The reason for this change was the past timelevels were left uninitialised after postregridinitial. The previous sequence was: 1. fill timelevels 2. regrid 3. postregridinitial on current timelevel
This leaves the past timelevels potentially uninitialised. And when init_fill_timlevels is set, then no other method will set up these past timelevels. Things work fine if this regridding step is a no-op, which will be the case for most current setups, as in this case the past timelevels remain defined.
My change re-applied the "fill timelevels" after postregridinitial. This should be a no-op, except if postregridinitial modified the current timelevel. In this case, copying these data to the past timelevels is arguably the correct thing to do.
-erik
On Tue, Nov 27, 2012 at 3:03 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 27 Nov 2012, at 08:39, rhaas@tapir.caltech.edu wrote:
User: rhaas Date: 2012/11/27 01:39 AM
Modified: /trunk/test/teukolsky/ Psi4i.d.asc, Psi4i.x.asc, Psi4i.y.asc, Psi4i.z.asc, Psi4r.d.asc,
Psi4r.x.asc, Psi4r.y.asc, Psi4r.z.asc
Log: WeylScal4: regenerate test data after Carpet change
Carpet's 6b5c318bb1057851d0ee1b5bba6e633c5cf31ca6 which re-copies init_fill_timelevels after initial restriction affects the ID we see and
hence
the final answer
Hi all,
This sounds like it might change results for more than just this one test case. Does more test data need to be regenerated, and does this affect reproducibility of simulations? Erik, what was the reason for this change in Carpet? Am I worrying for nothing?
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users