Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_*
by Roland Haas 07 Apr '26

07 Apr '26

1 0

#2929: GRHayLET/IllinoisGRMHD convert_IllinoisGRMHD_to_HydroBase schedule compatibility with VolumeIntegrals_*
by Maxwell Rizzo 07 Apr '26

07 Apr '26

#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 In GRHayLET/IllinoisGRMHD/schedule.ccl, starting at line 220, it appears that the Convert_to_Hydrobase is scheduled before the wrong thorn VolumeIntegral_* schedule group. ``` if(Convert_to_HydroBase_every) { schedule convert_IllinoisGRMHD_to_HydroBase at CCTK_ANALYSIS before (compute_bi_b2_Poyn_fluxET convert_to_MHD_3velocity particle_tracerET VolumeIntegralGroup) after ML_BSSN_evolCalcGroup { LANG: C OPTIONS: GLOBAL-EARLY,LOOP-LOCAL READS: ADMBase::metric, ADMBase::lapse, ADMBase::shift, grmhd_velocities, grmhd_B_center WRITES: HydroBase::vel(everywhere), HydroBase::w_lorentz(everywhere), HydroBase::Bvec(everywhere) } "Convert IllinoisGRMHD-native variables to HydroBase" } ``` VolumeIntegralGroup, appearing above in the ```before``` list, is the schedule group for thorn VolumeIntegrals_vacuum which does not inherit HydroBase. VI_GRMHD_VolumeIntegralGroup is the schedule group for thorn VolumeIntegrals_GRMHD which does inherit and use HydroBase. The above schedule does not ensure conversion to HydroBase occurs before VolumeIntegrals_GRMHD runs its main scheduled group. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2929/grhaylet-illinois…

1 0

#2916: Include Cottonmouth
by Zach Etienne 07 Apr '26

07 Apr '26

#2916: Include Cottonmouth Reporter: Beyhan Karakaş Status: open Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Zach Etienne): The Cottonmouth thorn can be found in this repo: https://github.com/EinsteinToolkit/Cottonmouth The code that generates Cottonmouth (EinsteinEngine) can be found in this repo: git clone https://github.com/max-morris/EinsteinEngine.git -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2916/include-cottonmou…

1 0

#2918: Include BHaHAHA
by Zach Etienne 07 Apr '26

07 Apr '26

#2918: Include BHaHAHA Reporter: Beyhan Karakaş Status: open Milestone: ET_2026_05 Version: Type: enhancement Priority: major Component: EinsteinToolkit thorn Comment (by Zach Etienne): ET_BHaHAHA (the Einstein Toolkit implementation of BHaHAHA) can be found here: https://bitbucket.org/einsteintoolkit/einsteinanalysis/src/master/ET_BHaHAH… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2918/include-bhahaha

1 0

#1775: Add Boost to ET
by Roland Haas 06 Apr '26

06 Apr '26

#1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): I note that while this builds a whole lot of libraries, it only, matching David's old library, links in `system` and `filesystem`. So we could likely speed up the build process by passing `--with-system` and `--with-filesystem` to `b2`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et

1 0

#1775: Add Boost to ET
by Roland Haas 06 Apr '26

06 Apr '26

#1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): @{557058:f7fd5133-6eee-4385-a5e5-3e03342a0b24} here's a repository: https://github.com/EinsteinToolkit/ExternalLibraries-Boost -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et

1 0

#2928: New Simfactory Option
by Steven R. Brandt 06 Apr '26

06 Apr '26

#2928: New Simfactory Option Reporter: Steven R. Brandt Status: new Milestone: Version: Type: enhancement Priority: major Component: SimFactory The options to simfactory reflect usage on older hardware. We used to be more concerned with how many cores we wanted to use and how many to allocate to each process. Now we are often more concerned with how many gpus we want. It would be much more convenient to say something like: ``` ./simfactory/bin/sim create-run --gpus=4 --queue=gpu2 ... ``` Than to figure out that nodes in the gpu2 queue we have 64 cores and 2 gpus per node, and thus the way to invoke simfactory is as follows: ``` ./simfactory/bin/sim create-run --procs=128 --num-threads=32 ... ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2928/new-simfactory-op…

1 0

#1775: Add Boost to ET
by Roland Haas 01 Apr '26

01 Apr '26

