Trac November 2025

trac@lists.einsteintoolkit.org

1 participants
45 discussions

#2901: ExternalLibraries-ADIOS2: detect.sh adds nonexistent MPI libraries if ADIOS2_ENABLE_SST == yes when using external ADIOS2
by Roland Haas 17 Nov '25

17 Nov '25

#2901: ExternalLibraries-ADIOS2: detect.sh adds nonexistent MPI libraries if ADIOS2_ENABLE_SST == yes when using external ADIOS2 Reporter: Miren Radia Status: open Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Roland Haas): responsible: [] (was ) assignee: Roland Haas (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2901/externallibraries…

1 0

#2901: ExternalLibraries-ADIOS2: detect.sh adds nonexistent MPI libraries if ADIOS2_ENABLE_SST == yes when using external ADIOS2
by Roland Haas 17 Nov '25

17 Nov '25

#2901: ExternalLibraries-ADIOS2: detect.sh adds nonexistent MPI libraries if ADIOS2_ENABLE_SST == yes when using external ADIOS2 Reporter: Miren Radia Status: open Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was submitted) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2901/externallibraries…

1 0

#2901: ExternalLibraries-ADIOS2: detect.sh adds nonexistent MPI libraries if ADIOS2_ENABLE_SST == yes when using external ADIOS2
by Miren Radia 17 Nov '25

17 Nov '25

#2901: ExternalLibraries-ADIOS2: detect.sh adds nonexistent MPI libraries if ADIOS2_ENABLE_SST == yes when using external ADIOS2 Reporter: Miren Radia Status: submitted Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Changes (by Miren Radia): I opened [an issue in the GitHub repository](https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2/iss… but am opening this ticket here as suggested by Roland Haas. The GitHub issue description is below In the case `ADIOS2_ENABLE_SST == yes`, after [this line](https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2/blob/c45b… ```shell ADIOS2_REQ_LIBRARIES="adios2_cxx11 adios2_c adios2_core adios2_evpath adios2_atl adios2_enet adios2_ffs adios2_dill" ``` \(maybe with a fortran one too depending on that config option\). Then [later on](https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2/blob/c45b71…, all of these libraries are appended by `_mpi` so the full library list looks something like ```shell ADIOS2_LIBS="adios2_cxx11_mpi adios2_c_mpi adios2_core_mpi adios2_evpath_mpi adios2_atl_mpi adios2_enet_mpi adios2_ffs_mpi adios2_dill_mpi adios2_cxx11 adios2_c adios2_core adios2_evpath adios2_atl adios2_enet adios2_ffs adios2_dill" ``` Unfortunately, looking at my Spack build of ADIOS2, I only have the following in the `lib64` directory \(actually it's the same as the one built by Cactus using the `build.sh` script\): ``` cmake libadios2_c.a libadios2_core.a libadios2_cxx11.a libadios2_dill.a libadios2_evpath.a libadios2_atl.a libadios2_c_mpi.a libadios2_core_mpi.a libadios2_cxx11_mpi.a libadios2_enet.a libadios2_ffs.a ``` I think only `adios2_cxx11 adios2_c adios2_core` \(and `adios2_fortran` if enabled\) should be appended by `_mpi`. Note that it seems to be correct in the case ADIOS2 is built rather than using an external library \(see [here](https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2/blob/c45b…). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2901/externallibraries…

1 0

#2901: ExternalLibraries-ADIOS2: detect.sh adds nonexistent MPI libraries if ADIOS2_ENABLE_SST == yes when using external ADIOS2
by Miren Radia 17 Nov '25

17 Nov '25

#2901: ExternalLibraries-ADIOS2: detect.sh adds nonexistent MPI libraries if ADIOS2_ENABLE_SST == yes when using external ADIOS2 Reporter: Miren Radia Status: submitted Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn I opened [an issue in the GitHub repository](https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2/iss… but am opening this ticket here as suggested by Roland Haas. The GitHub issue description is below In the case \`ADIOS2\_ENABLE\_SST == yes\`, after [this line](https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2/blob/c45b… \`\`\`bash ADIOS2\_REQ\_LIBRARIES="adios2\_cxx11 adios2\_c adios2\_core adios2\_evpath adios2\_atl adios2\_enet adios2\_ffs adios2\_dill" \`\`\` \(maybe with a fortran one too depending on that config option\). Then [later on](https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2/blob/c45b71…, all of these libraries are appended by \`\_mpi\` so the full library list looks something like \`\`\` ADIOS2\_LIBS="adios2\_cxx11\_mpi adios2\_c\_mpi adios2\_core\_mpi adios2\_evpath\_mpi adios2\_atl\_mpi adios2\_enet\_mpi adios2\_ffs\_mpi adios2\_dill\_mpi adios2\_cxx11 adios2\_c adios2\_core adios2\_evpath adios2\_atl adios2\_enet adios2\_ffs adios2\_dill" \`\`\` Unfortunately, looking at my Spack build of ADIOS2, I only have the following in the \`lib64\` directory \(actually it's the same as the one built by Cactus using the \`build.sh\` script\): \`\`\` cmake libadios2\_c.a libadios2\_core.a libadios2\_cxx11.a libadios2\_dill.a libadios2\_evpath.a libadios2\_atl.a libadios2\_c\_mpi.a libadios2\_core\_mpi.a libadios2\_cxx11\_mpi.a libadios2\_enet.a libadios2\_ffs.a \`\`\` I think only \`adios2\_cxx11 adios2\_c adios2\_core\` \(and \`adios2\_fortran\` if enabled\) should be appended by \`\_mpi\`. Note that it seems to be correct in the case ADIOS2 is built rather than using an external library \(see [here](https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2/blob/c45b…). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2901/externallibraries…

