Trac September 2013

trac@lists.einsteintoolkit.org

1 participants
141 discussions

[Einstein Toolkit] #1430: out-of-bounds write access checking in Cactus
by Einstein Toolkit 27 Sep '13

27 Sep '13

#1430: out-of-bounds write access checking in Cactus -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- I possibly very useful (and simple to implement) debugging help in Cactus would be if the Cactus driver provided some means to detect array accesses out of the array/grid-function bounds. In general that is hard to do (in C, for Fortran there are compiler switches) however a possible useful partial solution might already be to put canary values before and after the user-visible data of grid functions/grid arrays. The flesh/driver could then check after each scheduled routine if any of the canary values were modified and if so output a warning. Schematically the layout in memory would be Canary1 data Canary2 and CCTK_VarDataPtr would return a pointer to "data" only. After a scheduled function all we check Canary1 and Canary2 and output an error if they are corrupted. Similarly the IncreaseGroupStorage/DecreaseGroupStorage routines could set/check the canary values. This would prevent these errors triggering failures at some later unrelated call to malloc or free. glibc's malloc function provides some of this if _MALLOC_DEBUG is set, though I am not sure how well that actually works in practice in particular since eg OpenMP provides its own malloc function. I don't have an implementation of this right now and am mostly fishing for comments. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1430> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1443: Carpet commit bc08df4 break tests
by Einstein Toolkit 26 Sep '13

26 Sep '13

#1443: Carpet commit bc08df4 break tests --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- It initializes Carpet::timelevels with Carpet::maxtimelevels before the later has been set. The attached patch moves the initialization of timelevels after maxtimelevels. Not really pretty though since it moves it away from where timelevel is initialized. Somewhat related: shouldn't Jenkins send out email to the Users list if the tests fail? They do indeed fail but with the "no files were created" error (https://build.barrywardell.net/job/EinsteinToolkitProposed/541/console). Maybe that is the reason why no email are send or error detected? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1443> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1442: (small) diff in git commit messages
by Einstein Toolkit 24 Sep '13

24 Sep '13

#1442: (small) diff in git commit messages -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------+-------------------------------------------------- Commit messages from git repositories like carpet don't display a diff of changes, not even if it was as short as d37f25ab50b6155026196665c502864e9696dd5b (carpet). However, this would be quite useful (as usual limited to some length). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1442> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1441: Mode timer tree no longer supports multipatch
by Einstein Toolkit 24 Sep '13

24 Sep '13

#1441: Mode timer tree no longer supports multipatch --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- The parameter setting Carpet::include_maps_in_mode_timer_tree = yes does not work with the new timer tree code which includes a reduction across processes. This code expects all timers to exist on all processes, but with multipatch, and the above setting, local mode is not entered for all refinement levels on all processes (because not all processes have all maps), and the timer code aborts with the error "Timers are inconsistent across processes: root process expects timer [done], this process has timer enter_local_mode instead". One solution would be for the timers to be created and not started on the other processes. Another would be to modify the reduction code to allow missing timers on some processes. As a general goal, we are trying to move away from global knowledge and synchronisation across all processes. Such a goal favours making the reduction code more tolerant to each process having a different state. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1441> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1440: PITTNullCode lacks documentation
by Einstein Toolkit 23 Sep '13

23 Sep '13

#1440: PITTNullCode lacks documentation -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: PITTNull | -----------------------------------+---------------------------------------- currently the PITTNull code has not (Cactus) documentation and only refers toarXiv:1011.4223 in the README file of eg NullEvolve. I would like to have a section "Physical System" that gives definitions for the evolved variables, ideally also a section on the numerical implementation and in a perfect world and example on how to use it. The first two might conceivably be just sections from the relevant papers while the last could be from Yosef's CCE tutorial [http://ccrg.rit.edu/~yosef/cce.html]. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1440> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1437: Missing option for deterministic noise in CactusNumerical/Noise
by Einstein Toolkit 10 Sep '13

10 Sep '13

#1437: Missing option for deterministic noise in CactusNumerical/Noise -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Sometimes it would be very interesting to add some noise to GFs, but to do so in a deterministic way, i.e., when running the same par-file twice I would like to get the same noise, at least when run under the same conditions. Pseudo-PRNGs should be able to provide that, but care has to be taken to make this work consistently in parallel. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1437> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1436: update test data of CarpetProlongateTest
by Einstein Toolkit 10 Sep '13

10 Sep '13

#1436: update test data of CarpetProlongateTest --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- commit 4acaa0d0d3e59d6e618815515871f1f1115a6789 to Carpet removed an automated sync call. Since the tests do not behave like user thorns would (ie they do not schedule boundary calls after restriction since they want to verify restriction) their results changed. The attached patches regenerate data that changed. Generically the changes seem to be more zeros in the "difference" variables. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1436> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1434: remove non-conserved test data from Refluxing tests
by Einstein Toolkit 06 Sep '13

06 Sep '13

#1434: remove non-conserved test data from Refluxing tests -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: Refluxing | -----------------------------------+---------------------------------------- the attached patch removes all primitive variables from the test output. It removes the odd timesteps form the shift-atboundary test since the sum(convservatives) is only constant at even steps when there is no time interpolation for the reduction. It increases the threshold for the no- refluxing test to value used for other hydro tests. Ok to apply? With these all tests pass (without being regenerated). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1434> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1433: WeylScal4 and EinsteinExact tests should be run on 2 processes
by Einstein Toolkit 06 Sep '13

06 Sep '13

#1433: WeylScal4 and EinsteinExact tests should be run on 2 processes -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- WeylScal4 and EinsteinExact tests are currently run on 1 process only. If a single number of processes is going to be chosen, it should be 2, since this will test interprocess synchronisation. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1433> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1432: CarpetLib::poison_new_memory when aligning memory
by Einstein Toolkit 04 Sep '13

04 Sep '13

#1432: CarpetLib::poison_new_memory when aligning memory --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- looking at the poison code in CarpetLib's mem.cc it seems to me that the poisoning cdoe uses the wrong data pointer ie uses line 144 of mem.cc: {{{ total_allocated_bytes += nbytes; max_allocated_bytes = max (max_allocated_bytes, total_allocated_bytes); if (poison_new_memory) { memset (storage_, poison_value, nbytes); } }}} when in fact I think it should be {{{storage_base_}}} since this is the pointer to nbytes bytes of memory returned by malloc. Attached please find a patch which tries to address this. Note that this only matters on systems where the vector lenght is large enough so that the "natural" alignment provided by malloc (at least 4 bytes I'd assume more likely actually 8 bytes). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1432> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2013