MoL_PseudoEvolution vs ANALYSIS

Create issue
Issue #2629 new
Gabriele Bozzola created an issue

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?

Comments (6)

  1. 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).

  2. Gabriele Bozzola reporter

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

  3. Gabriele Bozzola 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 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)

  4. Log in to comment