Trac

trac@lists.einsteintoolkit.org

8708 discussions

#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

#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): To expand on this, the code in regrid\(\) is ``` void th::regrid() { CCTK_REAL const basetime = 0.0; CCTK_REAL const basedelta = 1.0; const int old_mglevels = times.size(); times.resize(h.mglevels()); deltas.resize(h.mglevels()); for (int ml = 0; ml < h.mglevels(); ++ml) { const int old_reflevels = times.AT(ml).size(); times.AT(ml).resize(h.reflevels()); deltas.AT(ml).resize(h.reflevels()); for (int rl = 0; rl < h.reflevels(); ++rl) { if (ml == 0) { deltas.AT(ml).AT(rl) = basedelta / reffacts.AT(rl); } else { deltas.AT(ml).AT(rl) = deltas.AT(ml - 1).AT(rl) * h.mgfact; } ``` As seen here, in line 14 deltas is always 1.0/reffacts, which is just 1 for the coarser grids. For PreSync, some synchronization/BCs are applied during the short period in which this is 1, and that doesn’t occur without PreSync. I believe this is where the incorrect time slips in. Since it quickly resets the deltas, most of the times afterward are correct. It’s only until later with the next call to CycleTimeLevels that this inconsistency finally breaks the code. I believe that basedelta should be set to the dt of the coarsest timelevel. At the very least, doing this explicitly for my case fixes the error. I haven’t verified that the codes produce the same results, but it seems like a reasonable choice instead of a random default of 1. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2639/carpetlib-interna…

1 0

#2647: incorrect WENO coefficient in GRHydro WENO reconstruction code
by Roland Haas 27 Sep '22

27 Sep '22

#2647: incorrect WENO coefficient in GRHydro WENO reconstruction code Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): responsible: [] (was ) assignee: Roland Haas (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2647/incorrect-weno-co…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac