Hello Bernard,

Thanks, Roland. I'll have to check, but that sounds plausible: I sometimes am sloppy with my max_refinement_levels.

Do you know why it uses "max_refinement_levels" instead of the actual instantaneous finest level? For simplicity, or consistency over time (in case a derefinement happens)? The effect is counter-intuitive to me.

It cannot use the current ("actual") largest refinement level in use since you could decide to activate the dormant higher refinement level later on in the run (eg. Christian does that for core collapse runs). At the moment the new level becomes active the meaning of cctk_iteration would change and all previous iteration numbers would have to be multiplied by say two if you add one more level. So yes, it is for consistency in case de- and refinement happens. It is somewhat odd yes, that the iteration counter does not necessarily increase by one from one step to the other (actually it does internally to Carpet it is just that nothing is called on these levels [in Evolve.cc] in particular you cannot have a global routine run more frequent than the finest level).

Yours, Roland

PS I forgot to CC the list. Do you mind if I forward both emails?

Thanks, Erik & Frank. Roland gave me much the same answer off-list.

As I told Roland, I'll have to check, but that sounds plausible: I sometimes am sloppy with my max_refinement_levels. It never occurred to me that something like this could be a side-effect.

Bernard

On 12/1/11 11:34 AM, "Erik Schnetter" schnetter@cct.lsu.edu wrote:

Bernard

In Carpet, you specify how time iterations are counted via the "max_refinement_levels". Whether these finest iterations exist depends on how many levels you allocate. This ensures that each iteration corresponds to the same dt.

The fact that your iteration step size is 2 doesn't matter. If you want, you can reduce max_refinement_levels by one to change how iterations are counted; the physics results should remain identical.

-erik

On Thu, Dec 1, 2011 at 11:00 AM, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly@nasa.gov wrote:

...

Hi all.

Something new (I think) and trivial, but is annoying me.

For diagnostic purposes, I was running a Cactus/Carpet executable (ETK Maxwell) with CarpetIOBasic::output_1Devery = 1. To my surprise, the output happens every *two* timesteps. When I switch the parameter to 2, the same thing happens. So I get the following behaviour:

parameter value => actual output frequency

1 => 2 2 => 2 4 => 4 8 => 8

The grid has multiple refinement levels. I tried a smaller testsuite (perhaps one of the ML_BSSN tests, which are unigrid), and there "output_1Devery = 1" really did produce output every timestep.

I know a proper report needs a sample parameter file for reproducibility, but before I get that (not logged into the right machine right now), perhaps someone could tell me why this -might- happen? The logic in the IOBasic thorn seems simple enough ...

Thanks, Bernard

---

---

Bernard Kelly -- CRESST Research Associate, NASA/GSFC

Phone: +1 (301) 286-7243 E-Mail: bernard.j.kelly@nasa.gov Web: http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&iph... nebookid=13052

---

---

---

Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users

-- Erik Schnetter schnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/