[Users] MoL Arrays

[Erik Schnetter]

Global mode functions see a different time than local (or level) mode
functions, because time moves at different speeds on each refinement
level. To handle this, Carpet has internally one clock for each level,
plus a separate global clock. When MoL modifies the times for the
current level, it leaves the global clock alone. This is by design --
we could change the time visible to thorns in global mode to be the
time visible on the finest level, but this would be strange in some
other scenarios.

One trick to evolve an array is to schedule the RHS routine in level
mode, but to set the RHS to zero for all but the finest level. This
will evolve the array together with the finest level, and you will see
the "right" time. This also ensures that the RHS routine is called at
the right times and the right number of times and in the right order
with respect to other routines.

-erik

On Fri, Feb 24, 2012 at 1:33 PM, Christian Reisswig
<reisswig at tapir.caltech.edu> wrote:
> ok, I have scheduled my RHS functions in global mode.
> In the global RHS function I set my RHS source term to an analytically known
> value at some time "cctk_time".
>
> Weirdly, "cctk_time" does not carry the value of the intermediate MoL step for
> my global-mode function. Instead, it is always set to the time that MoL
> reaches after its "n" substeps. Is this behavior intended? To me, this looks
> like a bug since I would expect a proper "cctk_time" in the MoL substeps also
> for global-mode functions.
>
> Thanks for any hints,
> Christian
>
>
>> Hi Erik,
>>
>> thanks, very good! I got confused by the commented out functions.
>>
>> Christian
>>
>> > MoL still supports arrays.
>> >
>> > The mesh refinement argument does not hold any water -- first, it is
>> > perfectly fine to run a simulation without mesh refinement, and
>> > second, evolving arrays at the same time as the finest grid works
>> > fine. (I believe this is used in some versions of puncture tracking,
>> > where grid scalars or arrays hold the puncture position.)
>> >
>> > I believe you are looking for an old interface, which requires you to
>> > register grid functions and grid arrays via separate functions. This
>> > is not necessary any more -- MoL_RegisterEvolved can now process any
>> > kind of grid variable. I don't recall when this was changed.
>> >
>> > The commented out old API for grid arrays should be removed from the
>> > interface file.
>> >
>> > -erik
>> >
>> > On Fri, Feb 24, 2012 at 2:32 AM, Christian Reisswig
>> >
>> > <reisswig at tapir.caltech.edu> wrote:
>> > > Dear all,
>> > >
>> > > I am wondering why MoL does not have support for arrays anymore (the
>> > > provided functions are all commented out). I guess there is a
>> > > particular reason for this?
>> > >
>> > > Thanks for any hints!
>> > > Christian
>> > > _______________________________________________
>> > > Users mailing list
>> > > Users at einsteintoolkit.org
>> > > http://lists.einsteintoolkit.org/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at einsteintoolkit.org
>> http://lists.einsteintoolkit.org/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users



-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/