Hi, all,
I noticed that data of "position_(x|y|z)[0-9]..asc" in CarpetRegrid2 is sometimes not correct at restarting point from checkpoint.
After restarting the run, the value of first one point become "0" ( See attached figure).
I guess this wrong values are only on outputted files and internally correct value are used. Is this right?
Kentaro TAKAMI
On Mar 6, 2012, at 10:49 AM, Kentaro Takami wrote:
Hi, all,
I noticed that data of "position_(x|y|z)[0-9]..asc" in CarpetRegrid2 is sometimes not correct at restarting point from checkpoint.
After restarting the run, the value of first one point become "0" ( See attached figure).
I guess this wrong values are only on outputted files and internally correct value are used. Is this right?
Hi Kentaro,
a few questions: which thorn are you using to fill in the position_* scalars? Is it doing anything at recovery? Are you using the parameter Carpet::regrid_during_recovery?
Eloisa
Hi, Eloisa,
a few questions: which thorn are you using to fill in the position_* scalars? Is it doing anything at recovery? Are you using the parameter Carpet::regrid_during_recovery?
I'm using Whisky, and the carpetregrid2::positions are computed by "Whisky_MoveCarpetGrids" thorn.
I'm using the parameter, Carpet::regrid_during_recovery = "no".
Kentaro
On Mar 6, 2012, at 1:38 PM, Kentaro Takami wrote:
Hi, Eloisa,
a few questions: which thorn are you using to fill in the position_* scalars? Is it doing anything at recovery? Are you using the parameter Carpet::regrid_during_recovery?
I'm using Whisky, and the carpetregrid2::positions are computed by "Whisky_MoveCarpetGrids" thorn.
I'm using the parameter, Carpet::regrid_during_recovery = "no".
OK. CarpetRegrid2::positions should be checkpointed and recovered; if this is working as it should (can you check your checkpoint files, just in case?), then something is changing these variables at recovery.
Is Whisky_MoveCarpetGrids perhaps reinitializing them? This will only matter if you're regridding at recovery (otherwise CarpetRegrid2 simply won't look at these values at that stage).
Eloisa
OK. CarpetRegrid2::positions should be checkpointed and recovered; if this is working as it should (can you check your checkpoint files, just in case?), then something is changing these variables at recovery.
At beginning, these variables are initialized by parameter values:
INFO (CarpetRegrid2): Initialising position of centre 0 to [15.3,0,0] INFO (CarpetRegrid2): Initialising position of centre 1 to [-15.3,0,0] INFO (CarpetRegrid2): Initialising position of centre 2 to [0,0,0]
After reading checkpoint file, these variables are replaced by checkpoint data.
However I can not directly check the checkpoint file, because already I don't have these checkpoint files and this strange behavior "sometimes" happen (not every time in recovering).
Is Whisky_MoveCarpetGrids perhaps reinitializing them?
I don't think so. Already as I mention, I can see this strange behavior sometimes, not every recovering time. I guess...this means the behavior depend on the iteration position of checkpoint file.
Kentaro
On Tue, Mar 6, 2012 at 6:20 PM, Kentaro Takami kentaro.takami@aei.mpg.de wrote:
OK. CarpetRegrid2::positions should be checkpointed and recovered; if this is working as it should (can you check your checkpoint files, just in case?), then something is changing these variables at recovery.
At beginning, these variables are initialized by parameter values:
INFO (CarpetRegrid2): Initialising position of centre 0 to [15.3,0,0] INFO (CarpetRegrid2): Initialising position of centre 1 to [-15.3,0,0] INFO (CarpetRegrid2): Initialising position of centre 2 to [0,0,0]
After reading checkpoint file, these variables are replaced by checkpoint data.
However I can not directly check the checkpoint file, because already I don't have these checkpoint files and this strange behavior "sometimes" happen (not every time in recovering).
Is Whisky_MoveCarpetGrids perhaps reinitializing them?
I don't think so. Already as I mention, I can see this strange behavior sometimes, not every recovering time. I guess...this means the behavior depend on the iteration position of checkpoint file.
You are making two guesses here -- about Whisky_MoveCarpetGrids, and the one about "depend on the iteration position". I would be very careful with such guesses; it is always necessary to check these with hard data. I suggest you examine both the Cactus schedule and the checkpoint file next time you see the problem.
-erik
Thank you, Erik and Eloisa,
I could find out the cause of this problem by your suggestions. It is just related with "Whisky" and "Whisky_MoveCarpetGrids" thorns and I could fix it.
Thanks.
Kentaro
users@lists.einsteintoolkit.org
-
Eloisa Bentivegna -
Erik Schnetter -
Kentaro Takami