Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates
by Roland Haas 30 Sep '25

30 Sep '25

#2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2889/outflow-uses-inco…

1 0

#2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates
by Roland Haas 30 Sep '25

30 Sep '25

#2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Pull request is here: [https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-requests/25](ht… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2889/outflow-uses-inco…

1 0

#2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates
by Roland Haas 30 Sep '25

30 Sep '25

#2889: Outflow uses incorrect `sf_centroid` to compute surface coordinates Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Outflow incorrectly used `sf_centroid` as the origin point for the spherical surface it computes fluxes on. However for `SphericalSurface` the surface is defined with respect to `sf_origin` via `sf_radius[ind2d]` . This pull request fixes this and also introduces a runtime parameter to chose between `sf_centroid` and `sf_origin`. The former is useful if one also sets `override_radius`if eg the sphericalsurface is really just a tracker position. Thankfully for the common case where there are either a set of spheres centered on on the coordinate origin or spheres following a neutron star via tracking we usually have `sf_origin` and `sf_centroid` being identical. However flow through an apparent horizon would be incorrect. I would suspect that `sf_origin` is the centroid of the previous horizon find result. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2889/outflow-uses-inco…

1 0

#2597: Simfactory on Bridges2
by Roland Haas 25 Sep '25

25 Sep '25

#2597: Simfactory on Bridges2 Reporter: Maria Status: new Milestone: Version: ET_2021_11 Type: task Priority: major Component: Comment (by Roland Haas): Unless objected, I will close this ticket due to inactivity after 2025-10-09 -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2597/simfactory-on-bri…

1 0

#2708: Elliptica_ID_Reader fails to compile on macOS
by Roland Haas 25 Sep '25

25 Sep '25

#2708: Elliptica_ID_Reader fails to compile on macOS Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: blocker Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2708/elliptica_id_read…

1 0

#2482: Inconsistency in Simfactory submission scripts
by Roland Haas 25 Sep '25

25 Sep '25

#2482: Inconsistency in Simfactory submission scripts Reporter: Steven R. Brandt Status: wontfix Milestone: Version: Type: bug Priority: major Component: SimFactory Changes (by Roland Haas): status: wontfix (was new) Comment (by Roland Haas): Not enough personpower to really fix this. Current setup is workable enough. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2482/inconsistency-in-…

1 0

#2888: race condition writing properties.ini in simfactory
by Roland Haas 24 Sep '25

24 Sep '25

#2888: race condition writing properties.ini in simfactory Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: SimFactory Changes (by Roland Haas): Currently both the `submit()` as well as the `run()`function in `lib/simrestart.py` write \(update\) the file `output-NNNN/properties.ini`. In particular `submit()` does so _after_ submitting to record the `jobid` field while `run()` does so before running to record the `checkpointing` value. This means that \(eg on SLURM where jobs start quickly, an particular when the `submit` command contains a `sleep 5` to slow down job submission\) there can be race condition: 1. `submit` writes initial copy of `properties.ini` lacking `jobid` 2. `submit` submits the job to SLURM 3. job starts and `run` reads `properties.ini` 4. `submit` writes updated `properties.ini` with `jobid` 5. `run` writes `properties.ini` with `checkpointing` at this point `jobid` is lost from `properties.ini` Fixes would be: * add a lock for `properties.ini` which `submit` only release once it has done its final update * submit jobs in “held” state \(`sbatch --hold`\) and only release them once the final update of properties.ini has happened both will require updates to simfactory’s code. The first option would work without updates to the machine ini files, the second will require extra entries to tell simfactory how to release a job. This could also be used to implement `hold` and `release` commands in simfactory. The first option will require fallback code in case the lock file is left behind \(e.g. wait no longer than 1 minute before assuming a stale lock and going ahead anyway\). The lock file will require at least some level for POSIX conformance from the file system \(namely that file creation and removal is an atomic operation cluster-wide\). This most likely is the reason for occasional strange failures on clusters with jobid being unset. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2888/race-condition-wr…

