Trac November 2024

trac@lists.einsteintoolkit.org

1 participants
106 discussions

#2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET
by Roland Haas 11 Nov '24

11 Nov '24

#2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET Reporter: Roland Haas Status: resolved Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): This seems to cause test failures on Anvil, likely due to some leftover option string \(which I had hoped would be harmless\). The first line of the attached log file says that ADIOS2 is continuing without compression but then it still seems to abort: ```text Warning: ADIOS2 backend does not support compression method blosc. Continuing without compression. Original error: [1;36m[Fri Nov 08 21:18:08 2024][1;34m [ADIOS2 EXCEPTION][0m <Operator> <OperatorFactory> <MakeOperator> : ADIOS2 didn't compile with blosc library, operator not added[0m Warning: ADIOS2 backend does not support compression method blosc. Continuing without compression. Original error: [1;36m[Fri Nov 08 21:18:08 2024][1;34m [ADIOS2 EXCEPTION][0m <Operator> <OperatorFactory> <MakeOperator> : ADIOS2 didn't compile with blosc library, operator not added[0m [a566:2717461] *** An error occurred in MPI_Win_allocate_shared [a566:2717461] *** reported by process [4252828002,1] [a566:2717461] *** on communicator MPI COMMUNICATOR 8 SPLIT FROM 6 [a566:2717461] *** MPI_ERR_INTERN: internal error [a566:2717461] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, [a566:2717461] *** and potentially your MPI job) In: PMI_Abort(17, N/A) slurmstepd: error: *** STEP 8387965.354 ON a566 CANCELLED AT 2024-11-08T21:18:08 *** srun: Job step aborted: Waiting up to 32 seconds for job step to finish. srun: error: a566: tasks 0-1: Killed ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-o…

1 0

#2834: Baikal regeneration instruction in README fail
by Zach Etienne 08 Nov '24

08 Nov '24

#2834: Baikal regeneration instruction in README fail Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: major Component: Comment (by Zach Etienne): Fixed in commit 82cde4590a280b477e744f6b5468595c79504b0f . Changelog entry for this commit: ``` Sync Baikal* with NRPy-main and add Makefile-baikal_thorns - Synced WVUThorns/Baikal* with NRPy-main, including: - Implemented computation of the squared momentum constraint (MSQUAREDGF). - Sorted parameters in `param.ccl` in a case-insensitive alphabetical order. - Replaced `pow(x, -1/6)` with `1 / sqrt(cbrt(x))` for enhanced performance. - Updated function-level comment blocks to start with `/**` instead of `/*` to enable `@param` syntax highlighting in IDEs (Emacs & VSCode). - Tidied up `simd/simd_intrinsics.h` and added new intrinsics for future ET NRPy projects. - Added `WVUThorns/Makefile-baikal_thorns` to regenerate Baikal* thorns from a trusted NRPy commit. ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regenerati…

1 0

#2834: Baikal regeneration instruction in README fail
by Zach Etienne 08 Nov '24

08 Nov '24

#2834: Baikal regeneration instruction in README fail Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: major Component: Comment (by Zach Etienne): I agree that a Makefile would be most helpful. I’ll just do that. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regenerati…

1 0

#2175: Test "Single, stable neutron star" example
by David Boyer 08 Nov '24

08 Nov '24

#2175: Test "Single, stable neutron star" example Reporter: Roland Haas Status: open Milestone: ET_2024_11 Version: development version Type: task Priority: major Component: EinsteinToolkit website Comment (by David Boyer): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} I’m trying to upload the results to [https://bitbucket.org/einsteintoolkit/www/downloads/](https://bitbucket.org…, but it’s saying I don’t have write permission and won’t let me upload. It looks like I still don’t have write permission. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2175/test-single-stabl…

1 0

#2520: update gauge settings in TOV example to be more typical
by David Boyer 08 Nov '24

08 Nov '24

#2520: update gauge settings in TOV example to be more typical Reporter: Roland Haas Status: open Milestone: ET_2023_11 Version: development version Type: enhancement Priority: major Component: Comment (by David Boyer): I have ran these tests with the new gauge settings in the current development, and these will be the updated gallery examples for the 11\_2024 release. I will note that before the changes to the parfiles were made, I did test the original gallery example, and the results were the same as before. Any observed changes in the gallery example of these new parfiles came due purely to the change in the gauge settings, as nothing else is different from the original parfiles. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2520/update-gauge-sett…

