Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2967: ExternalLibraries-ADIOS2: Fix CMake MPI detection against from-source OpenMPI
by Lucas Timotheo Sanches 20 Jul '26

20 Jul '26

#2967: ExternalLibraries-ADIOS2: Fix CMake MPI detection against from-source OpenMPI Reporter: Max Morris Status: open Milestone: Version: Type: bug Priority: major Component: Changes (by Lucas Timotheo Sanches): status: open (was submitted) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2967/externallibraries…

1 0

#2966: ExternalLibraries-AMReX: Fix CMake MPI detection against from-source OpenMPI
by Lucas Timotheo Sanches 20 Jul '26

20 Jul '26

#2966: ExternalLibraries-AMReX: Fix CMake MPI detection against from-source OpenMPI Reporter: Max Morris Status: open Milestone: Version: Type: bug Priority: major Component: Changes (by Lucas Timotheo Sanches): status: open (was submitted) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2966/externallibraries…

1 0

#2968: ExternalLibraries-openPMD: Fix CMake MPI detection against from-source OpenMPI
by Max Morris 20 Jul '26

20 Jul '26

#2968: ExternalLibraries-openPMD: Fix CMake MPI detection against from-source OpenMPI Reporter: Max Morris Status: submitted Milestone: Version: Type: bug Priority: major Component: Comment (by Max Morris): please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2968/externallibraries…

1 0

#2968: ExternalLibraries-openPMD: Fix CMake MPI detection against from-source OpenMPI
by Max Morris 20 Jul '26

20 Jul '26

#2968: ExternalLibraries-openPMD: Fix CMake MPI detection against from-source OpenMPI Reporter: Max Morris Status: submitted Milestone: Version: Type: bug Priority: major Component: This fixes an issue which prevents the ET from building when both OpenMPI and openPMD are built from source via ExternalLibraries. PR is here: https://github.com/EinsteinToolkit/ExternalLibraries-openPMD/pull/3 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2968/externallibraries…

1 0

#2967: ExternalLibraries-ADIOS2: Fix CMake MPI detection against from-source OpenMPI
by Max Morris 20 Jul '26

20 Jul '26

#2967: ExternalLibraries-ADIOS2: Fix CMake MPI detection against from-source OpenMPI Reporter: Max Morris Status: submitted Milestone: Version: Type: bug Priority: major Component: Comment (by Max Morris): please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2967/externallibraries…

1 0

#2967: ExternalLibraries-ADIOS2: Fix CMake MPI detection against from-source OpenMPI
by Max Morris 20 Jul '26

20 Jul '26

#2967: ExternalLibraries-ADIOS2: Fix CMake MPI detection against from-source OpenMPI Reporter: Max Morris Status: submitted Milestone: Version: Type: bug Priority: major Component: This fixes an issue which prevents the ET from building when both OpenMPI and ADIOS2 are built from source via ExternalLibraries. PR is here: https://github.com/EinsteinToolkit/ExternalLibraries-ADIOS2/pull/10 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2967/externallibraries…

1 0

#2966: ExternalLibraries-AMReX: Fix CMake MPI detection against from-source OpenMPI
by Max Morris 20 Jul '26

20 Jul '26

#2966: ExternalLibraries-AMReX: Fix CMake MPI detection against from-source OpenMPI Reporter: Max Morris Status: submitted Milestone: Version: Type: bug Priority: major Component: Comment (by Max Morris): please review -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2966/externallibraries…

1 0

#2966: ExternalLibraries-AMReX: Fix CMake MPI detection against from-source OpenMPI
by Max Morris 20 Jul '26

20 Jul '26

#2966: ExternalLibraries-AMReX: Fix CMake MPI detection against from-source OpenMPI Reporter: Max Morris Status: submitted Milestone: Version: Type: bug Priority: major Component: This fixes an issue which prevents the ET from building when both OpenMPI and AMReX are built from source via ExternalLibraries. PR is here: https://github.com/EinsteinToolkit/ExternalLibraries-AMReX/pull/2 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2966/externallibraries…

1 0

#1077: evaluate steered value as formula in AEIThorns::Trigger
by Jordan Nicoules 16 Jul '26

16 Jul '26

#1077: evaluate steered value as formula in AEIThorns::Trigger Reporter: Roland Haas Status: open Milestone: Version: Type: enhancement Priority: minor Component: Other Comment (by Jordan Nicoules): Can formulas be used for `Trigger_Checked_Variable` too (I think that was mainly the point of the conversation during the call of July 9)? What should be the syntax, I'm not sure I'm getting it? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1077/evaluate-steered-…

1 0

#2965: GetComponents option to obtain new branch
by Jordan Nicoules 16 Jul '26

16 Jul '26

#2965: GetComponents option to obtain new branch Reporter: Jordan Nicoules Status: new Milestone: Version: Type: enhancement Priority: minor Component: GetComponents ## Context Typically on a new release, calling `GetComponents`, even with the update option, will check out new components, but existing ones will not deal with the `!REPO_BRANCH = $ET_RELEASE` which changes in the thornlist. On the other hand, a change in the repo's URL is detected and triggers some error, asking for a clean checkout (at least I could see that for `Carpet` and `POWER`, between ET_2023_05 and ET_2026_05). >From a naive user perspective, I expected that updating components with a thornlist that indicates an ET version would put the repos on the corresponding branch, ready to be compiled. ## Suggested feature (details TBD) **Either with the update option or a new option, add the `!REPO_BRANCH` to the fetch list, create the corresponding branch, and check it out if possible.** Possibly (as an option), it could also remove the previous one. This makes the most sense for branches that are release versions, but may not in general. A minima, if there are possible conflicts (unstaged changes etc.), it could raise a warning/error like for the URL, that the user would then deal with manually. ## Discussion 1. Is this feature desirable? Does it correspond better to a user's expectation? 2. Can it be harmful? 3. Does it actually save work and effort, compared to recreating a brand new Cactus directory? About point 2, a conservative addition of a fetched ref and corresponding local branch, even if not checked out, looks benign to me. Regarding point 3, to me one of the issues is the following. With a new Cactus directory, it's needed to manually move and redo possible local changes and/or additions (tracking more branches/remotes, local commits,...) -- even for forked/owned repositories, although it's less critical in that case. This manual adjustment may not disappear completely, but could be alleviated (and be more explicit). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2965/getcomponents-opt…

1 0

← Newer
1
2
3
4
5
6
7
8
...
871
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac