On 02/24/2012 03:00 AM, Roland Haas wrote:

Hello Christian,

...

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?

As far as I understand it, the problem is with mesh refinement and the step-ahead in the Berger-Oliger scheme. Before a fine step is taken, the coarser grids step ahead so that there is data for prolongation. For an array this would require extra copies of the array for the stepping ahead. If you never feed the array content back into the grid then you might be able to get away updating in global mode (or on the finest level) and essentially do a unigrid evolution.

The discussion is here: http://cactuscode.org/pipermail/developers/2007-September/005428.html (Tanja Bode had the problem already while at PSU)

Yours, Roland

When was this changed? The RIT code uses MoL to evolve grid arrays (we use the Maxwell version of ET). It requires some nasty code to get the arrays evolved correctly and you need to make sure that, for a given a level, there is only 1 component per processor.

---

Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users

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

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

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