#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.