So I'm curious about why Cactus/MoL does things the way it does. For the sake of this example, consider that we are evolving the variable B and we compute B_RHS during the evolution.
First, we fill in initial data. B = something. Second, at the start of the iteration loop, we rotate time levels. B --> B_p, B --> invalid Third, MoL_InitialCopy copies the previous time level to the current. B_p --> B Fourth, we evolve. B_RHS = Foo(B)
MoL_InitialCopy seems to be a wasted step. It would not be needed if (1) time levels were rotated at the end of the iteration loop, or (2) we computed B_RHS = Foo(B_p)
Am I missing something? Why do we do things that way?
--Steve
Hello Steve,
MoL_InitialCopy seems to be a wasted step. It would not be needed if (1) time levels were rotated at the end of the iteration loop, or (2) we computed B_RHS = Foo(B_p)
Am I missing something? Why do we do things that way?
(2) is not possible since the RK type methods evaluate the RHS multiple times and only the first time would be B_RHS = Foo(B_p) and the others would be B_RHS = Foo(B_intermediate_step).
(1) I don't understand. Right now timelevels are rotated just before CCTK_PRESTEP which is (from MoL's point of view) identical to rotating after CCTK_POSTSTEP as far as I understand things.
Having said that: the initialcopy is wasteful. I think there is a parameter to MoL that would compute the RHS for the next step at the end of the current iteration which would make B_RHS = Foo(B_p) unnecessary though it requires that RHS to be permanent so they are no longer just vehicles to transfer the RHS data to MoL.
Yours, Roland
Steve
This is done mostly for historic reasons. I want to get rid of this as well. However, my approach is even more extreme.
Sometimes, one wants to output the RHS. In this case, the RHS variables need to be calculated in the Analysis bin. This is a bit of a waste, since MoL will then re-calculate them at the beginning of the next time step.
My approach is:
- calculate the RHS in MoL_PostStep - do not calculate them in MoL_CalcRHS (this schedule group remains empty) - tell MoL to not "initialize" the RHS variables with zero - you can then simply skip the initial copy as well (unless some other routine is looking at it)
-erik
On Thu, Dec 8, 2016 at 11:11 AM, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
So I'm curious about why Cactus/MoL does things the way it does. For the sake of this example, consider that we are evolving the variable B and we compute B_RHS during the evolution.
First, we fill in initial data. B = something. Second, at the start of the iteration loop, we rotate time levels. B --> B_p, B --> invalid Third, MoL_InitialCopy copies the previous time level to the current. B_p --> B Fourth, we evolve. B_RHS = Foo(B)
MoL_InitialCopy seems to be a wasted step. It would not be needed if (1) time levels were rotated at the end of the iteration loop, or (2) we computed B_RHS = Foo(B_p)
Am I missing something? Why do we do things that way?
--Steve _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Roland Haas -
Steven R. Brandt