[Users] Possible performance issue with some codes
Ian Hinder
ian.hinder at aei.mpg.de
Wed Aug 17 17:04:45 CDT 2011
Hi,
A change was made a few months ago to ADMBase to solve some problems with the ADMBase variables not being synchronised in some situations where they need to be. This was r59 in ADMBase SVN. The bit I'm worried about is this:
+# For Mesh Refinement it is possible (eg Cowling approximation) that ADMBase variables will need synchronization even when not evolved (eg when a new refined grid appears)
+if (CCTK_Equals(evolution_method, "static") || CCTK_Equals(evolution_method, "none") || CCTK_Equals(lapse_evolution_method, "static") || CCTK_Equals(shift_evolution_method, "static") || CCTK_Equals(dtlapse_evolution_method, "static") || CCTK_Equals(dtshift_evolution_method, "static") )
+{
+ SCHEDULE ADMBase_Boundaries IN MoL_PostStep BEFORE ADMBase_SetADMVars
+ {
+ LANG: C
+ OPTIONS: LEVEL
+ SYNC: lapse
+ SYNC: dtlapse
+ SYNC: shift
+ SYNC: dtshift
+ SYNC: metric
+ SYNC: curv
+ } "Select ADMBase boundary conditions - may be required for mesh refinement"
+}
For any code which does not use the ADMBase::[lapse/shift]evolution_method parameters to control their evolution, unnecessary syncs will be performed for the ADMBase variables. Whereas before these parameters seemed to be a superfluous part of the ADMBase infrastructure (after all, why activate your evolution thorn if you're not going to evolve with it?), it now seems that it is essential to extend and use these parameters if you want to use ADMBase, or performance will suffer. The GT evolution code would suffer from this, the last time I looked at it, and other groups' codes might also.
--
Ian Hinder
ian.hinder at aei.mpg.de
More information about the Users
mailing list