[Users] IOScalar Reductions

[Gwyneth Allwright]

Thanks Erik! This helped me a lot.


On Thu, Apr 6, 2017 at 3:47 PM, Erik Schnetter <schnetter at cct.lsu.edu>
wrote:

> 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/
> Disclaimer - University of Cape Town This e-mail is subject to UCT
> policies and e-mail disclaimer published on our website at
> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27
> 21 650 9111 <+27%2021%20650%209111>. If this e-mail is not related to the
> business of UCT, it is sent by the sender in an individual capacity. Please
> report security incidents or abuse via csirt at uct.ac.za
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20170408/dc6442a1/attachment.html