Trac September 2022

trac@lists.einsteintoolkit.org

1 participants
67 discussions

#2652: ./ET_executable -O outputs about 19,000 lines
by Zach Etienne 30 Sep '22

30 Sep '22

#2652: ./ET_executable -O outputs about 19,000 lines Reporter: Zach Etienne Status: new Milestone: Version: Type: bug Priority: major Component: ``` -O[v], --describe-all-parameters : describes all the parameters. v makes this verbose, i.e., it gives a verbose description of all parameters. ``` When running the Einstein Toolkit executable with `--help`, the above command-line option appears. The 19,123 lines of output is terrifying, but could be made less so. For one thing, each element of a parameter array is shown individually, and many arrays have 100 elements. I think the output for arrays should be combined into a single line. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2652/et_executable-o-o…

1 0

#2651: New warning message for missing boundary conditions
by Samuel Cupp 30 Sep '22

30 Sep '22

#2651: New warning message for missing boundary conditions Reporter: Samuel Cupp Status: new Milestone: Version: Type: task Priority: minor Component: Carpet Changes (by Samuel Cupp): I have made a pull request adding a warning inside ApplyPhysicalBCsForGroupI for when variables have no boundary conditions registered. Originally, there was a _cout_ statement only if a preprocessor flag was defined. I have found that this warning helped me discover several mistakes that would have been very difficult to track down without it. The associated pull request is [here](https://bitbucket.org/eschnett/carpet/pull-requests/53/carpet-added-w…. For example, it made me realize that I never properly changed over BaikalVacuum’s BC selection to also register boundary conditions with the driver. If I had put this comment in earlier, my confusion about why the code was trying to sync\+apply BCs way too often would have been instantly solved. As another example, one function in BaikalVacuum reads one group everywhere and another interior. I had both everywhere, but the interior-only one has no BCs because it is only ever read on the interior. As such, I was triggering syncs for no reason. This warning pointed me to the real problem in my simulation very quickly, and this was causing my code to sync variables 24 \(RK4 \* variables in group\) times more per iteration. Finally, it led to me finding that MoL’s scheduling was trying to sync scalars \(see [Ticket #2650](https://bitbucket.org/einsteintoolkit/tickets/issues/2650/fixing-write-statements-for-mol-scalars)\). While not a performance issue like the above, this is incorrect behavior. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2651/new-warning-messa…

1 0

#2651: New warning message for missing boundary conditions
by Samuel Cupp 30 Sep '22

30 Sep '22

#2651: New warning message for missing boundary conditions Reporter: Samuel Cupp Status: new Milestone: Version: Type: task Priority: minor Component: Carpet This commit adds a warning inside ApplyPhysicalBCsForGroupI for when variables have no boundary conditions registered. Originally, there was a _cout_ statement only if a preprocessor flag was defined. I have found that this warning helped me discover several mistakes that would have been very difficult to track down without it. The associated pull request is [here](https://bitbucket.org/eschnett/carpet/pull-requests/53/carpet-added-w…. For example, it made me realize that I never properly changed over BaikalVacuum’s BC selection to also register boundary conditions with the driver. If I had put this comment in earlier, my confusion about why the code was trying to sync\+apply BCs way too often would have been instantly solved. As another example, one function in BaikalVacuum reads one group everywhere and another interior. I had both everywhere, but the interior-only one has no BCs because it is only ever read on the interior. As such, I was triggering syncs for no reason. This warning pointed me to the real problem in my simulation very quickly, and this was causing my code to sync variables 24 \(RK4 \* variables in group\) times more per iteration. Finally, it led to me finding that MoL’s scheduling was trying to sync scalars \(see [Ticket #2650](https://bitbucket.org/einsteintoolkit/tickets/issues/2650/fixing-write-statements-for-mol-scalars)\). While not a performance issue like the above, this is incorrect behavior. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2651/new-warning-messa…

1 0

#2650: Fixing WRITE statements for MoL scalars
by Samuel Cupp 29 Sep '22

29 Sep '22

