[ET Trac] [Einstein Toolkit] #1431: Issue with McLachlan and ADMBase::initial_shift

Einstein Toolkit trac-noreply at einsteintoolkit.org
Tue Sep 3 14:17:46 CDT 2013


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

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


More information about the Trac mailing list