1 0

#2892: SpacetimeX: GPU error in PunctureTracker::PunctureContainer::interpolate
by Miren Radia 17 Nov '25

17 Nov '25

#2892: SpacetimeX: GPU error in PunctureTracker::PunctureContainer::interpolate Reporter: Miren Radia Status: open Milestone: Version: development version Type: bug Priority: major Component: CarpetX Comment (by Miren Radia): I have opened a discussion in the AMReX repository [here](https://github.com/AMReX-Codes/amrex/discussions/4795). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2892/spacetimex-gpu-er…

1 0

#2900: Support for Lonestar
by Hector Iglesias 14 Nov '25

14 Nov '25

#2900: Support for Lonestar Reporter: Hector Iglesias Status: submitted Milestone: Version: Type: bug Priority: blocker Component: Hello, I was wondering if there was support for the Lonestar cluster. I don’t see any files for it in `simfactory/mdb` in the latest ET release, but [#256](https://bitbucket.org/einsteintoolkit/tickets/issues/256/add-support-for-the-new-lonestar) seems to indicate that there was a time where there was support. Thanks. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2900/support-for-lones…

1 0

#2899: BHNS with Elliptica: Assertion `all(offset == other.offset)' failed
by Alejandra Gonzalez 12 Nov '25

12 Nov '25

#2899: BHNS with Elliptica: Assertion `all(offset == other.offset)' failed Reporter: Alejandra Gonzalez Status: new Milestone: Version: Type: bug Priority: major Component: Hello, I’m testing the Elliptica\_ID\_Reader thorn to evolve black hole neutron star binaries. Right after iteration 0 I get the following error: ``` cactus_sim_ellip: /gpfs/home/uib/uib416720/ETK2024/Elliptica/Cactus/arrangements/Carpet/CarpetLib/src/bboxset2.hh:263: CarpetLib::bboxset2::bboxset<T, D> CarpetLib::bboxset2::bboxset<T, D>::binary_operator(const F&, const CarpetLib::bboxset2::bboxset<T, D>&) const [with F = CarpetLib::bboxset2::bboxset<int, 3>::operator|(const CarpetLib::bboxset2::bboxset<int, 3>&) const::<lambda(const bboxset1&, const bboxset1&)>; T = int; int D = 3]: Assertion `all(offset == other.offset)' failed. ``` I understand there’s something wrong with the box covering either of the two objects so I would appreciate suggestions as to which parameters to modify and how to set this properly. I’m attaching the parfile I’m using, maybe I’m missing something there. attachment: bhns_gamma2.0_k92.1_n128.par (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2899/bhns-with-ellipti…

1 0

#2898: CarpetX: Interpolator caches
by Roland Haas 12 Nov '25

12 Nov '25

#2898: CarpetX: Interpolator caches Reporter: Lucas Timotheo Sanches Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Having a hidden cache is dangerous since it will accumulate cache entries that may no longer be required \(eg a run that never regrids but updates coordinates\). Something like this happened to the HTTP thorn Better maybe to let the user code control cache entries. Eg. Slab uses \(in `Slab/src/slab.h` \(though apparently there’s no LaTeXed docs for this\) `Slab_MultiTransfer_Init` and `Slab_MultiTransfer_Finalize` to manage lifetime of its control structures. CarpetInterp2 \(being C\+\+ only\) uses the `fasterp_setup_t`class \(`CarpetInterp2/src/fasterp.hh`\). This also avoids the need to have to hash the input coordinates etc. or otherwise find out which cached entry to use. This can be added to the regular Cactus interpolator \(could be in Carpet as well, though apparently I never created code for this\) by having a handle based interface and storing the \(int\) handle is a parameter in the interpolator parameter table \(in fact the interpolator is free to modify the table, so it could actually allocate the cache entry is an “emtpy” field for the cache handle is found in the table, which would require only call to deallocate the handle object\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2898/carpetx-interpola…

1 0

#2898: CarpetX: Interpolator caches
by Lucas Timotheo Sanches 11 Nov '25

11 Nov '25

#2898: CarpetX: Interpolator caches Reporter: Lucas Timotheo Sanches Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Lucas Timotheo Sanches): Please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2898/carpetx-interpola…

1 0

#2898: CarpetX: Interpolator caches
by Lucas Timotheo Sanches 11 Nov '25

11 Nov '25

#2898: CarpetX: Interpolator caches Reporter: Lucas Timotheo Sanches Status: new Milestone: Version: Type: enhancement Priority: major Component: Pull request and detailed explanation is [here](https://github.com/EinsteinToolkit/CarpetX/pull/369) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2898/carpetx-interpola…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2025