Trac

trac@lists.einsteintoolkit.org

8708 discussions

#1881: Unclear error message for parameter file error
by Roland Haas 09 Jul '26

09 Jul '26

#1881: Unclear error message for parameter file error Reporter: Erik Schnetter Status: open Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): ping -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1881/unclear-error-mes…

1 0

#2960: CarpetRegrid2: failure to regrid on relative radius change - possible underlying race condition
by Jordan Nicoules 09 Jul '26

09 Jul '26

#2960: CarpetRegrid2: failure to regrid on relative radius change - possible underlying race condition Reporter: Jordan Nicoules Status: new Milestone: Version: Type: bug Priority: major Component: Carpet ### Initial bug... `CarpetRegrid2` does not properly check for a change of radius of the refinement levels (when they are steered by a `Trigger` for instance). Looking a bit closer, it seems that the computed `drfac` in `CarpetRegrid2/src/regrid.cc` is `nan`, and thus `do_recompose` is not set to `true`. In particular, it means it *is* possible to change the radii if something else triggers a regridding (for instance, changing the number of active levels). ### ... revealed a deeper issue (race condition? Memory or compiler issue?) To figure out why `drfac` is `nan`, I added manual debugging information prints in the code. Depending on what information I ask, and in what order, I don't get consistent nor sensible results. *I haven't tried different compilers (I have gcc 11.4.0 locally), but this is happening even with a debug build (see attached make.config.defn file).* More precisely, printing `rad`, `oldrad`, `rad - oldrad`, their values are fine (done through `std::cout`). Printing (`CCTK_VINFO`) the numerator and denominator of `drfac` separately gives the right values for them, but the quotient `drfac` is wrong (it is `0`, and not `nan` anymore, even when it shouldn't). If I create new local variables ``` CCTK_REAL const num = sqrt(sum(ipow(rad - oldrad, 2))); CCTK_REAL const den = sqrt(sum(ipow(oldrad, 2))); ``` and print them, they both contain the same value. It looks like the values are as if it uses `rad=0` and whatever `oldrad` used to have before (which can be thus changed, depending on the order of the print lines). Finally, if I do print a lot of other info (in particular the intermediate computation steps), it seems it finally gets `drfac` right. I had a look at `CarpetLib`'s `vect.hh` and `defs.hh` too, but I can't seem to understand what is going wrong. ### Minimal example It would be helpful if someone could try to replicate the issue. To that effect, I'm attaching a minimal parfile (`regrid2_steer_radius.par`) adapted from `CarpetRegrid2/test/regrid2_granularity.par`, as well as a modified `regrid.cc` file with the extra `VINFO` that should allow you to quickly reproduce the situation. I'm attaching two output files generated from these simulations, one that gets `drfac` right, and one that gets it wrong. The difference is in the extra information I'm printing from `regrid.cc` (commented lines 840-849). ### Additional note I stumbled upon another possible desirable correction in the thorn, although it didn't seem to affect that matter so far. Hence, I also don't know how correct it actually is. I'm attaching the relevant `regrid.cc`, `initialise.cc` and `schedule.ccl` files in `fix__old_radius.zip`. attachment: CarpetRegrid2_bug.zip (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2960/carpetregrid2-fai…

1 0

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior
by Roland Haas 08 Jul '26

08 Jul '26

1 0

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior
by Roland Haas 08 Jul '26

08 Jul '26

1 0

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior
by Roland Haas 08 Jul '26

08 Jul '26

1 0

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior
by Roland Haas 08 Jul '26

08 Jul '26

#2912: Inconsistent computation of the volume form in Coordinates (llama) between Thornburg04/13 and default behavior Reporter: Jordan Nicoules Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was resolved) Comment (by Roland Haas): Outputting (and computing) volume_form for test7patch is very slow (10min runtime) due to high number of MC particles used. Tolerance is also excessively tight for the "sum" reduction (resulting in the total volume) for an expected output value of 2e8 or so. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2912/inconsistent-comp…

1 0

#2959: Include BHNSTracker
by rahime matur 07 Jul '26

07 Jul '26

#2959: Include BHNSTracker Reporter: Beyhan Karakaş Status: new Milestone: Version: development version Type: enhancement Priority: major Component: EinsteinToolkit thorn Changes (by rahime matur): responsible: [] (was ) assignee: rahime matur (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2959/include-bhnstrack…

1 0

#2959: Include BHNSTracker
by Beyhan Karakaş 07 Jul '26

07 Jul '26

#2959: Include BHNSTracker Reporter: Beyhan Karakaş Status: new Milestone: Version: development version Type: enhancement Priority: major Component: EinsteinToolkit thorn BHNS gallery example currently depends on `PunctureTracker` and `VolumeIntegralGRMHD`. Rahime and I wrote `BHNSTracker` to better track the stars. It has been tested for low resolution and it is now being tested for high resolution simulations. Once confirmed, it will be ready for a review for inclusion for the next release. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2959/include-bhnstrack…

1 0

#2958: Regression in TwoPuncturesX
by Roland Haas 07 Jul '26

07 Jul '26

#2958: Regression in TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: ET_2016_05 Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): With a better commit message, please. ``` <NameOfThorn>:<SingleSpace><One line, short, active mode, present tense description> <OneEmptyLine> <stuff I (or git) does not care about> ``` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2958/regression-in-two…

1 0

#2958: Regression in TwoPuncturesX
by Roland Haas 07 Jul '26

07 Jul '26

#2958: Regression in TwoPuncturesX Reporter: Steven R. Brandt Status: new Milestone: ET_2016_05 Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): priority: major (was blocker) Comment (by Roland Haas): not a "blocker" in that it does not prevent compilation. https://docs.einsteintoolkit.org/et-docs/Tickets#Priority Possibly "critical" depending on how important one deems TwoPunctures(X) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2958/regression-in-two…

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
871
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac