AMReX-Astro / Castro

Castro (Compressible Astrophysics): An adaptive mesh, astrophysical compressible (radiation-, magneto-) hydrodynamics simulation code for massively parallel CPU and GPU architectures.
http://amrex-astro.github.io/Castro
Other
293 stars 99 forks source link

reassess parameter defaults #211

Open zingale opened 6 years ago

zingale commented 6 years ago

The default behavior of Castro should be to use the values of the runtime parameters that give the best accuracy or performance. Some default values have not been updated in a long time, despite code improvements. We should propose parameter changes in this issue.

maxpkatz commented 6 years ago

Parameter changes I think are unambiguously good:

Retries are a great way to avoid CFL violations that result in the simulation dying. Most newer users do not even realize this is a possible failure mode until it hits them deep into a simulation and it causes significant disruption. One small caveat here is that retries are a tool that have required a bit of tinkering in the past to get right. So I cannot guarantee that future changes to the scheme will not change code results in cases where the retries are hit.

This should be done in conjunction with the retry default, or else we'll never even get to the retry because we crash immediately upon detecting a CFL violation.

Doing a lagged prediction of the source terms in the hydro should always be more accurate.

This is the sort of performance option that the user should never have objection to -- in general, we should do performance improvements for the user unless we think there is any reason they would not want this.

Changes I think are very good but have at least some reason for caution:

It's always nice to avoid density resets; density resets are quite bad and unpredictable. The reason for caution here is that the flux limiter can also (slightly) modify the flow in smooth regions that don't quite get to a reset.

Changes I think are good but are somewhat a matter of personal choice:

We have seen that the linear state interpolation can have problems keeping sum(X) = 1 during a fillpatch. It is not good for users to crash for a reason like this during an AMR run.

~The default now is that after every source term is calculated at the new time, we update the state immediately before calculating the next source term. This results in an inconsistency where different source terms see a different new-time state, and also involves an EOS call before every extra source term.~

zingale commented 6 years ago

Isn't the update_state_between_sources going to be obsolete by #165?

maxpkatz commented 6 years ago

Yes, that's true.

maxpkatz commented 6 years ago

For castro.source_term_predictor we should probably wait until we fix #154

zingale commented 6 years ago

we should change the default of

dual_energy_update_E_from_e to 0

maxpkatz commented 6 years ago

I'd prefer just to remove it entirely. I don't think it's a good option.

zingale commented 5 years ago

dual_energy_update_E_from_e has been removed

zingale commented 4 years ago

castro.use_retry = 1 is now the default (#724)

castro.hard_cfl limit has been removed (#723)

zingale commented 2 years ago

more updates:

castro.use_custom_knapsack_weights seems to have been removed