Trac March 2023

trac@lists.einsteintoolkit.org

1 participants
130 discussions

#1946: sim setup should create a section for the current machine
by Roland Haas 22 Mar '23

22 Mar '23

#1946: sim setup should create a section for the current machine Reporter: Roland Haas Status: open Milestone: Version: development version Type: enhancement Priority: minor Component: SimFactory Comment (by Roland Haas): @{557058:1671c5c3-29cc-4e83-9850-a152d33a6235} also came across this issue of `sourcebasedir` not being set when running `sim setup-silent` on known machines and in a directory different from what simfactory has in its machine database \(private communication\). This ticket may serve as a catchall to collect discussion and possible patches. The issue does not occur in the “official” workflow \(see SF paper: [https://arxiv.org/pdf/1008.4571](https://arxiv.org/pdf/1008.4571) page 4, “A. Managing Source Code“\), which would avoid ever running `sim setup` on the cluster \(and never run `GetComponents` there either\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1946/sim-setup-should-…

1 0

#2696: Update kuibit to 1.4.0
by Roland Haas 21 Mar '23

21 Mar '23

#2696: Update kuibit to 1.4.0 Reporter: Gabriele Bozzola Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Nice. Thank you. I can see this is going to be a continuous struggle with versions of Python / numpy / whatnot. Hiding Python 3.8 in the GNU modules is a mean trick by TACC. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2696/update-kuibit-to-…

1 0

#2696: Update kuibit to 1.4.0
by Gabriele Bozzola 21 Mar '23

21 Mar '23

#2696: Update kuibit to 1.4.0 Reporter: Gabriele Bozzola Status: new Milestone: ET_2023_05 Version: Type: enhancement Priority: major Component: Comment (by Gabriele Bozzola): I managed to add compatibility for Python 3.7 with no inconvenience for users. The next version of NumPy will drop support for Python 3.8 as well \(but it will be required for Python 3.12\), so I don’t know for how long I can hold on supporting 3.7 while also supporting newer versions. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2696/update-kuibit-to-…

1 0

#2697: Include BBH+scalar field initial data code from Canuda in ET
by Peter Diener 20 Mar '23

20 Mar '23

#2697: Include BBH+scalar field initial data code from Canuda in ET Reporter: Cheng-Hsin Cheng Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Peter Diener): NPScalars\_SF does no harm. It compiled out of the box and didn’t cause any tests that passed before to fail. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…

1 0

#1805: triggers statement does not include reductions output
by Roland Haas 20 Mar '23

20 Mar '23

#1805: triggers statement does not include reductions output Reporter: Wolfgang Kastaun Status: new Milestone: Version: ET_2014_05 Type: bug Priority: minor Component: Other Comment (by Roland Haas): I note that computing variables whose reductions are being computed \(for output or otherwise\) only every once in a while and not at every timestep is very firmly in the “[give you rope to hang yourself with, and then some more](https://motd.ambians.com/quotes.php/name/linux_computers/toc_id/1-1-4… territory. Technically should be supported though \(and I thought there are the required `CCTJ_TriggerFoo` calls in `CarpetIOScalar`\). The only way to get away with it somewhat safely is to compute \(and output\) only every coarse step \(if not computing every single step of course\). Everything else stands a danger of using stale / invalid data on past timelevels if and when interpolation in time happens. This also implies \(well mostly\) that the computed quantity must be computable in a pointwise manner, not involving any stencil operations \(to avoid having to restrict and prolongate\) to avoid different results obtained when computing every step and output every coarse or computing and outputting every coarse. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1805/triggers-statemen…

1 0

#2600: `CCTK_CENTERING_GF` is applied to grid scalars
by Roland Haas 20 Mar '23

20 Mar '23

#2600: `CCTK_CENTERING_GF` is applied to grid scalars Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: bug Priority: minor Component: Comment (by Roland Haas): @{557058:1671c5c3-29cc-4e83-9850-a152d33a6235} any news on this? Or have you already addressed this in the code and the issue can be closed? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2600/cctk_centering_gf…

1 0

#2650: Fixing WRITE statements for MoL scalars
by Roland Haas 20 Mar '23

20 Mar '23

#2650: Fixing WRITE statements for MoL scalars Reporter: Samuel Cupp Status: resolved Milestone: Version: Type: bug Priority: minor Component: Cactus Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2650/fixing-write-stat…

1 0

#2650: Fixing WRITE statements for MoL scalars
by Roland Haas 20 Mar '23

20 Mar '23

#2650: Fixing WRITE statements for MoL scalars Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): PreSync now defaults to write everywhere for scalars as of git hash [b39b9f87](https://bitbucket.org/cactuscode/cactus/commits/b39b9f879ff6351da… "Cactus: Implement scalars default to everywhere" of [cactus](https://bitbucket.org/cactuscode/cactus) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2650/fixing-write-stat…

1 0

#2705: error: more than one instance of overloaded function "isnan" matches the argument list
by Miguel Zilhão 19 Mar '23

19 Mar '23

#2705: error: more than one instance of overloaded function "isnan" matches the argument list Reporter: Miguel Zilhão Status: new Milestone: Version: Type: bug Priority: major Component: Comment (by Miguel Zilhão): I see. On Marenostrum, I can indeed fix this by pointing to a suitable g\+\+ version. On our local cluster, however, they only provide updated intel compiles and the gcc available is version 4. Is there anyway around this, or do I really need to ask the sysadmins to provide updated gcc compilers as well? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2705/error-more-than-o…

1 0

#2701: Use `std::shared_ptr` in Piraha
by Roland Haas 17 Mar '23

17 Mar '23

#2701: Use `std::shared_ptr` in Piraha Reporter: Erik Schnetter Status: resolved Milestone: Version: Type: enhancement Priority: major Component: Cactus Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2701/use-std-shared_pt…

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2023