[ET Trac] [Einstein Toolkit] #1256: scheduling MoL_PostStep in Post_Recover_Variables

[Einstein Toolkit]

#1256: scheduling MoL_PostStep in Post_Recover_Variables
---------------------+------------------------------------------------------
  Reporter:  rhaas   |       Owner:     
      Type:  task    |      Status:  new
  Priority:  major   |   Milestone:     
 Component:  Cactus  |     Version:     
Resolution:          |    Keywords:  MoL
---------------------+------------------------------------------------------

Comment (by wolfgang.kastaun@…):

 For the thermal branch of Whisky, the situation is the following

 -C2P does not need an initial guess, when called with the same input, the
 output is always the same.
 -C2P has a certain accuracy (given by a parameter), since it uses
 numerical root finding. Because of this, and only because of this, it is
 not an exact projection operator. It is however close to beeing one.
 -C2P does not just compute primitives from conserved variables, but also
 checks for unphysical input and tries to correct it under certain
 conditions, or sets the result to nan. Disentangling those two
 functionalities is possible but would be a performance problem.
 -C2P is also responsible for setting the artificial atmosphere. This could
 be decoupled in theory.
 -C2P does not set any additional masks.

 Therefore, our requirement are

 -C2P should only be called when the conserved variables have been updated.
 -It should not be called twice.
 -If it is called twice in certain cornercases, this may under no
 circumstance depend on arbitrary factors like restarts.
 -Running it twice is not an accuracy problem, but it is bad for debugging
 because it prevents us from noticing other bugs that slighltly change
 results during restart.
 -During checkpointing, the primitives and conserved variables should just
 be read from checkpoint file, including ghost/boundary points. There is no
 need to run C2P again.
 -Regridding of the conserved vars should be regarded like evolution of
 them, and C2P has to be run to keep things consistent.

 I also don't see why checkpointing and regridding have to trigger the
 sheduling of the same routines. Both things are different and should be
 treated seperately. I support the view that checkpointing should just
 reload stuff from file. If there are variables that can be recomputed
 _exactly_, one can do so instead, but this should be an _explicit_
 optimization. The standard should be to save and restore.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1256#comment:7>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit