#1431: Issue with McLachlan and ADMBase::initial_shift -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: McLachlan | -----------------------------------+---------------------------------------- ADMBase provides the parameter ADMBase::initial_dtshift, which defaults to “none”. It allocates storage for the ADMBase::dtshift group if this variable is not equal to “none”. Hence, if you forget to set this parameter, you would expect not to get any storage, and your code will noisily fail if you try to access this group. However, ML_BSSN_Helper allocates storage for ADMBase::dtshift directly. So even if ADMBase::initial_dtshift is “none”, you still get storage for the variable, but it is never initialised, and you get NaNs in the evolution from the first iteration. Also, ADMBase's shift_state variable will still be 0, even though the shift has storage.
One minimal solution would be for ML_BSSN_Helper to only allocate storage for this variable if ADMBase::initial_shift is not “none”. Would this be a good solution?
There is probably a similar issue for dtlapse, but this is not required during BBH evolutions, so I haven't noticed it.
I think it is possible for McLachlan to be used without storage for ADMBase::dtshift, since the initial data might not be coming from ADMBase. So an alternative solution of aborting during parameter check if initial_shift is none wouldn't be a good solution.
Aside: the logic at the top of ML_BSSN_Helper/schedule.ccl and that in ADMBase/schedule.ccl can be simplified since recent versions of Cactus allow you to use a variable for the number of timelevels in a storage declaration.