Trac June 2023

trac@lists.einsteintoolkit.org

1 participants
81 discussions

#2735: EinsteinBase: storage declaration simplification
by Samuel Cupp 01 Jun '23

01 Jun '23

#2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Comment (by Samuel Cupp): The only question is whether we want to preserve the $imo strange$ behavior of ADMBase and TmunuBase which ignores the requested timelevels if they aren’t initialized to zero. Zeroing can be an option, but to me it seems like enforcing it prevents people from using poisoning to notice bad behavior. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-stor…

1 0

#2735: EinsteinBase: storage declaration simplification
by Samuel Cupp 01 Jun '23

01 Jun '23

#2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Comment (by Samuel Cupp): The associated PR is [here](https://bitbucket.org/einsteintoolkit/einsteinbase/pull-requests/5). Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-stor…

1 0

#2735: EinsteinBase: storage declaration simplification
by Samuel Cupp 01 Jun '23

01 Jun '23

#2735: EinsteinBase: storage declaration simplification Reporter: Samuel Cupp Status: new Milestone: ET_2023_11 Version: Type: enhancement Priority: trivial Component: EinsteinToolkit thorn Currently, the various \*Base thorns declare storage like ``` if (timelevels == 1) { STORAGE: stress_energy_scalar[1] STORAGE: stress_energy_vector[1] STORAGE: stress_energy_tensor[1] } else if (timelevels == 2) { STORAGE: stress_energy_scalar[2] STORAGE: stress_energy_vector[2] STORAGE: stress_energy_tensor[2] } else if (timelevels == 3) { STORAGE: stress_energy_scalar[3] STORAGE: stress_energy_vector[3] STORAGE: stress_energy_tensor[3] } ``` We can instead just say ``` STORAGE: stress_energy_scalar[timelevels] STORAGE: stress_energy_vector[timelevels] STORAGE: stress_energy_tensor[timelevels] ``` This, of course, will properly declare the storage depending on the parameter at runtime. As I understand the behavior, this also works for timelevels = 0. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2735/einsteinbase-stor…

1 0

#2663: add an notice about minimum Intel / GCC version required to configure output
by Roland Haas 01 Jun '23

01 Jun '23

#2663: add an notice about minimum Intel / GCC version required to configure output Reporter: Roland Haas Status: resolved Milestone: Version: Type: enhancement Priority: major Component: Changes (by Roland Haas): status: resolved (was new) Comment (by Roland Haas): Thank you. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2663/add-an-notice-abo…

1 0

#2663: add an notice about minimum Intel / GCC version required to configure output
by Roland Haas 01 Jun '23

01 Jun '23

#2663: add an notice about minimum Intel / GCC version required to configure output Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): Applied as git hash [16e3c365](https://bitbucket.org/cactuscode/cactus/commits/16e3c365f1c201e9a… "Cactus: add configure test for functional C\+\+11 math" of [cactus](https://bitbucket.org/cactuscode/cactus) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2663/add-an-notice-abo…

1 0

#2663: add an notice about minimum Intel / GCC version required to configure output
by Roland Haas 01 Jun '23

01 Jun '23

#2663: add an notice about minimum Intel / GCC version required to configure output Reporter: Roland Haas Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Roland Haas): @{557058:8bc23f2a-45c0-477d-8ac4-a5a16c734278} says $in pull request$: please apply. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2663/add-an-notice-abo…

1 0

#2669: math is not rendered correctly in online docs
by Roland Haas 01 Jun '23

01 Jun '23

#2669: math is not rendered correctly in online docs Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): The mathjax $so one hopes$ rendered math in thorndocs eg in [http://einsteintoolkit.org/thornguide/CactusNumerical/LocalReduce/documenta… is not being shown correctly. I $firefox 102.5.0esr, Debian Linux/GNU$ am shown: ‌ ![](https://bitbucket.org/repo/8zBLME5/images/1379777661-image.png) ‌ instead of the correct $when I run `make LocalReduce-ThornDocHTML` on my laptop$: ‌ ![](https://bitbucket.org/repo/8zBLME5/images/2946320859-correct.png) ‌ This most likely is due to different tex4html engines in Ubuntu 20.04 $the github documentation runner$ and Debian bullseye. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2669/math-is-not-rende…

1 0

#2669: math is not rendered correctly in online docs
by Roland Haas 01 Jun '23

01 Jun '23

#2669: math is not rendered correctly in online docs Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): The mathjax $so one hopes$ rendered math in thorndocs eg in [http://einsteintoolkit.org/thornguide/CactusNumerical/LocalReduce/documenta… is not being shown correctly. I $firefox 102.5.0esr, Debian Linux/GNU$ am shown: ‌ ![](https://bitbucket.org/repo/8zBLME5/images/1379777661-image.png) instead of the correct $when I run `make LocalReduce-ThornDocHTML` on my laptop$: ‌ ![](https://bitbucket.org/repo/8zBLME5/images/2946320859-correct.png) ‌ This most likely is due to different tex4html engines in Ubuntu 20.04 $the github documentation runner$ and Debian bullseye. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2669/math-is-not-rende…

1 0

#1334: CCTK_CHECK_HEADER_LIB_FUNC adds library multiple times to $LIBS
by Roland Haas 01 Jun '23

01 Jun '23

#1334: CCTK_CHECK_HEADER_LIB_FUNC adds library multiple times to $LIBS Reporter: Frank Löffler Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): One could try and beautify the library list by removing consecutive identical libraries `m m m` or similar, which may help a bit but is not guaranteed to remove all possible redundant duplicates. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1334/cctk_check_header…

1 0

#1334: CCTK_CHECK_HEADER_LIB_FUNC adds library multiple times to $LIBS
by Roland Haas 01 Jun '23

01 Jun '23

#1334: CCTK_CHECK_HEADER_LIB_FUNC adds library multiple times to $LIBS Reporter: Frank Löffler Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): As @{557058:cf051f66-042f-4a92-a2c7-f2be5a7912de} mentions, adding a library multiple times is harmless. Sometimes, for static linking, it is even required if there are two libraries that require functions from each other. Eg. `libA` contains `funcA1` and `funcA2`. `funcA1` calls `funcB1` in `libB` which itself calls `funcA2` in `libA`. The way to link these correctly for static linking is `-lA -lB -lA` that is one has to repeat one $or the other$ of the libraries since the linker acts on the library list only once and does so sequentially and will only include objects from a library that if it _already_ knows that the object is required when it processes the library file. This may not be an issue for `CCTK_CHECK_HEADER_LIB_FUNC` if it only ever uses a single library, but would be an issue if it ever added two libraries since `-lA -lB -lA -lB` is not the same as `-lA -lB`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1334/cctk_check_header…

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac June 2023