#2932: Kuibit: detecting 0D and 1D files generated during Llama runs
Reporter: Jordan Nicoules
Status: new
Milestone:
Version:
Type: enhancement
Priority: minor
Component: EinsteinToolkit thorn
Comment (by Maxwell Rizzo):
Thanks for clarifying, in that case the PR looks complete.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2932/kuibit-detecting-…
#2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_*
Reporter: Maxwell Rizzo
Status: new
Milestone: ET_2026_05
Version: ET_2025_05
Type: bug
Priority: major
Component: EinsteinToolkit thorn
Comment (by Maxwell Rizzo):
This fixes the issue, however there is a remaining question whether this is the best location to ensure VolumeIntegrals are scheduled correctly. Given that VolumeIntegrals are analysis thorns, they should probably schedule themselves properly, and not require the evolution thorn to correct things.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2929/grhaylet-illinois…
#2932: Kuibit: detecting 0D and 1D files generated during Llama runs
Reporter: Jordan Nicoules
Status: new
Milestone:
Version:
Type: enhancement
Priority: minor
Component: EinsteinToolkit thorn
Comment (by Jordan Nicoules):
Thank you for the review! I agree that the scope of that ticket/PR is conservatively limited to patch 0 support (specifically for the Thornburg04 system).
Maybe proper llama support could deserve its own ticket, but as mentioned there, I'm not even sure how the other output is done and if it's fully reliable.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2932/kuibit-detecting-…
#2932: Kuibit: detecting 0D and 1D files generated during Llama runs
Reporter: Jordan Nicoules
Status: new
Milestone:
Version:
Type: enhancement
Priority: minor
Component: EinsteinToolkit thorn
Comment (by Maxwell Rizzo):
Changes look good to support patch 0 llama files, I left a comment on the kuibit pull request with some comments about non-zero patch output, but perhaps its best to start with just patch 0 support for now.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2932/kuibit-detecting-…
#2938: use SWMR mode for HDF5 output in CarpetIOHDF5
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: enhancement
Priority: minor
Component: Carpet
Comment (by Roland Haas):
This would fix the issue in #1283
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2938/use-swmr-mode-for…
#2918: Include BHaHAHA
Reporter: Beyhan KarakaÅŸ
Status: open
Milestone: ET_2026_05
Version:
Type: enhancement
Priority: major
Component: EinsteinToolkit thorn
Comment (by Zach Etienne):
@{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} : I have added the required code test to ET_BHaHAHA - it is a horizon find on a Kerr BH with spin parameter 0.6.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2918/include-bhahaha
#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…