Trac May 2023

trac@lists.einsteintoolkit.org

1 participants
109 discussions

#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

#2733: TwoPunctures contains globally visible symbols not prefixed by thorn name
by Roland Haas 30 May '23

30 May '23

#2733: TwoPunctures contains globally visible symbols not prefixed by thorn name Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: TwoPunctures contains a number of functions \(and possibly global variables\) that are not prefixed by the thorn name and thus cause name clashes. This is most obvious when one compares the derived codes `TwoPunctures_BBHSF` and `TwoPunctures_KerrProca` to `TwoPunctures` \(eg using `diff -ur`\) since the derived codes already added the prefixes. This should however also be fixed in `TwoPunctures` since some of the names are very generic \(eg `Index()` and `interpol`\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2733/twopunctures-cont…

1 0

#2387: move CactusCode.org to be hosted by github pages
by Roland Haas 26 May '23

26 May '23

#2387: move CactusCode.org to be hosted by github pages Reporter: Roland Haas Status: resolved Milestone: Version: Type: task Priority: major Component: Cactus website Changes (by Roland Haas): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2387/move-cactuscodeor…

1 0

#2387: move CactusCode.org to be hosted by github pages
by Roland Haas 26 May '23

26 May '23

#2387: move CactusCode.org to be hosted by github pages Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: Cactus website Comment (by Roland Haas): [http://www.cactuscode.org](http://www.cactuscode.org) moved to github pages in 2020 \(see [https://github.com/EinsteinToolkit/www.cactuscode.org/issues/19](https://gi…). Git hash [e825525d](https://bitbucket.org/cactuscode/cactus/commits/e825525d1866fda1e… "Cactus: remove link to removed wavetoy demo server" of [cactus](https://bitbucket.org/cactuscode/cactus) removes the now dead link. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2387/move-cactuscodeor…

1 0

#2732: leftover reverences to nds-org docker image and files in ET tutorial
by Roland Haas 25 May '23

25 May '23

#2732: leftover reverences to nds-org docker image and files in ET tutorial Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit website For the ET\_2023\_05 release we moved the repository hosting the ET notebook tutorial files \(jupyter notebooks, images, docker files\) from nds-org’s GitHub repo to einsteintoolkit/jupyter-et to simplify granting write access to ET developers. Currently there is at least one leftover reference to nds-org in the tutorial files. In CactusTutorial.ipynb it says: > This notebook is intended to be used online on the Einstein Toolkit tutorial server, offline as a read-only document, as a jupyter notebook that you can download and also in your own docker container using `nds-org/jupyter-et`. To make all of these work some setting need to be tweaked, which we do in the next cell. ‌ and there is no obvious docker image candidate in the einsteintoolkit dockerhub org to replace that with. The ones available are: ![](https://bitbucket.org/repo/8zBLME5/images/1886879992-image.png) ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2732/leftover-reverenc…

1 0

#2731: check for incomplete perl install when use requests parallel checkout
by Roland Haas 25 May '23

25 May '23

#2731: check for incomplete perl install when use requests parallel checkout Reporter: Roland Haas Status: resolved Milestone: Version: Type: bug Priority: minor Component: GetComponents Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2731/check-for-incompl…

1 0

#2731: check for incomplete perl install when use requests parallel checkout
by Roland Haas 25 May '23

25 May '23

#2731: check for incomplete perl install when use requests parallel checkout Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: GetComponents Comment (by Roland Haas): Applied as git hash [172d861](https://github.com/gridaphobe/CRL/commits/172d861bc4f96816c43183bc… "GetComponents: abort if --parallel is passed but Perl has no threads" of [CRL](https://github.com/gridaphobe/CRL) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2731/check-for-incompl…

1 0

#2731: check for incomplete perl install when use requests parallel checkout
by Roland Haas 25 May '23

25 May '23

#2731: check for incomplete perl install when use requests parallel checkout Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: GetComponents Comment (by Roland Haas): Steve says: please apply \(in pull request\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2731/check-for-incompl…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2023