[ET Trac] [Einstein Toolkit] #1398: make evolution_method etc. parameters of ADMBase steerable

[Einstein Toolkit]

#1398: make evolution_method etc. parameters of ADMBase steerable
------------------------------------+---------------------------------------
  Reporter:  rhaas                  |       Owner:                     
      Type:  enhancement            |      Status:  review             
  Priority:  minor                  |   Milestone:                     
 Component:  EinsteinToolkit thorn  |     Version:  development version
Resolution:                         |    Keywords:  ADMBase            
------------------------------------+---------------------------------------

Comment (by eschnett):

 This seems potentially dangerous, because these parameters also decide
 which variables are evolved via MoL, what thorns allocate storage for
 which variables etc. Changing the evolution system can easily lead to
 major inconsistencies -- this is not something that recovery has been
 designed for. Lately, the push has been to ensure that recovery gives bit-
 identical results to the checkpointed run. Ensuring that recovery also
 detects these parameter changes, and then re-initializes fundamental
 quantities (instead of ensuring bitwise identical results), will be
 difficult.

 One example would be the ML_BSSN variables. I assume that they currently
 have storage and are initialized independent of the evolution system. This
 is "officially" somewhat of a bug, as ML_BSSN should remain inactive if it
 does not provide the evolution system. This would make all BSSN variables
 inaccessible during the continuation.

 Another example would the the ADMBase variables. While they may currently
 be checkpointed, this may not always be so -- ML_BSSN may opt to re-
 calculate them instead upon recovery. In this case, when the evolution
 system is changed, you would need to ensure manually that the ADMBase
 variables are then initialized, presumably either via a special thorn or
 via a new parameter in ADMBase.

 Have you tried e.g. using the file reader instead? You would write a new
 parameter file that starts a simulation from scratch, using the last
 checkpoint file from the other simulation as input source for the evolved
 variables.

 I don't want to stop you from changing the evolution system if this works
 for you, but you need to know that this is probably based on coincidences
 and is in general unsafe. I do not want to give others the impression that
 this is something that is supported or that can be expected to work. For
 example, a special command line parameter that lets people change
 parameters that are not steerable would be a good way to do so -- you
 would then use this option when you perform the iffy recovery.

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