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 > <[email protected]> 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 <[email protected]> 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 > > <[email protected]> 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: [email protected] > > 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 > > [email protected] > > https://urldefense.com/v3/__http://lists.einsteintoolkit.org/mailman/listinfo/users__;!!DZ3fjg!6h4G9d13wz3CvnZuXtOUn3T5cMOIpEMAdnA3o2nTka8JLWDxyoWPws-NTWy-99dGdNk6LmRxzBagF6wcfg$ > > > > > > > > > > > > -- > > Erik Schnetter <[email protected]> > > 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 http://keys.gnupg.net.
pgp8i4ZiMUWd_.pgp
Description: OpenPGP digital signature
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
