Trac September 2022

trac@lists.einsteintoolkit.org

1 participants
67 discussions

#2645: Major update to Baikal/BaikalVacuum
by Zach Etienne 22 Sep '22

22 Sep '22

#2645: Major update to Baikal/BaikalVacuum Reporter: Zach Etienne Status: new Milestone: Version: Type: enhancement Priority: major Component: Changes (by Zach Etienne): First off, there are no new features or new parameters/parameter defaults in this update. All math kernels are identical as well. This is strictly the result of a modernization of the code generation infrastructure. The codegen of `Baikal` and `BaikalVacuum` has been updated to conform to the latest NRPy\+ standards, which emphasize registration of C functions with NRPy\+ instead of oodles of `.h` files that can be hard to track. Parallel codegen is far more robust, and maintainability has been greatly improved \(`./run_Jupyter_notebook.sh Tutorial-ETK_thorn-BaikalETK.ipynb` is the only means to generate the thorns; before the Jupyter notebook contents were completely copied into separate Python modules\). Here are the steps needed to validate this latest version against the original: 1. Clone the latest NRPy\+ repo: git clone [https://github.com/zachetienne/nrpytutorial.git](https://github.com/zacheti… 2. Make sure you have jupyter and sympy installed \(pip install jupyter sympy\) 3. Make sure you have downloaded the latest ET _release_ [https://einsteintoolkit.org/download.html](https://einsteintoolkit.org/down… 4. Go into the nrpytutorial directory and type ./convert\_jupyter\_to\_python\_and\_run.sh Tutorial-ETK\_thorn-BaikalETK.ipynb 5. Step 4 above should've generated the updated Baikal & BaikalVacuum thorns. 6. E.g., go into BaikalVacuum/src/ and diff a RHS file against the latest ET release version via: diff -w rhs\_eval\_BaikalVacuum\_order\_4.c \[path to latest ET release\]/arrangements/WVUThorns/BaikalVacuum/src/BSSN\_RHSs\_enable\_Tmunu\_False\_FD\_order\_4.c notice that -w ignores whitespace differences, which is important since the latest version does proper tabbing. You'll see that the math kernel is _identical_, and the only differences include things like adding CCTK\_ATTRIBUTE\_UNUSED to various automatically generated constants, which may not be used and using NGHOSTS=cctk\_nghostzones\[0\] consistently. Other RHS orders, Ricci evaluations, and constraint calculations can be compared in a similar fashion. The pull request is here: [https://bitbucket.org/zach\_etienne/wvuthorns/pull-requests/12/modernize-ba… I will merge this pull request on Tuesday Sept 27, unless there are objections. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2645/major-update-to-b…

1 0

#2645: Major update to Baikal/BaikalVacuum
by Zach Etienne 22 Sep '22

22 Sep '22

#2645: Major update to Baikal/BaikalVacuum Reporter: Zach Etienne Status: new Milestone: Version: Type: enhancement Priority: major Component: First off, there are no new features or new parameters/parameter defaults in this update. All math kernels are identical as well. This is strictly the result of a modernization of the code generation infrastructure. The codegen of `Baikal` and `BaikalVacuum` has been updated to conform to the latest NRPy\+ standards, which emphasize registration of C functions with NRPy\+ instead of oodles of `.h` files that can be hard to track. Parallel codegen is far more robust, and maintainability has been greatly improved \(`./run_Jupyter_notebook.sh Tutorial-ETK_thorn-BaikalETK.ipynb` is the only means to generate the thorns; before the Jupyter notebook contents were completely copied into separate Python modules\). Here are the steps needed to validate this latest version against the original: 1. Clone the latest NRPy\+ repo: git clone [https://github.com/zachetienne/nrpytutorial.git](https://github.com/zacheti… 2. Make sure you have jupyter and sympy installed \(pip install jupyter sympy\) 3. Make sure you have downloaded the latest ET _release_ [https://einsteintoolkit.org/download.html](https://einsteintoolkit.org/down… 4. Go into the nrpytutorial directory and type ./convert\_jupyter\_to\_python\_and\_run.sh Tutorial-BaikalETK\_new\_way.ipynb 5. Step 4 above should've generated the updated Baikal & BaikalVacuum thorns. 6. E.g., go into BaikalVacuum/src/ and diff a RHS file against the latest ET release version via: diff -w rhs\_eval\_BaikalVacuum\_order\_4.c \[path to latest ET release\]/arrangements/WVUThorns/BaikalVacuum/src/BSSN\_RHSs\_enable\_Tmunu\_False\_FD\_order\_4.c notice that -w ignores whitespace differences, which is important since the latest version does proper tabbing. You'll see that the math kernel is _identical_, and the only differences include things like adding CCTK\_ATTRIBUTE\_UNUSED to various automatically generated constants, which may not be used and using NGHOSTS=cctk\_nghostzones\[0\] consistently. Other RHS orders, Ricci evaluations, and constraint calculations can be compared in a similar fashion. The pull request is here: [https://bitbucket.org/zach\_etienne/wvuthorns/pull-requests/12/modernize-ba… I will merge this pull request on Tuesday Sept 27, unless there are objections. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2645/major-update-to-b…