#2650: Fixing WRITE statements for MoL scalars Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: minor Component: Cactus MoL implicitly sets the region when declaring the WRITES for its scalars. However, the default WRITE region for PreSync is currently ‘interior’, while scalars can only be written ‘everywhere'. This means that PreSync attempts to call SyncGroups and ApplyBCs on the scalar variables. It doesn’t actually do anything, as there’s no registered BCs and syncing a scalar does nothing. Still, there are quite a few empty function calls due to this. The WRITE statements in MoL should explicitly state ‘everywhere’, at least until PreSync is capable of automatically setting the WRITES of scalars to ‘everywhere’. I’ve made these changes, and the associated pull request is [here](https://bitbucket.org/cactuscode/cactusnumerical/pull-requests/17/mol…. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2650/fixing-write-stat…

1 0

#2649: Missing function Cartoon2D interface.ccl
by Samuel Cupp 29 Sep '22

29 Sep '22

#2649: Missing function Cartoon2D interface.ccl Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: minor Component: Cactus Cartoon2D uses Boundary\_SelectedGVs from the Boundary thorn, but it was missing from the interface.ccl. Since the function is defined implicitly, the compiler manages to figure it out at the linking stage. However, it should be added to the interface. The associated pull request is [here](https://bitbucket.org/cactuscode/cactusnumerical/pull-requests/16/car…. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2649/missing-function-…

1 0

#2648: Empty ApplyBCs call in LeanBSSNMoL
by Zach Etienne 29 Sep '22

29 Sep '22

#2648: Empty ApplyBCs call in LeanBSSNMoL Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Zach Etienne): I can confirm that I copied most of Lean’s scheduling when creating Baikal\*. It would be nice to know the reasoning behind the scheduling of this group in Lean. :\) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2648/empty-applybcs-ca…

1 0

#2648: Empty ApplyBCs call in LeanBSSNMoL
by Samuel Cupp 28 Sep '22

28 Sep '22

#2648: Empty ApplyBCs call in LeanBSSNMoL Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Samuel Cupp): This also appears in Baikal and BaikalVacuum, which may have copied this behavior from Lean. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2648/empty-applybcs-ca…

1 0

#2648: Empty ApplyBCs call in LeanBSSNMoL
by Samuel Cupp 28 Sep '22

28 Sep '22

#2648: Empty ApplyBCs call in LeanBSSNMoL Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn In the schedule.ccl of LeanBSSNMoL starting at line 55, the following ApplyBCs call is scheduled: ``` schedule GROUP ApplyBCs as LeanBSSN_ApplyBCs at CCTK_INITIAL after LeanBSSN_adm2bssn { } "Apply boundary conditions" ``` However, no boundary selection routines are scheduled before it. As far as I am aware, this is a do-nothing call. Should the function `LeanBSSN_Boundaries` be scheduled before this? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2648/empty-applybcs-ca…

1 0

#2639: CarpetLib internal error with PreSync and analysis thorns
by Samuel Cupp 27 Sep '22

27 Sep '22

#2639: CarpetLib internal error with PreSync and analysis thorns Reporter: Samuel Cupp Status: new Milestone: Version: development version Type: bug Priority: major Component: Carpet Comment (by Samuel Cupp): If I remember correctly, the timesteps for each reflevel have already been set by the time this runs. It’s the regridding that causes it to temporarily forget what the deltas are. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2639/carpetlib-interna…

1 0

#2639: CarpetLib internal error with PreSync and analysis thorns
by Roland Haas 27 Sep '22

27 Sep '22

#2639: CarpetLib internal error with PreSync and analysis thorns Reporter: Samuel Cupp Status: new Milestone: Version: development version Type: bug Priority: major Component: Carpet Comment (by Roland Haas): I woukd say @{557058:56049c54-f8c2-4b6c-9b88-ab697c967495} will have to weigh in on this one. Caroet does not actually itself know the timestep initially and squirrels it away when it is first set by thorn Time. Assuming basedelfa to be 1.0 does seem wrong though. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2639/carpetlib-interna…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2022