Trac March 2022

trac@lists.einsteintoolkit.org

1 participants
48 discussions

#2554: init_3_timelevels produces nans on past timelevels of the initial slice
by Roland Haas 14 Mar '22

14 Mar '22

#2554: init_3_timelevels produces nans on past timelevels of the initial slice Reporter: Yosef Zlochower Status: resolved Milestone: Version: ET_2021_05 Type: bug Priority: minor Component: Carpet Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2554/init_3_timelevels…

1 0

#2554: init_3_timelevels produces nans on past timelevels of the initial slice
by Roland Haas 14 Mar '22

14 Mar '22

#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): Applied as git hash [cfb236a4](https://bitbucket.org/eschnett/carpet/commits/cfb236a46e936fdd549… "Carpet: evolve level by level in init3tl" of [carpet](https://bitbucket.org/eschnett/carpet) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2554/init_3_timelevels…

1 0

#2554: init_3_timelevels produces nans on past timelevels of the initial slice
by Roland Haas 14 Mar '22

14 Mar '22

#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} says $private email$: The fix works for me. I no longer get Nans in the output files. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2554/init_3_timelevels…

1 0

#2596: EinsteinInitialData/TwoPunctures: Allocated memory is not freed
by Roland Haas 14 Mar '22

14 Mar '22

#2596: EinsteinInitialData/TwoPunctures: Allocated memory is not freed Reporter: Zach Etienne Status: open Milestone: Version: development version Type: bug Priority: major Component: Changes (by Roland Haas): assignee: Zach Etienne (was ) responsible: [] (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2596/einsteininitialda…

1 0

#2596: EinsteinInitialData/TwoPunctures: Allocated memory is not freed
by Roland Haas 14 Mar '22

14 Mar '22

#2596: EinsteinInitialData/TwoPunctures: Allocated memory is not freed Reporter: Zach Etienne Status: open Milestone: Version: development version Type: bug Priority: major Component: Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2596/einsteininitialda…

1 0

#2596: EinsteinInitialData/TwoPunctures: Allocated memory is not freed
by Roland Haas 14 Mar '22

14 Mar '22

#2596: EinsteinInitialData/TwoPunctures: Allocated memory is not freed Reporter: Zach Etienne Status: new Milestone: Version: development version Type: bug Priority: major Component: Comment (by Roland Haas): Can you provide a diff instead of the edited file, please? The edited file makes it harder to see what was actually changed and thus review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2596/einsteininitialda…

1 0

#2599: nsnstohmns cannot be reproduced using LORENE2
by Ken Hui 11 Mar '22

11 Mar '22

#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): The definition of those 3 physical constants do not match between LORENE1 and LORENE2. The initial data of the gallery simulation nsnstohmns is $I supposed$ taken from [https://lorene.obspm.fr/data/binNS.html](https://lorene.obspm.fr/data/binNS…, which should have been generated with an older LORENE version. That’s why I tried to change the physical constants in LORENE2, to recover their old values. ``` --- lorene1_unites.h.ori 2022-03-11 13:14:02.810753230 +0800 +++ lorene2_unites.h.ori 2022-03-11 02:08:27.660497092 +0800 @@ -26,8 +26,20 @@ /* - * $Id: unites.h,v 1.4 2004/12/01 12:28:32 p_grandclement Exp $ + * $Id: unites.h,v 1.8 2015/03/17 14:20:00 j_novak Exp $ * $Log: unites.h,v $ + * Revision 1.8 2015/03/17 14:20:00 j_novak + * New class Hot_eos to deal with temperature-dependent EOSs. + * + * Revision 1.7 2014/10/13 08:52:37 j_novak + * Lorene classes and functions now belong to the namespace Lorene. + * + * Revision 1.6 2014/06/30 14:34:57 j_novak + * Update of the values of some constants (G, M_sol and MeV). + * + * Revision 1.5 2014/05/13 10:06:12 j_novak + * Change of magnetic units, to make the Lorene unit system coherent. Magnetic field is now expressed in Lorene units. Improvement on the comments on units. + * * Revision 1.4 2004/12/01 12:28:32 p_grandclement * Include math.h in unite.h * @@ -47,50 +59,55 @@ * Initial revision * * - * $Header: /cvsroot/Lorene/C++/Include/unites.h,v 1.4 2004/12/01 12:28:32 p_grandclement Exp $ + * $Header: /cvsroot/Lorene/C++/Include/unites.h,v 1.8 2015/03/17 14:20:00 j_novak Exp $ ``` Indeed I have tried to update the values of G, M\_sol and MeV in LORENE1 according to the 2014 revision, recompile ET and run the nsnstohmns simulations. The Carpet errors came up again at the exact same time step. For the plot of the grids, I am having problem visualising it in gnuplot. Allow me to attach the raw output here for the moment, I will also try to see if I can plot them using other methods later. [https://drive.google.com/drive/folders/1iutL\_5avKqVTQxDCvqb8dIY5QwB6A\_PN?… ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2599/nsnstohmns-cannot…

1 0

#2554: init_3_timelevels produces nans on past timelevels of the initial slice
by Roland Haas 10 Mar '22

10 Mar '22

#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…

1 0

#2599: nsnstohmns cannot be reproduced using LORENE2
by Roland Haas 10 Mar '22

10 Mar '22

#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: ![](https://bitbucket.org/repo/8zBLME5/images/1133471296-image.png) 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…

1 0

#2599: nsnstohmns cannot be reproduced using LORENE2
by Ken Hui 10 Mar '22

10 Mar '22

#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. ![](https://bitbucket.org/repo/8zBLME5/images/2417778790-Psi4_compare.png) ![](https://bitbucket.org/repo/8zBLME5/images/2427778410-dens_compare.png) 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…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2022