[Developers] controlling the size of grid arrays

Erik Schnetter schnetter at cct.lsu.edu
Thu Nov 5 12:52:16 CST 2009

On Nov 5, 2009, at 10:47 , David Rideout wrote:

> Thanks.
> Can the accumulator parameter's value end up being the maximum of the
> parameters which contribute to it?  e.g.
> int Nmax accumulator=max(x,y)
> Unfortunately the values of y which contribute to it is not given
> directly by parameter values, but is a function of other parameters
> which involves square roots.  Is there some way to handle this?
> Is there any design requirement which is preventing us from having a
> much more flexible specification of the sizes of Cactus grid
> variables?  e.g. I have always thought it strange that the size of
> grid functions (and number of ghost zones!) is specified directly by
> parameters owned by the driver.  In general the size of grid variables
> should be computed by thorns, not given directly by parameters.  In
> fact I set PUGH's global_nx manually during STARTUP with
> ierr = CCTK_ParameterSet("global_nx", "PUGH", GFsizest);
> but this same trick is not working for grid arrays.  Also it is driver
> dependent which is ugly.  How does one specify the size of grid
> functions in Carpet?

Both Carpet and PUGH determine the sizes of grid functions on their  
own.  You can set Carpet::global_nx, but there are also other  
methods.  And PUGH also supports setting PUGH::local_nx, for example.

Instead of parameters we could also allow using aliased functions to  
set grid array sizes.  These would be called in the beginning of the  
simulation and would take no parameters.

The driver obtains the size of grid arrays via a call to  
CCTK_GroupSizesI.  This function could be updated, or there could be a  
driver flag to call another function.  (All other places that need to  
know the size of the group query the driver, so that there won't be an  


Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/

More information about the Developers mailing list