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

Einstein Toolkit trac-noreply at einsteintoolkit.org
Thu Feb 14 00:40:13 CST 2013


#1256: scheduling MoL_PostStep in Post_Recover_Variables
--------------------+-------------------------------------------------------
 Reporter:  rhaas   |       Owner:     
     Type:  task    |      Status:  new
 Priority:  major   |   Milestone:     
Component:  Cactus  |     Version:     
 Keywords:  MoL     |  
--------------------+-------------------------------------------------------
 this is not ideal since some routines in MoL_PostStep will always change
 results (eg. Con2Prim). We already removed MoL_PostStep from the past
 timelevels since the prolongation cannot be handled properly.

 Originally (MoL rev 137,
 https://trac.einsteintoolkit.org/changeset/137/CactusNumerical/MoL) was
 introduced to enforce boundary conditions and recompute the ADM variables.
 Since then the policy has changed and the ADM variables are supposed to be
 checkpointed (rule of thumb is that anything with more than one timelevels
 should be checkpointed).

 When recovering from a checkpoint the boundary conditions are currently
 satisfied since CarpetIOHDF5 reads in everything that it can, incl. data
 in ghost and boundary zones. This method ensures that bit identical data
 is read in. Unfortunately running MoL_PostStep then changes values.

 It seems as if MoL_PostStep is never required so should not be run.

 The attached trivial patch adds a parameter to MoL to disable running in
 Post_Recover_Variables.

 Note that this is not yet are request for review but a work item since
 more testing is required to decide if anything breaks when MoL_PostStep is
 not run.

 Tests done with GRHydro (and changes so that eg. the atmosphere mask is
 identical in ghost zones [currently it is not valid in ghost zones but
 also never checked in ghost zones]) gives bit identical results even when
 changing the number of processors while recovering. This is a very simple
 test though.

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


More information about the Trac mailing list