[ET Trac] [Einstein Toolkit] #490: McLachlan test case failing due to ADMBase variable differences

Einstein Toolkit trac-noreply at einsteintoolkit.org
Wed Aug 10 16:32:19 CDT 2011


#490: McLachlan test case failing due to ADMBase variable differences
-----------------------------------+----------------------------------------
 Reporter:  hinder                 |       Owner:     
     Type:  defect                 |      Status:  new
 Priority:  critical               |   Milestone:     
Component:  EinsteinToolkit thorn  |     Version:     
 Keywords:  McLachlan              |  
-----------------------------------+----------------------------------------
 The McLachlan test ML_BSSN_sgw3d has been failing since 03-Aug-2011.  The
 only tested variable which is showing differences is kxx, but the
 differences appear to be significantly larger than roundoff:

    kxx.x.asc: substantial differences
       significant differences on 16 (out of 36) lines
       maximum absolute difference in column 13 is 0.000822901437894541
       maximum relative difference in column 13 is 0.0560528644051835
       (insignificant differences on 16 lines)

 This coincides with the following commit:

 commit 3ba8a55ae2578cb6dc06f0ec8b81f86b3a2654ac
 Author: Erik Schnetter <schnetter at cct.lsu.edu>
 Date:   Tue Aug 2 20:37:19 2011 -0400

     Correct schedule, in particular for checkpoint/recovery

     Do not mark ADMBase variables for non-checkpointing if they have
     multiple timelevels. (Variables with multiple timelevels must always
     be checkpointed, because the past timelevels cannot be regenerated
     after recovery.)

     Finally remove all perl post-processing of the auto-generated code;
     instead, use proper Kranc mechanisms.

     Schedule the ADM constraints and ADM quantities after MoL_PostStep,
     since this is where the ADMBase variables are set.

     Schedule enforcing the BSSN constraints in the new schedule group
     MoL_PostStepModify, since they should not be enforced after recovery.
     (This would lead to inconsistencies at floating-point round-off
     level.)

     Regenerate all thorns.

 and the other commits made to Cactus at the same time as explained in this
 email:

   http://cactuscode.org/pipermail/users/2011-July/002872.html

 Attached is a diff which shows what changed between the test passing and
 failing.

 Since this test does not deal with checkpointing or recovery, I don't
 understand why kxx should change so drastically.

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


More information about the Trac mailing list