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?
Hello 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?
As far as I can tell:
We have few tests using mesh refinement, so not many tests are affected. Other than this it was tests in Dissipation. As far as real world simulations are concerned I expect that every simulation that uses init_fill_timelevels (ie. very many) will see changes in its evolved variables (but no changes at t=0 where all timelevels align). The changes are in the buffer zones only if we have ID where ID values depend only on position (and not eg on taking finite difference derivatives) which includes eg. TwoPunctures. All of this is true for vertex centered data. Cell centered data is different everywhere since restriction is no longer just a copy operation.
Yours, Roland
On 27 Nov 2012, at 09:50, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello 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?
As far as I can tell:
We have few tests using mesh refinement, so not many tests are affected. Other than this it was tests in Dissipation. As far as real world simulations are concerned I expect that every simulation that uses init_fill_timelevels (ie. very many) will see changes in its evolved variables (but no changes at t=0 where all timelevels align). The changes are in the buffer zones only if we have ID where ID values depend only on position (and not eg on taking finite difference derivatives) which includes eg. TwoPunctures. All of this is true for vertex centered data. Cell centered data is different everywhere since restriction is no longer just a copy operation.
Thanks. What was the reason for the change? Was it incorrect before?
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
On 27 Nov 2012, at 14:10, Erik Schnetter schnetter@cct.lsu.edu wrote:
The reason for this change was the past timelevels were left uninitialised after postregridinitial. The previous sequence was:
- fill timelevels
- regrid
- 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.
Thanks for the info. So in most common cases, the effect of this change is to effectively apply postregridinitial to the past timelevels (via copying from the current timelevel which has had this applied) where it was previously not being applied. This could conceivably mean that some things which were computed exactly from the initial data on the past timelevels are now no longer exact, having been "recomputed" by postregridinitial, but this is no worse than what is done on the current timelevel, so while it is different, it is not wrong.
-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
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Ian Hinder -
Roland Haas