 edited description
MoL_PseudoEvolution vs ANALYSIS
Consider a thorn like NPScalars
in the canuda arrangement.
NPScalars
computes the NewmanPenrose 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?
Comments (6)

reporter 
reporter  edited description

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 theevery
value that would give those iterations (ie not referring to the unknown maximumtimefac
value in the simulation). 
reporter 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/pullrequests/6/address2629amongtheotherthings
https://bitbucket.org/canuda/proca/pullrequests/5/npscalars_procacomputescalarsin
Everything compiles and runs.

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

reporter 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 followingWeylScal4
, which simply takes the modulo of the current iteration and thecompute_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 (unlesscompute_every
is 1).So, should
compute_every
be removed from thecanuda
codes andWeylScal4
? (Or at least, forced to be 1 for backwards compatibility)  Log in to comment