<div dir="ltr"><div>Thanks Erik! This helped me a lot.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 6, 2017 at 3:47 PM, Erik Schnetter <span dir="ltr"><<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div dir="ltr"><span class="">On Thu, Apr 6, 2017 at 7:50 AM, Gwyneth Allwright <span dir="ltr">
<<a href="mailto:allgwy001@myuct.ac.za" target="_blank">allgwy001@myuct.ac.za</a>></span> wrote:<br>
</span><div class="gmail_extra">
<div class="gmail_quote"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi All,<br>
<br>
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:<br>
</div>
</blockquote>
<div><br>
</div>
</span><div>Gwyneth</div>
<div><br>
</div>
<div>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:</div><span class="">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">*.average, *.count, *.d, *.maximum, *.minimum, *.norm1, *.norm2, *.norm_inf, *.sum
<br>
<br>
(as well as the above with an "i" in front of each descriptor, e.g. *.iaverage).<br>
<br>
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).<br>
</div>
</blockquote>
<div><br>
</div>
</span><div>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.</div><span class="">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Do norm1, norm2 and norm_inf refer to the L-1, L-2 and L-infinity norms?<br>
</div>
</blockquote>
<div><br>
</div>
</span><div>Yes.</div><span class="">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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?<br>
</div>
</blockquote>
<div><br>
</div>
</span><div>"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.</div>
<div><br>
</div>
<div>All quantities are integrated over all refinement levels.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">What does *.d represent?<br>
</div>
</blockquote>
<div><br>
</div>
<div>"*.d" files are created by 1D ASCII output. "x", "y", and "z" are along the respective directions, and "d" is along the diagonal.</div><span class="">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">For 1D IOASCII output, the headings look something like:<br>
<br>
# refinement level 1 multigrid level 0 map 0 component 26<br>
# 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<br>
<br>
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.<br>
</div>
</blockquote>
<div><br>
</div>
</span><div>it: iteration</div>
<div>tl: time level, usually zero, but can be nonzero if you output past time levels</div>
<div>rl: refinement level</div>
<div>c: component</div>
<div>ml: multigrid level, always zero</div>
<div>ix, iy, iz: integer coordinates (grid point indices) in the respective direction</div>
<div>time: simulation time (related to iteration)</div>
<div>x, y, z: coordinates (related to ix, iy, iz)</div>
<div>data: the actual value of the grid function</div>
<div><br>
</div>
<div>For plotting along the x axis, you would plot column 13 against column 10.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>-erik</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<div dir="ltr">Thanks very much for the help!<span class="m_-5991674407061929848HOEnZb"><font color="#888888"><br>
<br>
Gwyneth
<div><br>
</div>
</font></span></div>
<br></span>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@einsteintoolkit.org" target="_blank">Users@einsteintoolkit.org</a><br>
<a href="http://lists.einsteintoolkit.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.einsteintoolkit.o<wbr>rg/mailman/listinfo/users</a><br>
<br><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="m_-5991674407061929848gmail_signature" data-smartmail="gmail_signature">Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br>
<a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.<wbr>ca/personal/eschnetter/</a></div>
</font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
Disclaimer - University of Cape Town This e-mail is subject to UCT policies and e-mail disclaimer published on our website at <a href="http://www.uct.ac.za/about/policies/emaildisclaimer/" target="_blank">http://www.uct.ac.za/about/<wbr>policies/emaildisclaimer/</a> or obtainable from <a href="tel:+27%2021%20650%209111" value="+27216509111" target="_blank">+27 21 650 9111</a>. 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 <a href="mailto:csirt@uct.ac.za" target="_blank">csirt@uct.ac.za</a>
</font></span></div>
</blockquote></div><br></div>