Trac

trac@lists.einsteintoolkit.org

8708 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: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Roland Haas): Thank you. Somewhat ugly unfortunately. 3 #ifdefs spread over the length of the file. Naturally this runs ok on my workstation. I’ll push the change. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-o…

1 0

#2830: CarpetX depends on BLOSC support in ADIOS2 but BLOSC is not in the ET
by Erik Schnetter 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: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Comment (by Erik Schnetter): I confirm that the solution is to handle the option string in `io_openpmd.cxx` in the same way as the Blosc options in `io_adios2.cxx`, i.e. to use an `#ifdef`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-o…

1 0

#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: open Milestone: ET_2024_11 Version: Type: bug Priority: blocker Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-o…

1 0

#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): log file from Anvil testsuite run -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2830/carpetx-depends-o…

1 0

#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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac