[Developers] [Patches] The flesh evaluates parameter expressions for the size of grid arrays too early

David Rideout dprideout at gmail.com
Wed Nov 18 08:47:23 CST 2009

In general I would like to have more flexibility in the specification
of sizes of Cactus variables.  This is something that can be improved
in a future version.
In the mean time I have found a somewhat convenient workaround, which
is to steer parameters which control the size of grid variables during
STARTUP.  (To make it work I sandwich calls to CCTK_ParameterSet()
)  It would be convenient to have the size of a vector group also
evaluated during STARTUP, instead of at thorn activation.

Perhaps we could add another steerability mode, for such parameters?

I don't see a problem with checkpoint/recovery.  Thorns which use such
parameters are free to check their value during recovery if they

Extending accumulator parameters is a possibility, but it will be
messy, as it will force each contributing thorn to define yet another
dummy parameter.  Also it has the limitation that the contribution to
the accumulator parameter value must be a simple (closed form)
expression of parameters.  I can imagine the contribution having a
different functional form for different input parameter values.

My current situation is that I have a data structure whose size is a
random variable (its size changes every iteration).  Since this is
difficult to handle in Cactus, I want some upper bound on its size.
So I have each thorn declare an upper bound on this size to my 'base
thorn' (via an aliased function call), and that thorn then sets an
'Nmax' parameter with the supremum of all these bounds.

Here is a current function which declares a bound:

void CFlatSprinkle_Startup(void) {

  /* Since a Poisson distribution is essentially a Gaussian with variance
     'size', I choose violation of this bound to be a 6 sigma event. */
  CausetBase_RegisterGFSize(size + 6*sqrt(size));

Unfortunately I am finding this bound inadequate for small values of
'size', hence my concern above that one will want to use non-closed
form expressions of parameters.


On Thu, Nov 12, 2009 at 4:45 PM, Erik Schnetter <schnetter at cct.lsu.edu> wrote:
> On Nov 12, 2009, at 14:02 , David Rideout wrote:
>> The flesh evaluates parameter expressions for the size of grid arrays
>> when the thorn is activated.  This disallows the possibility of
>> steering the parameters before the driver allocates memory for such
>> grid variables.  The enclosed patch evaluates parameter expressions
>> for the size of grid arrays within the call to CCTK_GroupSizesI(), so
>> that it takes into account the most current values for the parameters.
> This is an intriguingly simple change to solve your problem (having grid array sizes be arbitrarily complex expressions instead of parameter values).  It is simpler than one of the alternative we discussed, which would be to allow calling aliased functions in these expressions.
> I'm concerned about several things.  The first is that, if array sizes are evaluated at a later time, then maybe other quantities should also be evaluated at a later time.  What about e.g. the number of vector elements in a grid variable group?
> Another is that this probably requires the parameter to be steerable, so that it can be set before the driver starts up.  However, being truly steerable is not a good idea, since the parameter should then remain constant during evolution, since the size of the grid array will never be recalculated.
> A third issue is with checkpointing and recovery.  I assume that the parameter value will not be set in the parameter file (since it will be calculated during startup).  That means that the parameter value will be checkpointed, and will also be recovered, which ensures that it then has the same value, which is necessary.  There should be some kind of check to ensure that the parameter is not set in a parameter file, and that it is not re-calculated differently upon recovery.
> Should there maybe a new parameter type "calculated", in addition to "steerable"?  Calculated parameters could not be set in the parameter file.
> Can you give an example of a function calculating a parameter?  How complex are these function in your case?  You mentioned earlier that you would like to calculate a maximum -- if this is all that you need, then extending accumulator parameters would be much simpler.
> -erik
> --
> Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/

More information about the Developers mailing list