[Users] MoL Arrays

[Christian Reisswig]

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