Trac July 2014

trac@lists.einsteintoolkit.org

1 participants
127 discussions

[Einstein Toolkit] #1633: backport MoL revision 225
by Einstein Toolkit 26 Aug '14

26 Aug '14

#1633: backport MoL revision 225 --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: MoL backport | --------------------------+------------------------------------------------- Before MoL did not initialize the RHS grid functions of the slow evolved variables to zero (but GRHydro did explicitly so this never showed up). Revision 225 adds the initialization. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1633> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #499: Prolongation fails with vectorisation enabled
by Einstein Toolkit 25 Aug '14

25 Aug '14

#499: Prolongation fails with vectorisation enabled --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- The development version of Carpet uses vectorisation to speed-up prolongation. This fails with various errors, including corruption of the malloc heap. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/499> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 23

[Einstein Toolkit] #445: Make Carpet timers hierarchical
by Einstein Toolkit 25 Aug '14

25 Aug '14

#445: Make Carpet timers hierarchical -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- With the current flat structure of timers in Carpet, it is difficult to identify which timers are contained in which other timers, and hence to avoid double-counting when adding up the times. This series of patches modifies the timer infrastructure in Carpet to generate a tree of timers where the hierarchy reflects the call-graph of the program. This makes it much easier to interpret the timer output than with the previous flat structure, where it was not possible to see which timers "contained" which others. More implementation details are given at the top of TimerNode.hh. Note that the Timer source and header files have been renamed as CactusTimer and a new Timer file and object has been created. This is because the Timer object now only provides a wrapper around the Cactus timer mechanism which was contained in the old Timer object. New parameters output_initialise_timer_tree and output_timer_tree_every control output of a new "timer tree diagram" to standard output for the Initialise and Evolve timer trees respectively. These diagrams indicate: 1. the value of each timer; 2. the percentage of the given tree taken by each timer; 3. which timers are contained in which other timers; 4. any untimed code for any timer which takes more than 1% of the tree time. Making the timers hierarchical means that the ad-hoc methods used before to identify the hierarchy (such as naming the timer Evolve::Sync, for example, to indicate that the Sync timer was a child of the Evolve timer) are no longer necessary and have been removed. Additionally, the construction of timers in a "dynamic" manner is now handled automatically for all timers, so special-case code is no longer needed and has been removed. Additionally some previously-untimed parts of the code are now timed, and timer names have been made more consistent in some places. There is code in the patches to output the entire timer tree as an XML file, but it is not enabled. Ideally the timer tree printed to standard output would contain reductions across processes, but at the moment it contains only the timer from the current process. The attached "tree-example.txt" file shows an example of the timer tree that is printed for a simulation using the qc0-mclachlan parameter file from the Einstein Toolkit. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/445> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #1618: Compile with adaptive MPI (based on Charm++)
by Einstein Toolkit 18 Aug '14

18 Aug '14

#1618: Compile with adaptive MPI (based on Charm++) ------------------------------+--------------------------------------------- Reporter: jtao@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | ------------------------------+--------------------------------------------- Gengbin Zheng, one of the leading developer of the Charm++ and I managed to get Cactus compile against the AMPI (http://charm.cs.illinois.edu/research/ampi). The patch against Revsion 5120 is attached. The major changes are in the flesh to deal with global variables. We started with PUGH to get started and changes in Carpet could be done later on. NR applications might not benefit from this work though this effort could make Cactus appealing to many other applications as a computational framework. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1618> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1649: HydroBase: add average atomic mass
by Einstein Toolkit 11 Aug '14

11 Aug '14

#1649: HydroBase: add average atomic mass ---------------------------------+------------------------------------------ Reporter: dradice@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | ---------------------------------+------------------------------------------ I would like to propose a patch to add a variable to HydroBase to be used to store the average atomic mass of the fluid during the evolution. This can be used, e.g., to do evolutions using a non-NSE equation of state. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1649> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1640: RK2-MR2-1 TestMoL test fails after MoL revision 225
by Einstein Toolkit 29 Jul '14

29 Jul '14

#1640: RK2-MR2-1 TestMoL test fails after MoL revision 225 -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: MoL | -----------------------------------+---------------------------------------- It seems as if it re-uses the RHS and 225 makes MoL clear the slow sector RHS the same way it clears the fast sector RHS. The results are silently wrong by a factor of 1/2 or so. This does not seem to happen in Jenkins but happens on my workstation (found while debugging another MoL related issue). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1640> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1643: cannot compile with release version of simfactory
by Einstein Toolkit 21 Jul '14

21 Jul '14

#1643: cannot compile with release version of simfactory ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: blocker | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- I just tried to compile with the release version of simfactory (on Gordon but that would not matter) and I get: {{{ [rhaas@gordon-ln1 Cactus]$ ./simfactory/bin/sim build --thornlist thornlists/NsNsToHMNS.th Error: required key email in section hal1 is missing Aborting Simfactory. }}} The same happens for the "user" key as well. This is most likely hidden for most users since keys in the [default] section of defs.ini.local hide this issue. email may make sense to specify in defs.local.ini but user would not seem like something that should be left to default since it is machine specific. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1643> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2014