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]
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>
>
>
>
> --
> Erik Schnetter <[email protected]>
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
>


-- 
Erik Schnetter <[email protected]>
http://www.perimeterinstitute.ca/personal/eschnetter/
_______________________________________________
Users mailing list
[email protected]
http://lists.einsteintoolkit.org/mailman/listinfo/users

Reply via email to