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 <hayleyjmacpher...@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: hjmacpher...@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@einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users -- Erik Schnetter <schnet...@gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/ _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
