[Users] highest output frequency for CarpetIOBasic?

[Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY]]

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 at 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 at 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 at nasa.gov
>> Web: 
>>http://science.gsfc.nasa.gov/sed/index.cfm?fuseAction=people.jumpBio&ipho
>>nebookid=13052
>> 
>>-------------------------------------------------------------------------
>>----
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at einsteintoolkit.org
>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>
>
>
>
>-- 
>Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/