This mask is intended for excision. With excision, AHFinderDirect needs to make sure that it does not interpolate from within the excised region. AHFinderDirect copies the excision mask into ahmask, and then interpolates from ahmask onto the horizon surface. It can thus find out whether an excised point was used for interpolation. Unfortunately, AHFinderDirect's code is a bit inflexible, and introducing a mask that is always there is much easier than changing the number of variables that are interpolated.
This interpolation is the same as is used for the ADMBase variables, and ahmask thus should have the same number of time levels. You are probably setting the number of ADMBase timelevels to 1, but some thorn (probably McLachlan) needs more timelevels and thus increases this number automatically.
In my case, I didn't think about it, and left the parameter set to the default. McLachlan then asks for storage for more timelevels.
If you set the number of ADMBase timelevels explicitly to the number you need (probably 3), then ahmask will also have more timelevels, and things should work. Since you are presumably already using 3 ADMBase timelevels, this will not change your evolution. And since ahmask will be all zeros anyway, increasing its number of timelevels should have no ill effect.
Yes, this worked. Setting the parameter on recovery allowed the run to proceed.
Maybe the number of timelevels should be set to the number actually active for the metric, rather than the value of a parameter which might be overridden by something else?
If you are looking for horizons at times that require time interpolation, then 1 timelevel for the ADMBase variables does not suffice.
I hope that my horizons are always on the finest grid, so I shouldn't need to interpolate on the horizons themselves, but the horizon-finding algorithm might need to look further out.