[ET Trac] [Einstein Toolkit] #380: AHFinderDirect failure with qc0-mclachlan.par

[Einstein Toolkit]

#380: AHFinderDirect failure with qc0-mclachlan.par
---------------------+------------------------------------------------------
  Reporter:  hinder  |       Owner:            
      Type:  defect  |      Status:  new       
  Priority:  major   |   Milestone:  ET_2011_05
 Component:  Other   |     Version:            
Resolution:          |    Keywords:            
---------------------+------------------------------------------------------

Comment (by rhaas):

 I agree with Erik in that scheduling is not the solution (in fact it does
 not help anyway) for the apparent horizon finding during the actual
 evolution. There (for the run I ran) I reduced the finding frequency of
 AHFinderDirect to the coarsest time step (for all horizons, though maybe
 only the larger surfaces were required). This kind of corresponds to not
 interpolating ahmask.

 Scheduling during ANALYSIS helps with Carpet::init_3_levels since Carpet
 calls CCTK_POSTSTEP during CCTK_INITIAL time when presumably
 cctk_iteration = 0 (but eg. cctk_time = -delta_t) so all of AHFinder's
 checks say "run me now". (I think from what I understand of how Carpet and
 the interpolation works.)
 I am not sure if I'd be happy with a full three-timelevel grid function
 just so that I can use it once during initial data. At least the my hydro
 runs tend to be starved for memory so I like avoiding extra grid functions
 (even though it is the cleanest solution to the problem). Maybe one coud
 make the number of timelevels a parameter?

 One could avoid scheduling in ANALYSIS by using Carpet::fill_timelevels
 instead of init_3_levels.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/380#comment:4>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit