#2928: New Simfactory Option
Reporter: Steven R. Brandt
Status: new
Milestone:
Version:
Type: enhancement
Priority: major
Component: SimFactory
Comment (by Steven R. Brandt):
Currently, this is how I run on qbd. I have a script where I set the number of gpus and the queue I want to run in, then I use these few lines to call simfactory. I set the gpus and queue, then the script handles the math. This could be absorbed into simfactory.
```
gpus=4
queue=gpu2
if [ $queue = gpu2 ]
then
cpus_per_gpu=32
else
cpus_per_gpu=16
fi
if [ $gpus = 1 ]
then
ppn=32
else
ppn=64
fi
set -x
./simfactory/bin/sim create-submit $sim --queue $queue --config bssn --parfile benchpars/bench_$sim.par --procs $(($gpus*$cpus_per_gpu)) --num-threads $cpus_per_gpu --ppn-used $ppn
```
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2928/new-simfactory-op…
#2938: use SWMR mode for HDF5 output in CarpetIOHDF5
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: enhancement
Priority: minor
Component: Carpet
New versions of HDF5 support a single-writer, multiple reader (SWMR) mode that keeps files intact while appending to existing datasets.
This can be helpful for CarpetIOHDF5 since it reduces the window in time during which files would be corrupted if Cactus is terminated while writing to a file. A high-level description of the functionality is found on:
https://support.hdfgroup.org/documentation/hdf5/latest/_s_w_m_r_t_n.html
Unfortunately, even for the reader, the functionality is not fully transparent it seems (namely the reader must pass flags to `H5Fopen`), so this may require a "fix-files" step to make partially written files readable with standard utilities (eg VisIt). But at least the files themselves would be mostly intact.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2938/use-swmr-mode-for…
#2937: TwoPuncturesX largely duplicates TwoPunctures
Reporter: Zach Etienne
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component:
TwoPuncturesX inclusion ticket: #2926
While `TwoPuncturesX` ( is an essential thorn for CarpetX, it currently exists largely as a line-by-line copy of `TwoPunctures`, with more than 90% of the lines of code duplicated.
This approach creates a maintenance burden: any updates to the core logic of either `TwoPunctures` or `TwoPuncturesX` must be manually replicated in the other thorn. This increases the risk that the two implementations will diverge over time, leading to inconsistent behavior, duplicated bugs, or fixes being applied in one thorn but accidentally omitted from the other.
Duplicated code is not acceptable here for several reasons. First, it makes long-term maintenance more error-prone, because developers must remember to update two nearly identical code paths whenever a change is made. Second, it makes review and testing more difficult, since reviewers and maintainers must determine whether differences between the two thorns are intentional, accidental, or simply the result of one copy being out of date. More broadly, this duplication increases the cost of future development and makes it harder to ensure correctness across both `TwoPunctures` and `TwoPuncturesX`.
During the April 30, 2026 ET telecon, several possible approaches were discussed for addressing this issue:
1. **Make `TwoPuncturesX` require `TwoPunctures`.**
This would reduce duplication by allowing `TwoPuncturesX` to reuse functionality from `TwoPunctures`. However, this may be difficult because `TwoPuncturesX` requires `ADMBaseX`, while `TwoPunctures` requires `ADMBase`.
2. **Create symbolic links for files that are identical between the two thorns.**
For files that are exactly the same in both thorns, symbolic links could ensure that updates to one file are automatically reflected in the other. This would reduce the risk of the two copies drifting apart, though care would be needed to ensure this works reliably across development environments and version-control workflows.
3. **Create a shared `TwoPuncturesGuts` thorn.**
A new thorn, tentatively named `TwoPuncturesGuts`, could contain header files or shared source components comprising the core utilities used by both `TwoPunctures` and `TwoPuncturesX`. This would provide a cleaner long-term solution by centralizing the common implementation while allowing the two thorns to retain their separate interfaces and dependencies where necessary.
The goal of this ticket is to identify and implement a maintainable structure that avoids unnecessary code duplication while preserving the functionality required by both `TwoPunctures` and `TwoPuncturesX`.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2937/twopuncturesx-lar…
#2916: Include Cottonmouth
Reporter: Beyhan Karakaş
Status: open
Milestone: ET_2026_05
Version:
Type: enhancement
Priority: major
Component: EinsteinToolkit thorn
Comment (by Lucas Timotheo Sanches):
Hey Zach,
Thanks for the comments! I have addressed all the issues pointed out so far. They are already in the `master` branch of EinsteinEngine. Please recheck and see if the changes are adequate
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2916/include-cottonmou…
#2931: Claude AI edits to TwoPuncturesX
Reporter: Steven R. Brandt
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component:
Comment (by Steven R. Brandt):
I think all clanker issues are now addressed. While there never was a passing test in this thorn, it still passes the test Lucas added in feature/TwoPuncturesX-tests.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2931/claude-ai-edits-t…