[ET Trac] [Einstein Toolkit] #572: Change scoping of TmunuBase parameter to allow parameter checking in other thorns

[Einstein Toolkit]

#572: Change scoping of TmunuBase parameter to allow parameter checking in other
thorns
-------------------------------+--------------------------------------------
  Reporter:  filga@…           |       Owner:        
      Type:  defect            |      Status:  review
  Priority:  major             |   Milestone:        
 Component:  Other             |     Version:        
Resolution:                    |    Keywords:        
-------------------------------+--------------------------------------------

Comment (by eschnett):

 Making the parameters steerable is not possible since the execution
 schedule is decided on startup, not dynamically.

 In this case, the easiest solution is probably indeed to check the
 parameters support_old_CalcTmunu_mechanism and/or stress_energy_at_RHS.
 Both could be made restricted. The parameter stress_energy_storage should
 remain private; instead, the grid scalar stress_energy_state needs to be
 examined, since storage may change at run time, and it is much simpler to
 change a grid scalar than to steer a parameter.

 The "friend" mechanism is used to push one's own grid variables into
 another thorn, not only to access another thorn's variables. This is
 necessary for the high-level function inlining that Cactus supports, an
 important performance optimization. These days, I would not recommend
 using "friend" any more, since there are other, cleaner abstractions
 available for this.

 I would support a patch to make support_old_CalcTmunu_mechanism and/or
 stress_energy_at_RHS restricted.



 To make thorns less finnicky over parameters one would have to use
 accumulator parameters, akin to MoL's number of evolved grid functions. I
 believe Cactus doesn't support boolean accumulator parameters, hence one
 would use integers instead, and thorns requiring the old CalcTmunu
 mechanism and/or Tmunu at RHS would add to this parameter. Of course, once
 these requirements depend on other parameters, things become more complex,
 and one would need some run-time logic.

 Since this can become complex, and since complex things tend to fail and
 frustrate people, it's often easier to just check for errors in paramcheck
 and require users to do the right thing.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/572#comment:4>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit