make evolution_method etc. parameters of ADMBase steerable

Comments (5)

1. 

   Roland Haas reporter

   • changed status to open
   • removed comment

   • 2013-06-29T15:50:43+00:00
2. 

   Erik Schnetter

   • removed comment

   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.

   • 2013-07-02T08:56:31+00:00
3. 

   Roland Haas reporter

   • removed comment

   Switching evolution system requires extra care and is potentially very dangerous (mostly though one just gets poison when not using it correctly), yes. One needs to schedule the equivalent of ADM_to_BSSN in Post_Recover_Variables - on all timelevels - which is currently disabled with a page long comment (by me...) explaining why running Post_Recover_Variables on all timelevels is detrimental to bitwise exact recovery. These are "you-asked-for-it/famous-last-words" kind of options. Use at your own risk.

   I have to admit I am not sure I see why this necessarily conflicts with a desire for bitwise identical recovery. Here the user is telling the system that she wants something different from what was used in the previous checkpoint so must expect changes.

   Using the file reader is currently not a very convenient alternative since it cannot currently automatically recover the grid structure from the data files and one is forced to construct a set of input parameters to eg CarpetRegrid2 that mimic the settings (set via the grid scalars of CarpetRegrid2) that were active at the time the checkpoint files were written.

   There is not much experience yet on how well this method will work. So let's wait for a bit to see how feasible it turns out to be. If it is fraught with difficulties it might be faster to extent the file reader to somehow recover the grid structure from files and use that. In that case it would be nice to be able to set the initial cctk_iteration value as well (agreed, no one should depend on cctk_iteration since it is just a counter and does not necessarily have a simple relationship with cctk_time, many thorns do though).

   • 2013-07-02T23:30:16+00:00
4. 

   Roland Haas reporter

   • changed status to resolved
   • removed comment

   No one seems to have actually done this yet, so I am happy to drop the patch given that there are reservations about having such dangerous (and requiring code changes to make work) patches in the repository. A better way seems to be to improve the file reader.

   • 2013-08-25T20:48:01+00:00
5. 

   Roland Haas reporter

   • edited description
   • changed status to closed

   • 2019-02-21T20:12:57+00:00
6. Log in to comment