[Users] MoL Arrays

[Christian Reisswig]

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