#1775: Add Boost to ET Reporter: Erik Schnetter Status: new Milestone: ET_2026_05 Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): It is possible to interact with make's parallel build system (somewhat): https://www.gnu.org/software/make/manual/html_node/POSIX-Jobserver.html (note that Cactus requires GNU make). ``` #!/bin/bash # fail on errors, error on unset variable reference set -u -e # verobse output? if [ ${VERBOSE-no} = yes ]; then set -x fi # handle -n option to make (do nothing), since make thinks we are a sub-make set -- $MAKEFLAGS if [[ ${#*} -ge 1 ]] && [[ $1 = *n* ]]; then # -n flag passed to make, do nothing exit 0 fi # parse remaining make arguments MAX_JOBS=1 JOBSERVER_AUTH= for o in "$@"; do case $o in ( --jobserver-auth=* ) JOBSERVER_AUTH=${o#--jobserver-auth=} ;; ( -j* ) MAX_JOBS=${o#-j*} ;; ( -- ) break ;; esac done # functions to get some job tokens from make function return_tokens() { local JOBSERVER_FILE= if [ -n "$JOBSERVER_AUTH" ] && [ -n "$JOBSERVER_TOKENS" ]; then case $JOBSERVER_AUTH in ( fifo:* ) JOBSERVER_FILE=${JOBSERVER_AUTH#fifo:} ;; ( *,* ) # /dev/fd/ emulated by bash (if not by the OS) JOBSERVER_FILE=/dev/fd/${JOBSERVER_AUTH#*,} # read handle of pipe ;; esac if [ -n "$JOBSERVER_FILE" ]; then echo -n $JOBSERVER_TOKENS >$JOBSERVER_FILE fi fi } function maybe_get_tokens() { local JOBSERVER_FILE= if [ -n "$JOBSERVER_AUTH" ]; then case $JOBSERVER_AUTH in ( fifo:* ) JOBSERVER_FILE=${JOBSERVER_AUTH#fifo:} ;; ( *,* ) # /dev/fd/ emulated by bash (if not by the OS) JOBSERVER_FILE=/dev/fd/${JOBSERVER_AUTH#%,*} # write handle of pipe ;; esac if [ -n "$JOBSERVER_FILE" ]; then set +e # read sets error code on timeout, which is not an error read -r -N $MAX_JOBS -t 5 JOBSERVER_TOKENS <$JOBSERVER_FILE set -e fi fi } if [ -n "$MAX_JOBS" ]; then JOBSERVER_TOKENS= # wait for 5 seconds to get up MAX_JOBS tokens (or 1024 if MAX_JOBS is empty) trap return_tokens EXIT maybe_get_tokens # one job is for "free" since it represents this process JOBS_OPT=-j$(( ${#JOBSERVER_TOKENS} + 1 )) else # no maximum JOBS_OPT=-j fi echo $JOBS_OPT tokens: ${JOBSERVER_TOKENS:-} ``` when declaring the script above a sub-make to make using: ``` all: +@./bjam-test.sh ``` which then produces: ``` haengie2: ~/.../Boost/dist$ make -j5 -f GNUMakefile all -j5 tokens: ++++ haengie2: ~/.../Boost/dist$ make -j1 -f GNUMakefile all -j1 tokens: haengie2: ~/.../Boost/dist$ make -j -f GNUMakefile all -j tokens: haengie2: ~/.../Boost/dist$ make -f GNUMakefile all -j1 tokens: ``` ie constructs a `-j` option for bjam reflection (a subset of) the jobs available to make. As for tar file size, the best I can do right now is to remove Boost examples, docs, tests etc. then re-compress with `gzip`'s `--rsyncable` option for a ~30MB file size which git can hopefully diff: ``` #!/bin/bash # this script removes "extra" files from Boost distribution archive to try and # reduce its size. It creates a new zipped archive that may be diff-able for git. if [ ${#@} -ne 1 ]; then echo >&2 "usage: $0 <tar-file>" exit 1 fi set -e FN="$1" TEMPDIR=`mktemp -d` function cleanup() { rm -r $TEMPDIR } trap cleanup EXIT tar -xf "$FN" -C $TEMPDIR find $TEMPDIR -depth '(' -name examples -or -name doc -or -name test ')' -print0 | xargs --null rm -r # use gzip's --rsyncable option in hopes that this will let git diff versions # of the tar archive ( cd $TEMPDIR ; tar -c * ) | gzip --rsyncable >${FN%.tar*}-stripped.tar.gz ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1775/add-boost-to-et

