[Users] MoL_InitialCopy

[Erik Schnetter]

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 at 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 at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>



-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20161208/28b9c4e6/attachment-0001.html