[Users] MoL Arrays

[Erik Schnetter]

Are you setting the RHS to 0 on all but the finest level?

MoL copies past to current timelevel at the begin of every iteration
for every level.

-erik

On Fri, Feb 24, 2012 at 7:58 PM, Christian Reisswig
<reisswig at tapir.caltech.edu> wrote:
> Hi,
>
> I now run into the problem that any of the rk* schemes are not returning the
> correct result. I am basically setting my (array) RHS to 1.0 and integrating
> the function for some iterations. I expect the final result to be equal to the
> final time which is not the case for rk* (but interestingly for icn).
> Are there any other tricks I need to apply to get it right (such as manually
> cycling timelevels...)?
>
> I only have one reflevel and the "level"-mode RHS array computation is executed
> once per MoL substep.
>
> Thanks,
> Christian
>
>
>> Great! Thanks a lot for your help, Erik!
>>
>> Christian
>>
>> > 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
>>
>> _______________________________________________
>> 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/