1 0

#2834: Baikal regeneration instruction in README fail
by Roland Haas 08 Nov '24

08 Nov '24

#2834: Baikal regeneration instruction in README fail Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: major Component: Comment (by Roland Haas): These changes are all fine and there is nothing wrong with the generated Baikal\* code updating during the release lifetime. What I am after is to have a way for the release manager and potential Baikal\* users to generate the C code from the original Python code. So that in case one has bug fixes to propose one can actually start from the real source code and not something unknown. Having the full thorn be generated with just a single command is very useful for the release manager since they have to generate very many thorns and if each one required a dozen manual steps \(worst would be “edit this file …”\), then this becomes very time consuming. The Kranc generated files uniformly require that one does `make` in the the `m` directory which contains the actual source code. RIght now with Baikal it seems that the source used is in `nrpy` and stored in some, to most users, unknown directory in `~/.local` unless one uses a virtualenv. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regenerati…

1 0

#2834: Baikal regeneration instruction in README fail
by Zach Etienne 08 Nov '24

08 Nov '24

#2834: Baikal regeneration instruction in README fail Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: major Component: Comment (by Zach Etienne): Largely this is a README issue: Only codes requiring NRPy generation will populate the thorns, so test/ doc/ and par/ will not be populated just by running NRPy. Instead, src/ and \*.ccl files should be deleted in the thorns and replaced with generated codes. The README should be updated to reflect this. In addition, there have been some minor reshufflings to improve maintainability, diagnostics, and performance, including 1. computing the squared momentum constraint \(MSQUAREDGF\). 2. sorting the parameters in param.ccl in a case-insensitive alphabetical way. 3. replacing pow\(x, -1/6\) with 1 / sqrt\(cbrt\(x\)\) \(it is faster!\) 4. Starting all function-level comment blocks with /\*\* instead of /\* . This enables syntax highlighting of @param \[parameter name\] in all IDEs I tried \(emacs & vscode\). 5. simd/simd\_intrinsics.h has been tidied up a bit, and a few new intrinsics \(currently unused by Baikal\*, but used by other \[future ET\] NRPy projects\) were added. The above changes reflect the Baikal\* thorns in the latest `NRPy-main`. Should I proceed in updating the README to use this? There is no functional change. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regenerati…

1 0

#2834: Baikal regeneration instruction in README fail
by Roland Haas 08 Nov '24

08 Nov '24

#2834: Baikal regeneration instruction in README fail Reporter: Roland Haas Status: new Milestone: ET_2024_11 Version: Type: bug Priority: major Component: README says: > 4. Regenerating these thorns > > Baikal and BaikalVacuum can be automatically generated via > > pip install git\+[https://github.com/nrpy/nrpy.git@79774f69b2911fe5729b2d256c7e1fe754c2… python3 -m nrpy.examples.carpet\_baikal\_thorns > > The second command will generate the thorns in project/et\_baikal/ > and can then be copied into the WVUThorns directory. Yet following these I am missing the `test`, `doc` and `par` directories as well as the `README` file and get very many differences. Most of the differences are harmless \(comments\) but same changes affect `CCTK_ATTRIBUTE_NOINLINE` which, being something that Zach found to be required to cut down compilation time, is important. So currently I cannot regenerate the Baikal thorns. ‌ attachment: vacuum.diff (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) attachment: matter.diff (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2834/baikal-regenerati…

1 0

#2818: failing tests with gcc-14
by Roland Haas 08 Nov '24

08 Nov '24

#2818: failing tests with gcc-14 Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Failing tests have been addressed in git hash [81e426ff](https://github.com/EinsteinToolkit/CarpetX/commits/81e426ffe9bdfe… "Loop: explicitly create function args to avoid compiler issue" of [CarpetX](https://github.com/EinsteinToolkit/CarpetX) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-wit…

1 0

#2818: failing tests with gcc-14
by Roland Haas 08 Nov '24

08 Nov '24

#2818: failing tests with gcc-14 Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Pull request for original issue \(failing tests\) is [https://github.com/EinsteinToolkit/CarpetX/pull/319](https://github.com/Ein… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2818/failing-tests-wit…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2024