[Users] Loss of precision after postintial?

Thu Aug 31 09:54:08 CDT 2023

Hello Hayley,

Sorry for the delay. I am currently out of office and slow with emails.

GRHydro was really my only guess, and I ma pretty stumped. We discussed
this in the ET call today but could not come up with a good answer.

One question that came up was if the difference you see in say 3-Ricci
is present everywhere or only at say refinement boundaries?

If you have not already done so (if you have, then sorry, I missed
them) could you possible send a (cut down, does not have to include the
analysis code or private codes) parameter file that would show the
problem? Is the issue present only in quantities that are being
re-computed (3-Ricci) by the analysis code or already in quantities
that are in the HDF5 files (gij, kij in ADMBase and gammaij, Aij and
the traces in the BSSN code)?

Yours,
Roland

> Hi Roland,
> 
> Yes, there is a fluid and I am using GRHydro. But I have checked individual terms, and the matter terms are identical between my checks in HydroBase_Initial and my analysis of the HDF5 output. 
> 
> I have pinpointed the difference to be coming from the terms with spatial derivatives of metric quantities, e.g., D_i trK and 3-Ricci tensor. The codes I use for these two calculations use the same routines, so all I can think of now is a possible precision issue somewhere. 
> 
> I’ll keep investigating, but if you have any other ideas please let me know!
> 
> Best,
> Hayley
> 
> > On 24 Aug 2023, at 15:39, Roland Haas <rhaas at illinois.edu> wrote:
> > 
> > Hello all,
> > 
> > just to be sure: is there a fluid present (and GRHydro)? Then there is
> > also the issue of con2prim to consider (and Tmunu).
> > 
> > Yours,
> > Roland
> >   
> >> Hayley
> >> 
> >> No, there should not be any loss of precision. The difference in the
> >> ADMBase variables should be at round-off level.
> >> 
> >> -erik
> >> 
> >> On Wed, Aug 23, 2023 at 12:37 PM Hayley Macpherson
> >> <hayleyjmacpherson at gmail.com> wrote:  
> >>> 
> >>> Hi Erik,
> >>> Thanks for the quick response!
> >>> 
> >>> I’m not using mesh refinement, and yes I ignore the ghost zones in my calculations. I use periodicity within the original (no ghosts) grid for derivatives.
> >>> 
> >>> And yes I’m using the ADMBase metric and extrinsic curvature. I get the same result whether I do the calculation in the postpostinitial stage or using the 3D dumps in post-processing. Would there be a loss of precision in ADMBase gij and kij when translating back and forth to BSSN metric/kij, which could then be propagated to the output files?
> >>> 
> >>> Best,
> >>> Hayley
> >>> 
> >>> On 23 Aug 2023, at 11:31, Erik Schnetter <schnetter at gmail.com> wrote:
> >>> 
> >>> Hayley
> >>> 
> >>> Are you using mesh refinement in your calculations? If so, the ET
> >>> would fill the ghost and the buffer zones with interpolated data.
> >>> These are generally less accurate than properly calculated data. If
> >>> so, are you ignoring ghost and buffer zones? These should not be used
> >>> for visualization and post-processing.
> >>> 
> >>> Which metric variables are you accessing? I assume you are looking at
> >>> ADMBase for the metric and extrinsic curvature? These should change,
> >>> unless you look at them too early: During initialization, we set up
> >>> the ADMBase variables, then define the BSSN variables from these, and
> >>> then recalculate the ADMBase variables. This would change them
> >>> slightly. Analysis tools should only look at the ADMBase variables
> >>> after they have been reset.
> >>> 
> >>> -erik
> >>> 
> >>> 
> >>> On Wed, Aug 23, 2023 at 11:56 AM Hayley Macpherson
> >>> <hayleyjmacpherson at gmail.com> wrote:
> >>> 
> >>> 
> >>> Hi all,
> >>> 
> >>> I’m the author of a cosmological initial data thorn in the ET; FLRWSolver. I’m currently working on improving the initial data to solve the constraint equations exactly (instead of previously using an approximation), for a given metric and Kij. The way this works is to calculate the metric terms on the LHS of both the constraints and solve for the relevant rest mass density and peculiar 3-velocities from the matter terms.
> >>> 
> >>> I have my own routines from a post-processing analysis code to calculate the metric terms, and I’ve incorporated these into the ET for both generating the initial data but also then double checking the constraint violation after the initial data is set up.
> >>> 
> >>> I noticed something strange: my checks immediately after FLRWSolver is called in the ET show the constraints are satisfied essentially to roundoff error (i.e. the momentum constraint violation has magnitude ~ 1.e-15), but when I take the 3D dump of the initial time slice and run this through my analysis code (which uses the same routines as I use to set up initial data), I see the momentum constraint is violated at the ~ 1e-7 level.
> >>> 
> >>> I thought this might be my post processing code, so I added a second call to check the constraints using my routines after the full initial process is finished. The first call which immediately follows my FLRWSolver routine is placed in group HydroBase_Initial, and I added another call in CCTK_POSTINITIAL which gives the same result, however, if I instead schedule this call in POSTPOSTINITIAL I see the momentum constraint violation is identical to what I see when post processing the initial dump, at ~ 1.e-7. I can see the specific terms which are causing this difference are the terms which use finite-difference derivatives (the curvature terms in the momentum constraint), while all others are identical.
> >>> 
> >>> So my question is the following: is there any way that the metric and curvature variables could suffer a loss of precision between the POSTINITIAL and POSTPOSTINITIAL phases of the run? Especially, a loss in precision which is then translated to the 3D dumps.
> >>> 
> >>> The momentum constraint violation I have is satisfactory, but I am trying to pinpoint why this jump happens to make sure it’s not a bug in my separate code somewhere (also to explain why the constraints aren’t satisfied to roundoff level when they should be, by construction of my initial data :) ).
> >>> 
> >>> Any help is much appreciated!
> >>> Best wishes,
> >>> Hayley
> >>> 
> >>> ----
> >>> 
> >>> Hayley Macpherson | NASA Einstein Fellow
> >>> 
> >>> Email: hjmacpherson at uchicago.edu
> >>> Pronouns: she/her/hers
> >>> 
> >>> Office: ERC 479
> >>> Kavli Institute for Cosmological Physics
> >>> Eckhardt Research Center
> >>> 5640 South Ellis Avenue
> >>> Chicago, IL, 60637
> >>> 
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users at einsteintoolkit.org
> >>> https://urldefense.com/v3/__http://lists.einsteintoolkit.org/mailman/listinfo/users__;!!DZ3fjg!6h4G9d13wz3CvnZuXtOUn3T5cMOIpEMAdnA3o2nTka8JLWDxyoWPws-NTWy-99dGdNk6LmRxzBagF6wcfg$ <https://urldefense.com/v3/__http://lists.einsteintoolkit.org/mailman/listinfo/users__;!!DZ3fjg!6h4G9d13wz3CvnZuXtOUn3T5cMOIpEMAdnA3o2nTka8JLWDxyoWPws-NTWy-99dGdNk6LmRxzBagF6wcfg$> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> --
> >>> Erik Schnetter <schnetter at gmail.com <mailto:schnetter at gmail.com>>
> >>> https://urldefense.com/v3/__http://www.perimeterinstitute.ca/personal/eschnetter/__;!!DZ3fjg!6h4G9d13wz3CvnZuXtOUn3T5cMOIpEMAdnA3o2nTka8JLWDxyoWPws-NTWy-99dGdNk6LmRxzBbMw-NSHw$ <https://urldefense.com/v3/__http://www.perimeterinstitute.ca/personal/eschnetter/__;!!DZ3fjg!6h4G9d13wz3CvnZuXtOUn3T5cMOIpEMAdnA3o2nTka8JLWDxyoWPws-NTWy-99dGdNk6LmRxzBbMw-NSHw$> 
> >>> 
> >>>   
> >> 
> >>   
> > 
> > 
> > 
> > -- 
> > My email is as private as my paper mail. I therefore support encrypting
> > and signing email messages. Get my PGP key from https://urldefense.com/v3/__http://keys.gnupg.net__;!!DZ3fjg!7tqgOCho0o2qv2M3wbGJgaL-UlExqMms_TgqHTqS06axk1z1N7PN7DZ-xRG7RjL4tcMN8BrEgpF0V6guM-_619mXG18$  <https://urldefense.com/v3/__http://keys.gnupg.net/__;!!DZ3fjg!7tqgOCho0o2qv2M3wbGJgaL-UlExqMms_TgqHTqS06axk1z1N7PN7DZ-xRG7RjL4tcMN8BrEgpF0V6guM-_6td95u-M$ >.  
> 

-- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://keys.gnupg.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.einsteintoolkit.org/pipermail/users/attachments/20230831/04675733/attachment.sig>