Trac

trac@lists.einsteintoolkit.org

8708 discussions

#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

#2712: KadathThorn build script contains GNUisms
by Roland Haas 01 Jun '23

01 Jun '23

#2712: KadathThorn build script contains GNUisms Reporter: Roland Haas Status: resolved Milestone: ET_2023_05 Version: Type: bug Priority: major Component: Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2712/kadaththorn-build…

1 0

#2734: Consider adding if statement functionality to read/write declarations
by Samuel Cupp 31 May '23

31 May '23

#2734: Consider adding if statement functionality to read/write declarations Reporter: Samuel Cupp Status: new Milestone: Version: Type: enhancement Priority: minor Component: Cactus Currently, the read/write declarations are a compile-time setting. This is usually fine. For a function that is scheduled in multiple places with different rd/wr, Cactus takes a union of all declarations for generating the function-specific macros. However, one case can lead to additional complications in scheduling. If a function has many different _if_ statements inside it controlling behavior at runtime $see e.g. GRHydro for the worst case scenario of this type of runtime-dependent scheduling$, then properly setting the rd/wr declarations will require either ignoring the actual behavior of the code and hoping for the best **or** having all of those _if_ statements reproduced inside the schedule.ccl. The former can bypass some safety checks and enforcement of good code behavior, while the latter causes excessive bloat in the schedule.ccl. ‌ A preferable alternative would be to allow rd/wr declarations to have runtime tags/conditionals/something that can turn them on/off depending on parameters. An easy example is `IllinoisGRMHD`'s conserv\_to\_prims function, which writes the primitives, conservatives, and $if update\_Tmunu$ the stress-energy tensor. Right now, the only way to explicitly give this data dependency would be $focusing on the WRITES declarations$ ``` if (update_Tmunu) { schedule IllinoisGRMHD_conserv_to_prims { LANG: C READS: stuff WRITES: prims, cons, Tmunu } "" } else { schedule IllinoisGRMHD_conserv_to_prims { LANG: C READS: stuff WRITES: prims, cons } "" } ``` Instead, it would be convenient to say ``` schedule IllinoisGRMHD_conserv_to_prims { LANG: C READS: stuff WRITES: prims, cons WRITES: Tmunu if update_Tmunu } "" ``` or something equivalent. This not only gives the ability to more accurately state the data dependencies, it also allows for more compact scheduling of complicated functions while still allowing for them to be controlled using runtime parameters. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2734/consider-adding-i…

1 0

#2723: No boundary conditions registered for variables in group LEANBSSNMOL
by Samuel Cupp 31 May '23

31 May '23

1 0

#2723: No boundary conditions registered for variables in group LEANBSSNMOL
by Samuel Cupp 31 May '23

31 May '23

#2723: No boundary conditions registered for variables in group LEANBSSNMOL Reporter: Vikram Manikantan Status: new Milestone: ET_2023_05 Version: ET_2022_11 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): I’ve never used this thorn, but I can hazard a guess. On the master branch, the function `LeanBSSN_Boundaries` doesn’t run until ``` schedule LeanBSSN_Boundaries in MoL_PostStep { LANG: Fortran OPTIONS: LEVEL SYNC: ADMBase::lapse SYNC: ADMBase::shift SYNC: LeanBSSNMoL::conf_fac SYNC: LeanBSSNMoL::hmetric SYNC: LeanBSSNMoL::hcurv SYNC: LeanBSSNMoL::trk SYNC: LeanBSSNMoL::gammat } "MoL boundary enforcement" ``` In the old approach, boundary conditions and ghost zone synchronization were completely independent. Now, we simply do both at the same time. Hence, scheduling like ``` schedule LeanBSSN_adm2bssn at CCTK_INITIAL after ADMBase_PostInitial { LANG: Fortran OPTIONS: Local SYNC: gammat } "Convert initial data into BSSN variables" ``` will naturally trigger warnings if there are no BCs yet. Additionally, the old method didn’t make it clear that the ApplyBCs scheduled at CCTK\_INITIAL was an empty call that did nothing. Since the registered BCs look to be `none`, it doesn't actually matter. I thought this was resolved in [Issue #2648](https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-conditions-registered-for). However, the changes aren’t in master. This ticket changed ``` schedule LeanBSSN_adm2bssn at CCTK_INITIAL after ADMBase_PostInitial { LANG: Fortran OPTIONS: Local SYNC: gammat } "Convert initial data into BSSN variables" schedule GROUP ApplyBCs as LeanBSSN_ApplyBCs at CCTK_INITIAL after LeanBSSN_adm2bssn { } "Apply boundary conditions" ``` to ``` schedule LeanBSSN_adm2bssn at CCTK_INITIAL after ADMBase_PostInitial { LANG: Fortran OPTIONS: Local } "Convert initial data into BSSN variables" schedule LeanBSSN_Boundaries at CCTK_INITIAL after LeanBSSN_adm2bssn { LANG: Fortran OPTIONS: LEVEL SYNC: LeanBSSNMoL::gammat } "Boundary enforcement" schedule GROUP ApplyBCs as LeanBSSN_ApplyBCs at CCTK_INITIAL after LeanBSSN_adm2bssn { } "Apply boundary conditions" ``` It looks like this change **is** in the development branch. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2723/no-boundary-condi…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac