Trac October 2022

trac@lists.einsteintoolkit.org

1 participants
87 discussions

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily
by Samuel Cupp 06 Oct '22

06 Oct '22

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: major Component: Carpet Comment (by Samuel Cupp): I’ve verified that this fixes the behavior, though actually iterating through all the variables in the pre\_groups on every level for every sync is slower than simply commenting out the recursion \(~17 time/hr vs ~19 time/hr\). I think that we should consider whether this check is necessary or not, and if it is then see if there’s any way to improve the method. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2653/carpet-presync-tr…

1 0

#2654: PR for ADMAnalysis Trace function with incorrect interface
by Samuel Cupp 06 Oct '22

06 Oct '22

#2654: PR for ADMAnalysis Trace function with incorrect interface Reporter: Samuel Cupp Status: new Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn Comment (by Samuel Cupp): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2654/pr-for-admanalysi…

1 0

#2654: PR for ADMAnalysis Trace function with incorrect interface
by Samuel Cupp 06 Oct '22

06 Oct '22

#2654: PR for ADMAnalysis Trace function with incorrect interface Reporter: Samuel Cupp Status: new Milestone: Version: development version Type: bug Priority: minor Component: EinsteinToolkit thorn The new macros that came with PreSync set read-only variables to const, which led to compiler warnings appearing in ADMAnalysis because Trace does not respect these consts. I fixed the consts, but I also noticed in the process that the interface.ccl lists the tensor Trace is tracing is listed as OUT instead of IN. I created a [pull request](https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-reques… with these changes. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2654/pr-for-admanalysi…

1 0

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily
by Samuel Cupp 06 Oct '22

06 Oct '22

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: major Component: Carpet Comment (by Samuel Cupp): I pushed a branch and made a [pull request](https://bitbucket.org/eschnett/carpet/pull-requests/54/carpet-adde…. I’m doing some final testing now to verify that it behaves as I expect \(that is to say, it removes the extra calls just like commenting out the recursion does\). I’ll comment again when I’m done. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2653/carpet-presync-tr…

1 0

#2650: Fixing WRITE statements for MoL scalars
by Samuel Cupp 06 Oct '22

06 Oct '22

#2650: Fixing WRITE statements for MoL scalars Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: minor Component: Cactus Comment (by Samuel Cupp): I have tested this branch, and it does stop the incorrect behavior. I support merging this fix in once the various comments on the PR are resolved. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2650/fixing-write-stat…

1 0

#2650: Fixing WRITE statements for MoL scalars
by Steven R. Brandt 06 Oct '22

06 Oct '22

#2650: Fixing WRITE statements for MoL scalars Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: minor Component: Cactus Comment (by Steven R. Brandt): Here is a pull request that fixes this issue for your enjoyment: [https://bitbucket.org/cactuscode/cactus/pull-requests/145/implement-scalars… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2650/fixing-write-stat…

1 0

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily
by Samuel Cupp 05 Oct '22

05 Oct '22

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: major Component: Carpet Comment (by Samuel Cupp): I haven’t yet run a simulation with a lot of reflevels, but I verified that this code doesn’t call `SyncProlongateGroups` except for the current reflevel when coarser levels don’t need to be synced. Thus, it is equivalent to commenting out the loop. The only added time will be from looping over the groups and comparing ints at each reflevel, which should be negligible. I’ll run the BaikalVacuum with this and check performance. Since I don’t have a code where the coarser levels aren’t synced before getting to the finer level, I can’t do a ‘real’ test of the case where this loop is actually necessary. I’m still not convinced that’s something that can happen without a thorn having incorrect reads/writes. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2653/carpet-presync-tr…

1 0

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily
by Steven R. Brandt 05 Oct '22

05 Oct '22

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: major Component: Carpet Comment (by Steven R. Brandt): @{557058:088051f9-5b94-4b5e-bfbe-71137030b9c1} does this fix the performance? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2653/carpet-presync-tr…

1 0

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily
by Samuel Cupp 05 Oct '22

05 Oct '22

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: major Component: Carpet Comment (by Samuel Cupp): I attempted to put in some logic to check whether it should actually call SyncProlongateBoundaries. Leaving the recursion loop unchanged, I have ``` std::vector<int> check_groups; std::set<int> tmpgroups; for (int g = 0; g < pre_groups.size(); g++) { int gi = pre_groups[g]; for (int vi = 0; vi < CCTK_NumVarsInGroupI(gi); vi++) { int const map0 = 0; ggf *const ff = arrdata.AT(gi).AT(map0).data.AT(vi); assert(ff); int const valid = ff->valid(mglevel, reflevel, timelevel); if (not is_set(valid, CCTK_VALID_EVERYWHERE)) { tmpgroups.insert(gi); break; } } } check_groups.assign(tmpgroups.begin(), tmpgroups.end()); if(!check_groups.empty()) { // ask Carpet to do the SYNC, this will apply BC as well SyncProlongateGroups(cctkGH, check_groups, attribute); } ``` This loops over the groups in pre\_groups. It then loops over the variables in each group and checks if they are valid everywhere. If not, then the group is added to tmpgroups and the loops are cycled to the next group. At the end, the vector check\_groups is assigned all the group indices that need to be passed on. I mimicked what is done in the PreCheckValid function, so all of this should be fine. I did this here because it will be a bit more complicated to do it in SyncProlongateBoundaries because we will have to do it separately for syncs and BC application. There’s also a ProlongateBoundaries call that I don’t know what logic I would need to use. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2653/carpet-presync-tr…

1 0

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily
by Samuel Cupp 05 Oct '22

05 Oct '22

#2653: Carpet PreSync triggering syncs for all refinement levels unnecessarily Reporter: Samuel Cupp Status: new Milestone: Version: Type: bug Priority: major Component: Carpet Comment (by Samuel Cupp): I also feel I should add that I’m not convinced that this recursive behavior is necessary. Do we actually need to do this? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2653/carpet-presync-tr…

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 October 2022