- changed status to open
- removed comment
MoL flag for last MoL_PostStep
Issue #841
closed
This patch adds a flag MoL_LastPostStep which indicates whether we are in the last MoL_PostStep.
Keyword: MoL
Keyword: last
Keyword: PostStep
Keyword: flag
Comments (10)
-
-
- removed comment
Scheduling in the last MoL_PostStep seems to be identical to scheduling at evol after MoL_Evolution. Or is there a difference?
-
- removed comment
There is a difference, for instance, for syncing. Previously, the AtmosphereReset routine was scheduled in CCTK_EVOL after MoL_Evolution which required an extra sync of the primitive and conserved outside MoL_Evolution.
Instead, if we do the AtmosphereReset in the last Post Step, we only need to sync the primitives once (in the last post step), and in total we save an additional sync of the conserved quantities (since they are synced after Con2Prim anyway).
-
reporter
- removed comment
Replying to [comment:3 anonymous]:
There is a difference, for instance, for syncing. Previously, the AtmosphereReset routine was scheduled in CCTK_EVOL after MoL_Evolution which required an extra sync of the primitive and conserved outside MoL_Evolution.
Instead, if we do the AtmosphereReset in the last Post Step, we only need to sync the primitives once (in the last post step), and in total we save an additional sync of the conserved quantities (since they are synced after Con2Prim anyway).
I am not anonymous but Christian R.
-
- removed comment
This implies that:
(1) Atmosphere resetting acts locally on grid points, i.e. does not need ghost zones (does not look at neighbouring points), since otherwise it would require synchronizing beforehand. (2) It does not act on all grid points, since it requires synchronizing afterwards.
This seems strange. Could one instead run atmosphere resetting on all grid points (similar to converting to ADMBase), so that one does not need to synchronize afterwards?
-
- removed comment
Put differently: If this is only required for atmosphere handling, which doesn't follow the "usual" time integration scheme (nothing wrong with this!), then I would rather have this new MoL flag in the atmosphere handling thorn. I would like to keep MoL "clean" in the sense of strongly encouraging people to write algorithms that are independent of the MoL step counter.
-
reporter
- removed comment
Yes, atmosphere resetting does not look at neighboring points and thus no need for ghostzones. And yes, it only acts on those grid points (nominal grid) which had a proper RHS update and were integrated by MoL.
The trouble is that the atmosphere mask is updated during MoL evolution and can only be set on the nominal grid. We would need to synchronize the atmosphere mask. Then, we would be able to schedule atmosphere reset after all syncs and act on all grid points (and not just the nominal points).
We could also put the flag to GRHydro (which does the atmo handling) and let GRHydro decide whether this is the last PostStep. However, there may also be other thorns like the neutrino leakage thorn which may require scheduling in the last post step.
I principally agree that keeping the MoL thorn clean is a good idea. But I also see that the last MoL post step is a special case. For now, I guess we could introduce a flag to GRHydro checking the MoL step counter and let GRHydro decide whether it is time to execute the atmo resetting routine.
-
- removed comment
Yes, I would prefer this.
-
- changed status to resolved
- removed comment
Since there was further discussion, I will close this ticket.
-
- edited description
- changed status to closed
- Log in to comment
