TmunuBase: stress_energy_storage should be a restricted parameter

Create issue
Issue #714 closed
Bruno Mundim created an issue


I was trying to use the stress_energy_storage parameter in TmunuBase to determine when to schedule or not a routine calculating the magnetic pressure (and friends). If storage is allocated for Tmunu then the magnetic pressure is calculated in the same routine. Otherwise, a separate routine would calculate the magnetic pressure. Keeping the routines always separate wouldn't be efficient when we do need the calculation and storage of Tmunu. Anyway, in order to do so, I needed to set stress_energy_storage as a restricted parameter (patch attached) in TmunuBase. Is there any reason for keeping this parameter private?


Keyword: TmunuBase

Comments (8)

  1. Erik Schnetter
    • removed comment

    This parameter is only used to initialise the grid scalar stress_energy_state. This grid scalar may change during evolution. Looking at the parameter is therefore not a good idea.

    Instead of using an if statement in your schedule, you could use an if modifier to check the grid scalar:

    SCHEDULE routine AT bin IF TmunuBase::stress_energy_state

  2. Bruno Mundim reporter
    • removed comment

    Ok, that seems better. However I want to schedule my routine when TmunuBase::stress_energy_state!=0. I am not sure how to make the "!" operator to work on the schedule after the IF statement.


  3. Bruno Mundim reporter
    • removed comment

    Sorry, actually I want to schedule when TmunuBase::stress_energy_state=0 or when (!TmunuBase::stress_energy_state)

  4. Erik Schnetter
    • removed comment

    That may not be possible in the schedule. In this case, I would open a feature request for this, and in the mean time put the if statement into your routine.

    (Calling a C or C++ routine from the scheduler is very fast, and costs only a few cycles. Calling a Fortran routine is more expensive since more arguments need to be passed, but should still be quite fast.)

  5. Bruno Mundim reporter
    • removed comment

    Hi Erik,

    thanks! I moved the logic to the routine itself. Hopefully it won't slow down that much.

    Regarding the feature request, shouldn't we wait for the schedule revamp to be done?

    Cheers, Bruno.

  6. Erik Schnetter
    • removed comment

    What feature request do you mean? I believe the parameter should remain private, as one should check the grid scalar instead.

  7. Log in to comment