1 0

#2888: race condition writing properties.ini in simfactory
by Roland Haas 24 Sep '25

24 Sep '25

#2888: race condition writing properties.ini in simfactory Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: SimFactory Changes (by Roland Haas): Currently both the `submit()` as well as the `run()`function in `lib/simrestart.py` write \(update\) the file `output-NNNN/properties.ini`. In particular `submit()` does so _after_ submitting to record the `jobid` field while `run()` does so before running to record the `checkpointing` value. This means that \(eg on SLURM where jobs start quickly, an particular when the `submit` command contains a `sleep 5` to slow down job submission\) there can be race condition: 1. `submit` writes initial copy of `properties.ini` lacking `jobid` 2. `submit` submits the job to SLURM 3. job starts and run reads `properties.ini` 4. `submit` writes updated `properties.ini` with `jobid` 5. `run` writes `properties.ini` with `checkpointing` at this point `jobid` is lost from `properties.ini` Fixes would be: * add a lock for `properties.ini` which `submit` only release once it has done its final update * submit jobs in “held” state \(`sbatch --hold`\) and only release them once the final update of properties.ini has happened both will require updates to simfactory’s code. The first option would work without updates to the machine ini files, the second will require extra entries to tell simfactory how to release a job. This could also be used to implement `hold` and `release` commands in simfactory. The first option will require fallback code in case the lock file is left behind \(e.g. wait no longer than 1 minute before assuming a stale lock and going ahead anyway\). The lock file will require at least some level for POSIX conformance from the file system \(namely that file creation and removal is an atomic operation cluster-wide\). This most likely is the reason for occasional strange failures on clusters with jobid being unset. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2888/race-condition-wr…

1 0

#2888: race condition writing properties.ini in simfactory
by Roland Haas 24 Sep '25

24 Sep '25

#2888: race condition writing properties.ini in simfactory Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: SimFactory Changes (by Roland Haas): Currently both the `submit()` as well as the `run()`function in `lib/simrestart.py` write \(update\) the file `output-NNNN/properties.ini`. In particular `submit()` does so _after_ submitting to record the `jobid` field while `run()` does so before running to record the `checkpointing` value. This means that if \(eg on SLURM where jobs start quickly, an particular when the `submit` command contains a `sleep 5` to slow down job submission\) there can be race condition: 1. `submit` writes initial copy of `properties.ini` lacking `jobid` 2. `submit` submits the job to SLURM 3. job starts and run reads `properties.ini` 4. `submit` writes updated `properties.ini` with `jobid` 5. `run` writes `properties.ini` with `checkpointing` at this point `jobid` is lost from `properties.ini` Fixes would be: * add a lock for `properties.ini` which `submit` only release once it has done its final update * submit jobs in “held” state \(`sbatch --hold`\) and only release them once the final update of properties.ini has happened both will require updates to simfactory’s code. The first option would work without updates to the machine ini files, the second will require extra entries to tell simfactory how to release a job. This could also be used to implement `hold` and `release` commands in simfactory. The first option will require fallback code in case the lock file is left behind \(e.g. wait no longer than 1 minute before assuming a stale lock and going ahead anyway\). The lock file will require at least some level for POSIX conformance from the file system \(namely that file creation and removal is an atomic operation cluster-wide\). This most likely is the reason for occasional strange failures on clusters with jobid being unset. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2888/race-condition-wr…

1 0

#2888: race condition writing properties.ini in simfactory
by Roland Haas 24 Sep '25

24 Sep '25

#2888: race condition writing properties.ini in simfactory Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: SimFactory Comment (by Roland Haas): Note that not writing `properties.ini` is not a sufficient solution since even without writing there remains the issue that a job could start before `jobid` has been recorded and thus the `@JOB_ID@` replacement is invalid. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2888/race-condition-wr…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac