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@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@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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users