Hi Konrad,
All of the hdf5 2d outputs (e.g. admbase::lapse) include the grid data
as well at each iteration. For these quick things, I tend to use Visit
from LLNL to plot the lapse and the mesh overtop so I can see the
position of the grid as the system evolves. You could likely do the
same plot with something like KuiBit, but I haven't messed with plotting
the grid with that yet.
Also, in the output you just sent, it looks like you are using your
grhydro par file, however, in the grhydro par you sent before, quite a
lot of the puncture tracker settings are commented out including track
puncture.
Finally, the warnings of "the refined region #" is inactive for a
specific surface is also likely a contributor. I'm sure Erik et al are
more knowledgeable on resolving this, but usually this was an issue I
had based on my refinement level and spherical surface setup.
Cheers,
Samuel
On 8/23/21 7:54 PM, Konrad Topolski wrote:
Hi
I cannot set up the tracker correctly in either of these parameter files.
The "pt_loc_" timeseries all display the (0,0,0) position at all times.
The 'NaNMask' data is probably corrupted by simulation shutting down,
as I cannot open it.
What are the "mesh grid variables" exactly that I should use in this
diagnostics and in which thorns should I look for them?
Here's part of the log (common for both simulations in the
PunctureTracker part):
mesh grid variables" that
[...]
INFO (GRHydro): Setting up the atmosphere mask: all points are
not_atmosphere
INFO (PunctureTracker): Tracking punctures...
INFO (PunctureTracker): Puncture #0 is at (17.3774,-0.0975486,0)
INFO (PunctureTracker): Shift at puncture #0 is at (0,0,0)
INFO (AHFinderDirect): proc 0: searching for horizon 1/1
INFO (PunctureTracker): Setting spherical surface 0 centroid from
puncture #0 to (17.3774,-0.0975486,0)
1 0.022 | 6.0400998 | -nan -nan |
-nan -nan | 2516 3089 | 0 0
INFO (CarpetTracker): Setting position of refined region #1 from
surface #0 to (17.3774,-0.0975486,0)
INFO (CarpetTracker): Refined region #2 (depending on surface #1) is
inactive
INFO (PunctureTracker): Tracking punctures...
INFO (PunctureTracker): Puncture #0 is at (17.3774,-0.0975486,0)
INFO (PunctureTracker): Shift at puncture #0 is at (-nan,-nan,-nan)
ERROR from host nid00681 process 0
while executing schedule bin CCTK_EVOL, routine
PunctureTracker::PunctureTracker_Track
in thorn PunctureTracker, file
/lustre/tetyda/home/topolski/Cactus/arrangements/EinsteinAnalysis/PunctureTracker/src/puncture_tracker.cc:204:
-> Shift at puncture #0 is (-nan,-nan,-nan). This likely indicates
an error in the simulation.
I'm also sending the initial data to confirm the initial guess for the
puncture.
Best
niedz., 22 sie 2021 o 08:59 Samuel Tootle <[email protected]
<mailto:[email protected]>> napisał(a):
Hi Konrad,
The matter looks reasonable in all the iterations until the end,
so that's good. Have you looked at the mesh grid to see if both
objects are being tracked properly? You asked about this being a
possibility in your first note, but didn't mention if you looked
at the grid or not.
Cheers,
Samuel
*From: *Konrad Topolski <[email protected]
<mailto:[email protected]>>
*To: *Samuel Tootle <[email protected]
<mailto:[email protected]>>; Einstein Toolkit Users
<[email protected] <mailto:[email protected]>>
*Date: *Aug 21, 2021 23:20:30
*Subject: *Re: [Users] BHNS simulation issues - Hamiltonian
constraint violations and general problems
Hi Sam
I am sending the pictures of the density in a few iterations.
Something indeed goes *very *bad (and possibly in the wrong
direction pretty soon from the start).
But before a chunk of the NS turns into atmosphere it doesn't
look like it would end up like that.
This is rho.maximum:
0 0 0.00181508688452629
16 0.4 0.00181562065714772
32 0.8 0.00181716349263237
48 1.2 0.00181971188439579
64 1.6 0.00182322915996771
80 2 0.00182773078378139
And this is rho.average:
0 0 1.23447090415481e-07
16 0.4 1.2346439769246e-07
32 0.8 1.23490260581956e-07
48 1.2 1.23521771090518e-07
64 1.6 1.23554773904041e-07
80 2 1.23584518348538e-07
sob., 21 sie 2021 o 23:03 Samuel Tootle
<[email protected]
<mailto:[email protected]>> napisał(a):
Hi Konrad,
Have you checked the import of the ID from the hydro point
of view (i.e. plot rho in for the first iterations). If
you see drastic changes in the NS density in the initial
iterations, it usually means the EOS manager isn't
configured correctly which routinely results in the NS
"vanishing" thereby destroying the solution and the
evolution.
Cheers,
Samuel
*From: *Konrad Topolski <[email protected]
<mailto:[email protected]>>
*To: *Einstein Toolkit Users <[email protected]
<mailto:[email protected]>>
*Date: *Aug 21, 2021 22:30:57
*Subject: *[Users] BHNS simulation issues - Hamiltonian
constraint violations and general problems
Hi all
I am trying to run a BH-NS simulation using at least
one of some (and sometimes more) unofficial thors.
That would be Kadath for the initial data and possibly
THC for hydro evolution.
I'm trying to run the simulation either with GRHydro
or with THC.
In both cases I believe that the initial data gets
imported correctly - I have looked at some simple
visuals which I'm attaching to this mail.
However, as the simulation proceeds, huge hamiltonian
constraint violations occur and e.x. the lapse gets
driven to 0 globally. This can also be seen.
How can I help this? Is it because the puncture is not
tracked correctly? Trying to set up a PunctureTracker
at the location of the black hole yields a failure
very soon, as the shift at puncture is said to be
(nan, nan, nan).
I'm sending the .par files, outputs (.out), errors
(.err) and visualization (.png).
Best regards
Konrad
_______________________________________________
Users mailing list
[email protected]
<mailto:[email protected]>
http://lists.einsteintoolkit.org/mailman/listinfo/users
<http://lists.einsteintoolkit.org/mailman/listinfo/users>
_______________________________________________
Users mailing list
[email protected]
http://lists.einsteintoolkit.org/mailman/listinfo/users
