Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with Species Prediction at Edges #441

Open
biboyd opened this issue Apr 25, 2024 · 10 comments
Open

Issues with Species Prediction at Edges #441

biboyd opened this issue Apr 25, 2024 · 10 comments

Comments

@biboyd
Copy link
Collaborator

biboyd commented Apr 25, 2024

The species prediction (set by species_pred_type) type 2 and 3 differ in behavior from type 1 in a peculiar way. This can be seen in many problems but here is the difference in test_problems/reacting_bubble.

Problem

To recreate compile and run:

make -j 4 DIM=2
./Maestro2d.gnu.ex inputs_2d_C maestro.stop_time=3 maestro.species_pred_type=<insert type>

Output

Slices of ('boxlib', 'tpert'). species_pred_type=1 on the left, 2 in the center, and 3 on the right.

time0 0_tpert
time1 0_tpert
time2 0_tpert
time3 0_tpert

@zingale
Copy link
Member

zingale commented Apr 25, 2024

do you see the same differences if you run with maestro.evolve_base_state = 0?

@biboyd
Copy link
Collaborator Author

biboyd commented Apr 25, 2024

Yes, the behavior is the same

@zingale
Copy link
Member

zingale commented Apr 25, 2024

okay. I am not sure if this is a bug or a feature ;)
The way these different reconstruction methods work is written out here:
https://amrex-astro.github.io/MAESTROeX/docs/pert.html

we should see if the code agrees with what is written there.

@zingale
Copy link
Member

zingale commented Apr 26, 2024

it would also be interesting to try to reproduce this in the old Fortran MAESTRO. Assuming we can still get it to compile...

@biboyd
Copy link
Collaborator Author

biboyd commented Apr 29, 2024

Was able to get the last MAESTRO release to compile, looks better though you can still see some differences

maestro_time1 0_tpert
maestro_time2 0_tpert
maestro_time3 0_tpert

@zingale
Copy link
Member

zingale commented May 6, 2024

I looked over all the code in DensityAdvance, MakeRhoXFlux, MaestroRhoHT.cpp, and then ModifyScalForce and MakeEdgeScal and compared to the old Maestro and I don't see any obvious issues.

I think the next step would be to run the same problem in each for one step and have the codes print out the interface states so we can compare.

@zingale
Copy link
Member

zingale commented May 12, 2024

I setup a small version of this problem (48 x 80 cells) and walked through the density advance, printing out the components that go into the flux construction in both MAESTRO and MAESTROeX for a single zone. I ran without enthalpy (use_tfromp=1) and with base state evolution disabled.

Looking at the results of modify_scal_force, make_edge_scal, and make_rhoxflux, they all seem consistent for species_pred_type = 1 and species_pred_type = 3.

I still need to dig into the update_scal stuff.

@zingale
Copy link
Member

zingale commented May 12, 2024

Here's a comparison with burning disabled using 144 x 240 zones and species_pred_type = 3

image

MAESTRO is left, MAESTROeX is right

@zingale
Copy link
Member

zingale commented May 13, 2024

what's interesting is that I can get old (Fortran) MAESTRO to abort in the first step if I try running with species_pred_type = 2 with this inputs file:

inputs.compare.txt

and a slight change to the perturbation:

$ git diff .
diff --git a/Exec/TEST_PROBLEMS/reacting_bubble/init_perturb.f90 b/Exec/TEST_PROBLEMS/reacting_bubble/init_perturb.f90
index 04c68ce5..bd14a8de 100644
--- a/Exec/TEST_PROBLEMS/reacting_bubble/init_perturb.f90
+++ b/Exec/TEST_PROBLEMS/reacting_bubble/init_perturb.f90
@@ -69,8 +69,14 @@ contains
     eos_state%T     = temp
     eos_state%p     = p0_init
     eos_state%rho   = s0_init(rho_comp)
-    eos_state%xn(:) = s0_init(spec_comp:spec_comp+nspec-1)/s0_init(rho_comp)
 
+    if (r1 < 1.0 .or. r2 < 1.0 .or. r3 < 1.0) then
+       eos_state%xn(1) = 0.0d0
+       eos_state%xn(2) = 0.7d0
+       eos_state%xn(3) = 0.3d0
+    else
+       eos_state%xn(:) = s0_init(spec_comp:spec_comp+nspec-1)/s0_init(rho_comp)
+    endif
     call eos(eos_input_tp, eos_state)
 
     dens_pert = eos_state%rho

but MAESTROeX runs...

@zingale
Copy link
Member

zingale commented May 13, 2024

okay... I think it is an averaging thing

Here's old Fortran MAESTRO running inputs_2d_C with species_pred_type = 3 with 2 different resolutions.

On the left is 144 x 240 zones on the right is the default 384 x 640 zones.

image

what I think we are seeing is that this problem has very strong, local perturbations, which affects the average base state more at coarse resolutions. And the different pred types interact with the averaging in different ways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants