March 2022 - Trac - lists.einsteintoolkit.org

#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

#2531: remove non piraha parser from Flesh
by Roland Haas 10 Mar '22

10 Mar '22

#2531: remove non piraha parser from Flesh Reporter: Roland Haas Status: resolved Milestone: Version: development version Type: enhancement Priority: trivial Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2531/remove-non-piraha…

1 0

#2531: remove non piraha parser from Flesh
by Roland Haas 10 Mar '22

10 Mar '22

#2531: remove non piraha parser from Flesh Reporter: Roland Haas Status: new Milestone: Version: development version Type: enhancement Priority: trivial Component: Comment (by Roland Haas): Applied as git hash [2ba01b5b](https://bitbucket.org/cactuscode/cactus/commits/2ba01b5bb3d1df52f… "Cactus: remove non-Piraha parser" of [cactus](https://bitbucket.org/cactuscode/cactus) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2531/remove-non-piraha…

1 0

#2531: remove non piraha parser from Flesh
by Roland Haas 10 Mar '22

10 Mar '22

#2531: remove non piraha parser from Flesh Reporter: Roland Haas Status: new Milestone: Version: development version Type: enhancement Priority: trivial Component: Comment (by Roland Haas): Please apply. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2531/remove-non-piraha…

1 0

#2531: remove non piraha parser from Flesh
by Roland Haas 10 Mar '22

10 Mar '22

#2531: remove non piraha parser from Flesh Reporter: Roland Haas Status: new Milestone: Version: development version Type: enhancement Priority: trivial Component: Comment (by Roland Haas): Pull request is here: [https://bitbucket.org/cactuscode/cactus/pull-requests/139](https://bitbucke… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2531/remove-non-piraha…

1 0

#2206: make LORENE2 the default LORENE in the ET
by Roland Haas 10 Mar '22

10 Mar '22

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

1 0

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

09 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 Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2599/nsnstohmns-cannot…

1 0

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

09 Mar '22

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

1 0

#2518: retire BlueGene/Q support in thorn vectors
by Roland Haas 07 Mar '22

07 Mar '22

#2518: retire BlueGene/Q support in thorn vectors Reporter: Roland Haas Status: open Milestone: Version: development version Type: task Priority: minor Component: Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2518/retire-bluegene-q…

1 0

#2518: retire BlueGene/Q support in thorn vectors
by Roland Haas 07 Mar '22

07 Mar '22

#2518: retire BlueGene/Q support in thorn vectors Reporter: Roland Haas Status: new Milestone: Version: development version Type: task Priority: minor Component: Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2518/retire-bluegene-q…

1 0

#2518: retire BlueGene/Q support in thorn vectors
by Roland Haas 07 Mar '22

07 Mar '22

#2518: retire BlueGene/Q support in thorn vectors Reporter: Roland Haas Status: new Milestone: Version: development version Type: task Priority: minor Component: Comment (by Roland Haas): Pull request is here: [https://bitbucket.org/cactuscode/cactusutils/pull-requests/38/vectors-remov… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2518/retire-bluegene-q…

1 0

#2590: Uninitialized variable in Perl code
by Roland Haas 07 Mar '22

07 Mar '22

#2590: Uninitialized variable in Perl code Reporter: Erik Schnetter Status: resolved Milestone: Version: development version Type: bug Priority: minor Component: Cactus Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2590/uninitialized-var…

1 0

#2590: Uninitialized variable in Perl code
by Roland Haas 07 Mar '22

07 Mar '22

#2590: Uninitialized variable in Perl code Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Applied as git hash [97419569](https://bitbucket.org/cactuscode/cactus/commits/97419569fbd748131… "Merged in fixuninit $pull request #136$" of [cactus](https://bitbucket.org/cactuscode/cactus) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2590/uninitialized-var…

1 0

#2239: GetComponents --avoid-useless-downloads --propose-system-installs
by Roland Haas 07 Mar '22

07 Mar '22

#2239: GetComponents --avoid-useless-downloads --propose-system-installs Reporter: Boud Roukema Status: wontfix Milestone: Version: Type: proposal Priority: major Component: GetComponents Changes (by Roland Haas): status: wontfix (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2239/getcomponents-avo…

1 0

#2396: potential issue with GitHub svn checkouts on Ubuntu
by Roland Haas 07 Mar '22

07 Mar '22

#2396: potential issue with GitHub svn checkouts on Ubuntu Reporter: Roland Haas Status: closed Milestone: Version: Type: bug Priority: minor Component: GetComponents Changes (by Roland Haas): status: closed (was open) Comment (by Roland Haas): Nothing we can do to fix really, since it is a GitHub problem and nothing we control. Just why it (mostly) affects Ubuntu (and WSL which is also Ubuntu), is not clear. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2396/potential-issue-w…

1 0

#2396: potential issue with GitHub svn checkouts on Ubuntu
by Roland Haas 07 Mar '22

07 Mar '22

#2396: potential issue with GitHub svn checkouts on Ubuntu Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: minor Component: GetComponents Comment (by Roland Haas): The issue most likely still exists but since git hash [be9c164](https://bitbucket.org/einsteintoolkit/manifest/commits/be9c164e050… "[einsteintoolkit.th](http://einsteintoolkit.th): use git checkout for RePrimAnd" of [manifest](https://bitbucket.org/einsteintoolkit/manifest) and git hash [15eac20](github.com/gridaphobe/CRL/commits/15eac20b021480cfe6a41056b0a3f841… "GetComponents: max --shallow and --branch work together $#6$" $sic$ of [CRL](github.com/gridaphobe/CRL) we no longer use svn in the ET thornlist, instead relying on shallow git checkouts. So most likely the issue will no longer happen to new installs. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2396/potential-issue-w…

1 0

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

04 Mar '22

#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 Ken Hui): $Updates$ Okay, it turns out that if I amend some of the parameters in Lorene/C\+\+/Include/unites.h in LORENE2 according to those in LORENE1, I can reproduce the nsnstohmns simulation. But I would still like to know if there is a way to understand how it causes the error in Carpet, and how it can be fixed. Thank you. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2599/nsnstohmns-cannot…

1 0

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

04 Mar '22

#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 I have been using the Lorentz release of EinsteinToolkit to reproduce the simulation nsnstohmns in the ET gallery. Compiling with LORENE1, the simulation works well but I encountered some errors from the Carpet thorn with LORENE2: ``` INFO (NSTracker): Found star at (4.21875,12.0938,0) 29304 824.175 | 126.7906196 | 0.0001241 0.0019978 | 0.0007481 | 1.1329054 | 0.0008567 | 1182 INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 0 INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 1 WARNING level 1 from host chpc-cn024.rc.cuhk.edu.hk process 0 in thorn CarpetLib, file /opt/Cactus/configs/sim/build/CarpetLib/dh.cc:161: -> /opt/Cactus/configs/sim/build/CarpetLib/dh.cc:973: [ml=0 rl=6 c=0] The following grid structure consistency check failed: Synchronisation and boundary prolongation: All points must have been received needrecv.empty() ml=0 rl=6 baseextent=([756,504,756]:[6408,11784,6408]:[4,4,4]/[189,126,189]:[1602,2946,1602]/[1414,2821,1414]/5640296116) ml=0 rl=6 c=0 extent=([756,5748,756]:[932,5916,872]:[4,4,4]/[189,1437,189]:[233,1479,218]/[45,43,30]/58050) outer_boundaries=[[1,0,1],[0,0,0]] processor=0 ... ... ... memoryof(gh)=15396 memoryof(dh)=138360 memoryof(dh.light_boxes)=11304 memoryof(dh.local_boxes)=96952 memoryof(dh.level_boxes)=7328 memoryof(dh.fast_boxes)=16156 #gfs=181 memoryof(gfs)=193316 WARNING level 0 from host chpc-cn024.rc.cuhk.edu.hk process 0 in thorn CarpetLib, file /opt/Cactus/configs/sim/build/CarpetLib/dh.cc:2105: -> The grid structure is inconsistent. It is impossible to continue. 3 total processes killed (some possibly by mpirun during cleanup) Stopping: ``` In previous release$s$, only LORENE2 respect the manual input of eos\_file\_path parameters in Meudon\_Bin\_NS. But now it appears that the problem has been fixed in by: Cactus/arrangements/ExternalLibraries/LORENE/dist/eos\_table\_filepath.patch I wonder if there is no reason to use LORENE2 over LORENE1 anymore, and if someone could provide a hint to fix the above errors arose in Carpet. I am grateful for any help and comments. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2599/nsnstohmns-cannot…

1 0

#2598: thornyflat - production run segmentation fault
by Maria 03 Mar '22

03 Mar '22

#2598: thornyflat - production run segmentation fault Reporter: Maria Status: new Milestone: Version: ET_2021_11 Type: bug Priority: major Component: Comment (by Maria): The helpdesk thinks that is an internal problem with Einstein Toolkit, bug or a bad software design, which has as result not checking for proper allocations. I suspect the problem is in the submit or run files. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2598/thornyflat-produc…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2022