MoL_PseudoEvolution vs ANALYSIS

[Gabriele Bozzola]

Consider a thorn like NPScalars in the canuda arrangement.

NPScalars computes the Newman-Penrose grid functions in the CCTK_ANALYSIS bin. The operation requires taking derivatives. Similarly, LeanBSSNMoL computes the constraints in the same bin (this will likely be a regression I introduced in commit 80b6b1b).

My understanding is now that CCTK_ANALYSIS is not the right place where to do this because of interpolation/prolongation/notsurewhat.

Is the fix to simply replace CCTK_ANALYSIS with MoL_PseudoEvolution?

I would like to make sure that this is the case considering also parameters like compute_every. Since these are expensive diagnostics, it is best to compute them only when they are output. Do I get the correct constraints/scalars if I compute and output them only when all the refinement levels are synced?

‌

[Roland Haas]

In the call I said I knew how to do the scheduling in MoL_PseudoEvolution. Turns out that this is not true. Here’s my current thoughts:

rl=0 delta_t=4.0 timefac=1
rl=1 delta_t=2.0 timefac=2
rl=2 delta_t=1.0 timefac=4

it == 0:
rl=0 t_of_level=0.0
rl=1 t_of_level=0.0
rl=2 t_of_level=0.0

it == 1:
rl=0 t_of_level=4.0
rl=1 t_of_level=2.0
rl=2 t_of_level=1.0

it == 2:
rl=2 t_of_level=2.0

it == 3:
rl=1 t_of_level=4.0
rl=2 t_of_level=3.0

it == 4:
rl=2 t_of_level=4.0

if wanting to compute every Delta_t = 4.0 which is every 4 iterations, need to
evaluate at:

it = 0 for rl=0,1,2
and
it = 1 for rl=0
it = 3 for rl=1
it = 4 for rl=2

and I am not sure to to come up with an expression that involves only iteration, timefac and the every value that would give those iterations (ie not referring to the unknown maximum timefac value in the simulation).

[Gabriele Bozzola]

I guess the solution is to leave it up to the user to make sure the they set the correct value for “compute_every”.

Here’s two PR:

https://bitbucket.org/canuda/lean_public/pull-requests/6/address-2629-among-the-other-things

https://bitbucket.org/canuda/proca/pull-requests/5/npscalars_proca-compute-scalars-in

Everything compiles and runs.

[Gabriele Bozzola]

It runs, but I am not sure it produces the correct results, so the PRs shouldn’t be merged at the moment.

[Gabriele Bozzola]

Upon further reflection, and reading more carefully the previous message, my impression is that there’s no easy way to implement a compute_every function. I originally implemented the function following WeylScal4, which simply takes the modulo of the current iteration and the compute_every parameter. But, if I understand what is going on, this is not the correct thing to do, as I can see in my test runs (unless compute_every is 1).

So, should compute_every be removed from the canuda codes and WeylScal4 ? (Or at least, forced to be 1 for backwards compatibility)