1 0

#2923: ADIOS2 compilation fails due to unknown type name ‘INT4= ’
by Steven R. Brandt 01 Apr '26

01 Apr '26

#2923: ADIOS2 compilation fails due to unknown type name ‘INT4’ Reporter: Cheng-Hsin Cheng Status: new Milestone: Version: ET_2025_05 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Steven R. Brandt): OK, my mistake. I didn't read this carefully enough. This is an ADIOS2 issue. Not sure what to do about that. Here's what the Grok clanker has to say: https://grok.com/share/c2hhcmQtMw_c753302c-29b1-4ccd-a483-6ca95174b4ad -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2923/adios2-compilatio…

1 0

#2927: gcc-version-dependent error: Range error setting parameter
by Jordan Nicoules 01 Apr '26

01 Apr '26

#2927: gcc-version-dependent error: Range error setting parameter Reporter: Jordan Nicoules Status: new Milestone: Version: Type: bug Priority: major Component: Cactus For reference, thread on the mailing list: https://lists.einsteintoolkit.org/pipermail/users/2026-March/009901.html # TLDR # With certain versions of gcc, having a (real) parameter defined with a range only consisting of ``*`` causes a range error at the start of the simulation. # Description # With certain versions of gcc (13.3.0, 14.3.0), having a real parameter defined with a range only consisting of ``*`` causes a range error at the start of the simulation, right after thorn activation: ``` WARNING[L2,P0] (Cactus): ParameterSetReal: Unable to set real 'Coordinates::h_radial_1' = '0.40000000000000002' not in any active range WARNING[L1,P0] (Cactus): Major error in parameter file '/home/jnicoules/Work/ET_test/Simus/parfiles/Gallery/Kerr-Schild_Multipole_stretch.par' line 46: Range error setting parameter 'Coordinates::h_radial_1' to '0.40000000000000002' WARNING level 0 from host cnx001.deucalion.macc.fccn.pt process 0 in thorn Cactus, file /projects/F202407872CPCAA2/jnicoules/ET_test/Cactus/configs/ET_test__x86__GCC-13.3.0/build/Cactus/main/ProcessParameterDatabase.c:201: -> CCTKi_SetParameterSetMask: 1 major error in parameter file ``` The issue was encountered with a specific parameter, ``Coordinates::h_radial_1``, from the ``llama`` repo. I didn't experiment with other parameters from different thorns. Most of the experimentation was performed on x86 nodes of the Deucalion cluster (https://docs.macc.fccn.pt/deucalion/). Three different versions of gcc and available related modules were tested: 12.3.0, 13.3.0, 14.3.0. # Minimal (non)working example # The issue can be seen with the attached parameter file, based on the Multipatch wave equation Gallery example, tweaked to include parameter ``Coordinates::h_radial_1``. The used ET version for the MWE is 2025-05 and the thornlist is a shaved off version of the one on the ET website (https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2025_05/einsteintoolk…), to ease configuration and compilation. The outputs are attached, for each of the three versions mentioned above. Additionally, it contains the output for a configuration using GCC-13.3.0, but changing, in ``Cactus/repos/llama/Coordinates/param.ccl``, ``` real h_radial_1 "Intended radial resolution of the first stretched domain" { * :: "negative turns off stretching" } -1 ``` by ``` real h_radial_1 "Intended radial resolution of the first stretched domain" { *:* :: "negative turns off stretching" } -1 ``` which is enough to have the simulation work properly. # Other notes # As mentioned in https://lists.einsteintoolkit.org/pipermail/users/2026-March/009901.html, gcc 15 might work just well. Testing on my other setups (workstation and other clusters), where I have various older versions of gcc, the issue did not occur. I'm not attaching the respective files here, as the MWE shows both working and non-working situations. # Attachments # ``` range_error_MWE/ |__ einstein_toolkit.th # Thornlist |__ Kerr-Schild_Multipole_stretch.par # Parameter file |__ Kerr-Schild_Multipole_stretch/ # Contains the output for the various cases, without .h5 files for size reasons |__ README |__ output-*/ |__ GCC-*/ # contains compilation information in each case |__ *.cfg # option file |__ config_*.log # output of make config |__ make_*.log # output of make |__ make.config.defn # file found in Cactus/configs/*/config-data ``` attachment: range_error_MWE.zip (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2927/gcc-version-depen…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac