[Users] IOScalar Reductions

[Erik Schnetter]

On Thu, Apr 6, 2017 at 7:50 AM, Gwyneth Allwright <allgwy001 at myuct.ac.za>
wrote:

> Hi All,
>
> I'm currently trying to make sense of the 0D output files for the momentum
> and Hamiltonian constraint errors (from ML_ADMConstraints and ML_BSSN).
> When using IOScalar, many files are produced, apparently using various
> norms and reductions:
>

Gwyneth

There is a difference between 0D and scalar output. 0D output chooses a
zero-dimensional subset of the grid function, i.e. a single point, and
outputs it. That is useful only in very special situations. Scalar output
consists of reductions, i.e. norms and similar. IOScalar only provides
scalar output, such as these files:

*.average, *.count, *.d, *.maximum, *.minimum, *.norm1, *.norm2,
> *.norm_inf, *.sum
>
> (as well as the above with an "i" in front of each descriptor, e.g.
> *.iaverage).
>
> I'd naively guess that iaverage, isum etc. are reductions using imaginary
> components, while the others are with real components, but have no clue
> whether this is correct (I'm not sure whether these errors can run over the
> imaginaries).
>

With mesh refinement, there are two straightforward ways of defining a
norm. One, you can integrate over the physical domain, so that coarse cells
(large cells) contribute much more than fine cells, which are very small.
This is physically correct, but often uninteresting, since it basically
only looks at the regions far away from a black hole, which occupies a tiny
fraction of the domain. Second, you can integrate over the grid cells, so
that each cell contributes the same. This is physically wrong, but
computationally a much better measure to find out about the "interesting"
regions of the domain. The "i"-prefixed quantities use this measure. Note
that this measure changes when the grid structure changes.

Do norm1, norm2 and norm_inf refer to the L-1, L-2 and L-infinity norms?
>

Yes.

I'm unsure of what *.count represents -- perhaps the number of grid points
> over which the reductions are calculated? Are the values used to calculate
> the reductions taken from different refinement levels?
>

"count" is the number of cells, i.e. related to the volume of the domain.
"sum" is the sum over all cells, related to the volume integral.

All quantities are integrated over all refinement levels.

What does *.d represent?
>

"*.d" files are created by 1D ASCII output. "x", "y", and "z" are along the
respective directions, and "d" is along the diagonal.

For 1D IOASCII output, the headings look something like:
>
> # refinement level 1   multigrid level 0   map 0   component 26
> # column format: 1:it 2:tl 3:rl 4:c 5:ml 6:ix 7:iy 8:iz 9:time 10:x 11:y
> 12:z 13:data
>
> I'm unsure of what many of these mean: "multigrid level", "map" and
> "component" in the first row; 3 to 8 in the second row. I'm especially
> curious about what the components are, because I'm only seeing data for a
> small number of components.
>

it: iteration
tl: time level, usually zero, but can be nonzero if you output past time
levels
rl: refinement level
c: component
ml: multigrid level, always zero
ix, iy, iz: integer coordinates (grid point indices) in the respective
direction
time: simulation time (related to iteration)
x, y, z: coordinates (related to ix, iy, iz)
data: the actual value of the grid function

For plotting along the x axis, you would plot column 13 against column 10.

Cactus splits a grid function into rectangular block. This is necessary for
domain decomposition, and also if a refined region has a non-rectangular
shape. These blocks are called "components", and are numbered separately on
each refinement level. In a unigrid simulation, the component number is
equal to the process number.

-erik

Thanks very much for the help!
>
> Gwyneth
>
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>
>


-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20170406/bd940f9c/attachment.html