1 0

#2644: NaNs in ADMBASE metric components with RNSID
by Davide Guerra 22 Sep '22

22 Sep '22

#2644: NaNs in ADMBASE metric components with RNSID Reporter: Davide Guerra Status: new Milestone: ET_2022_11 Version: ET_2022_11 Type: bug Priority: critical Component: EinsteinToolkit thorn I have found a problem related to a parfile that I am attaching here. I used the same parfile with the version of ET 2019\_10 “Mayer” having no problems at all, and the latest version of ET having the problem with the presence of NaNs in the ADMBASE:gij where ij are all the components of g. It happens after creating the initial data with HYDRO\_RNSID which I checked to be the same between this latest simulation and the previous one with the old version of ET. Therefore, I attach here the parfile, the .out and the .err files that I used. They refers to the model D2 written in Table I studied by Luca Baiotti et al in the paper “[Accurate simulations of the dynamical bar-mode instability in full General Relativity](https://arxiv.org/pdf/astro-ph/0609473.pdf)” Thank you in advance. ‌ attachment: D2_test.out (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2644/nans-in-admbase-m…

1 0

#2642: Toolkit Fails to Compile on Sawtooth (Idaho National Lab)
by Roland Haas 21 Sep '22

21 Sep '22

#2642: Toolkit Fails to Compile on Sawtooth (Idaho National Lab) Reporter: Leonardo Werneck Status: new Milestone: Version: ET_2022_11 Type: bug Priority: major Component: Comment (by Roland Haas): This is the sympton caused by using an outdated stdc\+\+ template [library. In](http://library.In) you fix you are basically re-introducing the compatibility hacks \(more or less\) that we have just removed from Cactus. A better fix for the compilation failure is to make sure that icpc uses a new enough g\+\+ \(and its STL library\) by passing a `-gxx-name` option and the path to a new enough g\+\+. If on the other hand you really want an isnan that persists even when -Ofast is used \(though you are defeating the Ofast purpose in that case and with Ofast there just may not be any NaN produce in a consitent way to begin with\) you could use your change. But it addresses a different issue than the compilation failure I think. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2642/toolkit-fails-to-…

1 0

#2643: Adding read/write declarations to Meudon ID thorns
by Samuel Cupp 21 Sep '22

21 Sep '22

#2643: Adding read/write declarations to Meudon ID thorns Reporter: Samuel Cupp Status: new Milestone: Version: development version Type: task Priority: minor Component: EinsteinToolkit thorn I’ve opened a pull request which adds the read/write declarations and new macros to the three Meudon ID thorns in einsteininitialdata. The pull request: [https://bitbucket.org/einsteintoolkit/einsteininitialdata/pull-requests/15/… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2643/adding-read-write…

1 0

#2642: Toolkit Fails to Compile on Sawtooth (Idaho National Lab)
by Leonardo Werneck 21 Sep '22

21 Sep '22

#2642: Toolkit Fails to Compile on Sawtooth (Idaho National Lab) Reporter: Leonardo Werneck Status: new Milestone: Version: ET_2022_11 Type: bug Priority: major Component: Comment (by Leonardo Werneck): @{557058:8bc23f2a-45c0-477d-8ac4-a5a16c734278} @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} The fix to `IllinoisGRMHD` is proposed here: [https://bitbucket.org/zach\_etienne/wvuthorns/pull-requests/9](https://bitb…. Please review the request at your earliest convenience. This fix was already part of the version of IllinoisGRMHD that supports tabulated equations of state. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2642/toolkit-fails-to-…

1 0

#2642: Toolkit Fails to Compile on Sawtooth (Idaho National Lab)
by Leonardo Werneck 21 Sep '22

21 Sep '22

#2642: Toolkit Fails to Compile on Sawtooth (Idaho National Lab) Reporter: Leonardo Werneck Status: new Milestone: Version: ET_2022_11 Type: bug Priority: major Component: Changes (by Leonardo Werneck): component: (was Carpet) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2642/toolkit-fails-to-…

1 0

#2642: Toolkit Fails to Compile on Sawtooth (Idaho National Lab)
by Leonardo Werneck 21 Sep '22

21 Sep '22

