[Users] problems with AHFinderDirect

[Erik Schnetter]

On Thu, Jun 14, 2012 at 12:06 PM, Eloisa Bentivegna
<bentivegna at cct.lsu.edu> wrote:
> On Jun 14, 2012, at 4:34 PM, Ian Hinder wrote:
>
>>>>> this error usually comes up when the arguments to umfpack_numeric() are not numbers (as would happen, for instance, if the metric had become singular). Could you check that your 3+1 variables are finite? Thorn NaNChecker could help you do that.
>>>>
>>>> If this turns out to be the problem, we should probably check for this in AHFinderDirect and give an error message.  Something like "The metric has become singular at [x,y,z]; unable to compute horizon and aborting the run".
>>>
>>> Nah: "unable to compute horizon; continuing the run".
>>
>> This would be consistent with the behaviour when it is unable to find the horizon for other reasons, so I agree.  Though it might be good to have a "strict" parameter for each horizon which insists that it must be found when it is searched for, or the run stops.  Not sure what to do about horizons disappearing at a merger though.
>
> Well, that is heavily case-dependent. A user will need to decide by themselves whether finding a horizon is absolutely necessary, and when. Maybe we could introduce parameters strict_after and strict_before, similarly to the existing find_after and find_before?

Horizon finding is always iffy. There is currently no mechanism to
abort if a horizon cannot be found.

We could introduce a mechanism for this, but it would need to be
fuzzy. "If you can't find this horizon during the first 10 iterations
of the run, or if you have lost it for more than 100 iterations before
t=30, or before the common horizon is found, then abort."

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/