#2554: init_3_timelevels produces nans on past timelevels of the initial slice
Reporter: Yosef Zlochower
Status: open
Milestone:
Version: ET_2021_05
Type: bug
Priority: minor
Component: Carpet
Comment (by Roland Haas):
@{557058:d079f9c2-ad27-47b2-bf4b-ecc6bbe288b0} any news on this?
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2554/init_3_timelevels…
#2599: nsnstohmns cannot be reproduced using LORENE2
Reporter: Ken Hui
Status: open
Milestone: ET_2021_05
Version: ET_2021_05
Type: bug
Priority: minor
Component: Cactus
Comment (by Roland Haas):
Thanks for the update. The changes in solar mass and and gravitational constant I can understand \(and expect\). Though how can MeV in Joule change? It’s essentially the electron charge which I would have expected to be very well known.
I agree that the plots are not directly useful. The interesting bit would be that failure happens once the central density rises ie star start to interact.
Another useful plot, since the grid structure is what fails would be a plot of the grid structure. Eg using the plot-bboxes tool in [https://bitbucket.org/eschnett/carpet/src/master/Carpet/src/util/plot-bboxe… It expects as input one of Carpet’s `carpet-grid-structure` files:
```
> gnuplot
$ load "plot-bboxes"
```
then paste \(since it reads from `/dev/tty`\) one of the sections from the grid structure file, eg:
```
iteration 0
maps 1
0 mglevels 1
0 0 reflevels 3
0 0 0 components 2
0 0 0 0 0 ([0,0,0]:[136,136,68]:[4,4,4]/[0,0,0]:[34,34,17]/[35,35,18]/22050) [[1,1,1],[1,1,0]]
0 0 0 1 1 ([0,0,72]:[136,136,136]:[4,4,4]/[0,0,18]:[34,34,34]/[35,35,17]/20825) [[1,1,0],[1,1,1]]
0 0 1 components 2
0 0 1 0 0 ([36,36,36]:[100,100,68]:[2,2,2]/[18,18,18]:[50,50,34]/[33,33,17]/18513) [[0,0,0],[0,0,0]]
0 0 1 1 1 ([36,36,70]:[100,100,100]:[2,2,2]/[18,18,35]:[50,50,50]/[33,33,16]/17424) [[0,0,0],[0,0,0]]
0 0 2 components 2
0 0 2 0 0 ([52,52,52]:[84,84,68]:[1,1,1]/[52,52,52]:[84,84,68]/[33,33,17]/18513) [[0,0,0],[0,0,0]]
0 0 2 1 1 ([52,52,69]:[84,84,84]:[1,1,1]/[52,52,69]:[84,84,84]/[33,33,16]/17424) [[0,0,0],[0,0,0]]
```
which should produce this plot:

This may also be possible with a dedicated Cactus analysis package like SimulationTools or Kuibit or PyCactus/PostCactus listed on [https://docs.einsteintoolkit.org/et-docs/Analysis\_and\_post-processing](ht… .
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2599/nsnstohmns-cannot…
#2599: nsnstohmns cannot be reproduced using LORENE2
Reporter: Ken Hui
Status: open
Milestone: ET_2021_05
Version: ET_2021_05
Type: bug
Priority: minor
Component: Cactus
Comment (by Ken Hui):
I followed the particular ticket you mentioned to plot the Psi4 and maximum density, but I don’t think they give any information related to the failure of the simulation.


lorentz\_lorene1: Lorentz release compiled with LORENE
lorentz\_lorene2: … LORENE2 \(the one giving the Carpet error\)
lorentz\_lorene2\_amend: … LORENE2, but with some changes in `unites.h`
The values of the density differ even at the first step between lorentz\_lorene1 and lorentz\_lorene2, which is caused by differences in some physical constants, so I amended some numbers in `unites.h` of LORENE2 to match that of LORENE.
```
--- lorene2_unites.h.ori 2022-03-11 02:08:27.660497092 +0800
+++ lorene2_unites.h.amend 2022-03-11 02:03:28.053007609 +0800
@@ -78,13 +78,13 @@
* and black holes.\ingroup (unites)
*/
namespace Unites {
- const double g_si = 6.6738E-11 ; ///< Newton gravitational constant [SI]
+ const double g_si = 6.6726E-11 ; ///< Newton gravitational constant [SI]
const double c_si = 2.99792458E+8 ; ///< Velocity of light [m/s]
const double kB_si = 1.3806488E-23 ; ///< Boltzmann constant [J/K]
const double rhonuc_si = 1.66E+17 ; ///< Nuclear density [kg/m3] (arbitrary)
const double km_si = 1.E+3 ; ///< One kilometer [m]
- const double msol_si = 1.9885E+30 ; ///< Solar mass [kg]
- const double mev_si = 1.602176565E-13 ; ///< One MeV [J]
+ const double msol_si = 1.989E+30 ; ///< Solar mass [kg]
+ const double mev_si = 1.6021892E-13 ; ///< One MeV [J]
const double r_unit = 1.e4 ; ///< Lorene's unit of length = 10 km
const double v_unit = c_si ; ///< Lorene's unit of velocity = c
```
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2599/nsnstohmns-cannot…
#2206: make LORENE2 the default LORENE in the ET
Reporter: Roland Haas
Status: new
Milestone:
Version: development version
Type: enhancement
Priority: minor
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
See #2599 for a potential issue.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2206/make-lorene2-the-…
#2599: nsnstohmns cannot be reproduced using LORENE2
Reporter: Ken Hui
Status: open
Milestone: ET_2021_05
Version: ET_2021_05
Type: bug
Priority: minor
Component: Cactus
Changes (by Roland Haas):
status: open (was new)
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2599/nsnstohmns-cannot…
#2599: nsnstohmns cannot be reproduced using LORENE2
Reporter: Ken Hui
Status: new
Milestone: ET_2021_05
Version: ET_2021_05
Type: bug
Priority: minor
Component: Cactus
Comment (by Roland Haas):
The error you see is very late and really related to the grid structure \(and really should never happen\).
We had some instances of small changes in initial data changing results of the BNS gallery example at very late times \(close to merger\), though never really in a production setup. This is discussed in ticket #2119 . It is very low resolution so some fragility is expected though this change is a bit unexpected.
Can you check that the results up to the point of failure are “sane”?
Can you provide a “diff” of the changes you made to `unites.h`, please?
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2599/nsnstohmns-cannot…