#2642: Toolkit Fails to Compile on Sawtooth (Idaho National Lab) Reporter: Leonardo Werneck Status: new Milestone: Version: ET_2022_11 Type: bug Priority: major Component: Carpet Compilation of the Riemann release of the toolkit fails with the Intel-19.0.5 compiler on Sawtooth \(Idaho National Lab\). Attached is the full configuration used for the compilation \(sawtooth-intel19.cfg\). The compilation errors are the following: ``` /home/rosaleon/sawtooth/test_compile/Cactus/arrangements/Carpet/CarpetMask/src/mask_surface.cc(144): error: more than one instance of overloaded function "CarpetMask::isnan" matches the argument list: function "isnan(double)" function "std::isnan(double)" argument types are: (CCTK_REAL8) assert(not isnan(theta)); ^ /home/rosaleon/sawtooth/test_compile/Cactus/arrangements/Carpet/CarpetMask/src/mask_surface.cc(160): error: more than one instance of overloaded function "CarpetMask::isnan" matches the argument list: function "isnan(double)" function "std::isnan(double)" argument types are: (CCTK_REAL8) assert(not isnan(phi)); ^ Checking status of thorn IllinoisGRMHD compilation aborted for /home/rosaleon/sawtooth/test_compile/Cactus/configs/intel19/build/CarpetMask/mask_surface.cc (code 2) make[4]: *** [mask_surface.cc.o] Error 2 make[3]: *** [make.checked] Error 2 make[2]: *** [/home/rosaleon/sawtooth/test_compile/Cactus/configs/intel19/lib/libthorn_CarpetMask.a] Error 2 make[2]: *** Waiting for unfinished jobs.... COMPILING WVUThorns/IllinoisGRMHD/src/driver_conserv_to_prims.C /home/rosaleon/sawtooth/test_compile/Cactus/arrangements/WVUThorns/IllinoisGRMHD/src/driver_conserv_to_prims.C(204): error: more than one instance of overloaded function "isnan" matches the argument list: function "isnan(double)" function "std::isnan(double)" argument types are: (double) if(isnan(CONSERVS[RHOSTAR]*CONSERVS[STILDEX]*CONSERVS[STILDEY]*CONSERVS[STILDEZ]*CONSERVS[TAUENERGY]*PRIMS[BX_CENTER]*PRIMS[BY_CENTER]*PRIMS[BZ_CENTER])) { ^ compilation aborted for /home/rosaleon/sawtooth/test_compile/Cactus/configs/intel19/build/IllinoisGRMHD/driver_conserv_to_prims.C (code 2) make[4]: *** [driver_conserv_to_prims.C.o] Error 2 make[3]: *** [make.checked] Error 2 make[2]: *** [/home/rosaleon/sawtooth/test_compile/Cactus/configs/intel19/lib/libthorn_IllinoisGRMHD.a] Error 2 make[1]: *** [intel19] Error 2 make: *** [default-target] Error 2 Using the only available configuration: intel19. ^Cmake[1]: *** [intel19] Interrupt make: *** [default-target] Interrupt ``` I am currently working on a pull request to fix the issue in `IllinoisGRMHD`. Cheers, Leo attachment: sawtooth-intel19.cfg (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2642/toolkit-fails-to-…

1 0

#2641: ML_BSSN macro usage bypasses personalized read/write macros
by Samuel Cupp 20 Sep '22

20 Sep '22

#2641: ML_BSSN macro usage bypasses personalized read/write macros Reporter: Samuel Cupp Status: new Milestone: Version: development version Type: bug Priority: trivial Component: Kranc The new macros are designed to only give access to the variables listed by read/write declarations, but ML\_BSSN bypasses this sanity check with its \*\_Body internal functions. As an example, in ML\_BSSN/src/ML\_BSSN\_ADMBaseInterior.cc is the scheduled function ``` extern "C" void ML_BSSN_ADMBaseInterior(CCTK_ARGUMENTS) { #ifdef DECLARE_CCTK_ARGUMENTS_ML_BSSN_ADMBaseInterior DECLARE_CCTK_ARGUMENTS_CHECKED(ML_BSSN_ADMBaseInterior); #else DECLARE_CCTK_ARGUMENTS; #endif DECLARE_CCTK_PARAMETERS; ``` which then calls ``` static void ML_BSSN_ADMBaseInterior_Body(const cGH* restrict const cctkGH, const int dir, const int face, const CCTK_REAL normal[3], const CCTK_REAL tangentA[3], const CCTK_REAL tangentB[3], const int imin[3], const int imax[3], const int n_subblock_gfs, CCTK_REAL* restrict const subblock_gfs[]) { DECLARE_CCTK_ARGUMENTS; DECLARE_CCTK_PARAMETERS; ``` The various \*\_Body should \(ideally\) either have their required variables passed explicitly or use the macro of the parent function. While the two macros don’t produce different numerical results, the personalized macros help validate the code’s behavior. It is admittedly a pretty low-priority task, but using the new macro is preferred when possible. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2641/ml_bssn-macro-usa…

1 0

#2640: NRPyEllipticET fails to compile on Stampede2
by Roland Haas 20 Sep '22

20 Sep '22

#2640: NRPyEllipticET fails to compile on Stampede2 Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: blocker Component: Changes (by Roland Haas): status: resolved (was new) Comment (by Roland Haas): this commit seems to fix the issue (at least on stampede2-skx). Thank you for the quick bugfix. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2640/nrpyellipticet-fa…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2022