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