Trac October 2013

trac@lists.einsteintoolkit.org

1 participants
148 discussions

[Einstein Toolkit] #1425: git repositories checkout into main tree
by Einstein Toolkit 28 Oct '13

28 Oct '13

#1425: git repositories checkout into main tree ---------------------------+------------------------------------------------ Reporter: knarf | Owner: eric9 Type: enhancement | Status: new Priority: major | Milestone: ET_2013_11 Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ GetComponents should only use 'repos' for git clones if it has to, i.e., if the thorn/arrangement is deeper within the repository. If the repository only contains one thorn, and that thorn is what should be checked out, then we should check it out directly into its arrangement. Also, if we are going to have arrangement-repos in the future, these should also be checked out directly into the main tree. We need to figure out how to teach this to GetComponents, while still telling Cactus about all the contained thorns it should build. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1425> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1462: use Cray pointers instead of Fotran ones in GRHydro
by Einstein Toolkit 26 Oct '13

26 Oct '13

#1462: use Cray pointers instead of Fotran ones in GRHydro -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro | -----------------------------------+---------------------------------------- this works around very slow compilation times when using intel 12. Not sure if this makes the code faster or slower at runtime. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1462> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1460: Timer improvement
by Einstein Toolkit 26 Oct '13

26 Oct '13

#1460: Timer improvement -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- I have added some timers and optional barriers for interpolation in CarpetInterp2, as well as enabling output for all clocks in the timer tree XML files. This work is in the ianhinder/interptimers branch (http://git.carpetcode.org/carpet.git/shortlog/ae71ad5e952a892c7b4a326daa078…) of Carpet. OK to merge? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1460> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1461: provide dTickets/dt or dChanges/dt plots on statistics page
by Einstein Toolkit 25 Oct '13

25 Oct '13

#1461: provide dTickets/dt or dChanges/dt plots on statistics page ----------------------------------+----------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit trac | Version: development version Keywords: | ----------------------------------+----------------------------------------- we have a large number of tickets so the plots on the statistics page that show the total number of tickets/changes are making it hard to judge how much activity there really is since all have a large offset. It might be useful to provide tickets-opened/closed-per-week plots as well. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1461> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1066: Implement IMEX integrators in MoL
by Einstein Toolkit 25 Oct '13

25 Oct '13

#1066: Implement IMEX integrators in MoL -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Dana Alic contributed an implementation of IMEX integrators for MoL. I attach the implementation as a patch (based on r133 of MoL). The implementation is well tested. The patch does not apply cleanly, and seems to make some modifications to the schedule etc. as well that have since been superseded by other changes to MoL. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1066> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #652: CACTUS_CONFIGS_DIR should be documented
by Einstein Toolkit 23 Oct '13

23 Oct '13

#652: CACTUS_CONFIGS_DIR should be documented -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- At the moment CACTUS_CONFIGS_DIR is only mentioned in doc/FAQ. It should be documented in the regular documentation as well. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/652> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1429: Assertion error when using "eval" & new UIUC speedup in TwoPunctures
by Einstein Toolkit 23 Oct '13

23 Oct '13

#1429: Assertion error when using "eval" & new UIUC speedup in TwoPunctures --------------------------------------+------------------------------------- Reporter: bernard.j.kelly@… | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: development version Keywords: TwoPunctures, malloc | --------------------------------------+------------------------------------- Hi. The new, more efficient, "eval" branch of TwoPunctures is generating a problem in certain cases. I had a job using this code (brought over from the trunk to my ET_2013_05 release), and it failed with an assertion error in TP_utilities.c, within the "d3tensor" allocation routine. I'm attaching a sample parameter file and the associated SCROUT + SCRERR for a small version of this case. It was run on 2 Nehalem nodes (8 cores each; no OpenMP), using an executable compiled with -O3 level optimisation using Intel-2013 compilers and SGI's MPT implementation of MPI. Here's the actual error message in the SCROUT+ERR file: {{{ TP_utilities.c:146: TP_d3tensor: Assertion `retval[i][nch]-retval[i][ncl] == (nch-ncl)*depth' failed. }}} I've looked at the d3tensor allocation routine in TP_utilities.c, and it seems to have several problems: * it has an actual bug in line 115: {{{ retval[0][0] = malloc(sizeof(CCTK_REAL)*(nrh-nrl+1)*(nch-ncl+1)*(nrh- nrl+1)); }}} --- the last factor should be (ndh-ndl+1), ''not'' (nrh-nrl+1) * even without that bug, the size allocated is too long by one in each dimension, when called by other TP routines, as, in fact, are *all* these TP_utilities routines. * the way in which memory is allocated seems to assume contiguous memory chunks (I suspect this is the real problem, given the error message). * all the routines in TP_utilities.c use "int" and "long" instead of "CCTK_INT" -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1429> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 17

[Einstein Toolkit] #963: Improve McLachlan accuracy
by Einstein Toolkit 15 Oct '13

15 Oct '13

#963: Improve McLachlan accuracy -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- James van Meter provided me with an optimised version of McLachlan. He states: 1. You are not taking full advantage of the chi=exp(-2phi) variable. There are several terms you divide by chi or chi^2 in expressions with overall factors exp(-4phi). I rewrote the BSSN equations to make these cancellations before coding. So where you have an expression of the form chi^2(A+B/chi^2), I have chi^2A+B. This gives a slight but noticeable advantage in both accuracy and performance. 2. I added Hamiltonian-constraint-damping terms due to Duez et al. These terms don't seem to be well-known but they are effective. 3. I added a Gamma-constraint-damping term due to Yo et al. 4. I enforce det(g)=1. I have not tested this new version yet, but James suggests to include it into the Einstein Toolkit. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/963> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #1449: CarpetLib dh:gfs needs to be traversed in order of variable index
by Einstein Toolkit 15 Oct '13

15 Oct '13

#1449: CarpetLib dh:gfs needs to be traversed in order of variable index --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- Commit 9166952 "CarpetLib: Store registered gh, dh, th, gf, data etc. via sets, not via lists" replaced list<ggf*> dh::gfs by set<ggf*> dh::gfs. Unfortunately some code assumes that these containers are iterated over from varindex=0 to the last varindex. The set however is sorted by the address of the ggf structures it holds (the list was sorted by creation order which apparently happened to coincide with the variable index). The bug manifests when storage is allocated for vectors of grid functions (eg vel[]) and recompose_allocate is called on vel[1] before vel[0]. Since only vel[0] actually allocactes memory vel[1] tries to refer to this memory and assert()s when trying to access not yet existing timelevels. The attached patches (each!) fix the issues, once by using a vector<ggf*> indexed by the varindex which allows for simple iterators but comes at the price of having to deal with NULL pointers for not-yet registered ggfs. The second uses a map<int,ggf*> which avoids this problem but comes at the price of having to deal with pairs for iterators. Making the set<ggf*> sorted by variable index is possible but awkward since C++ requires the sorting callback (type) to be part of the set type, ie one needs something like set<ggf*,bool(*)(ggf*const,ggf*const)> as the type of the container. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1449> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1455: CCTK_InterpGridArrays should give an error if an input variable index is -1
by Einstein Toolkit 15 Oct '13

15 Oct '13

#1455: CCTK_InterpGridArrays should give an error if an input variable index is -1 --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- CCTK_InterpGridArrays takes as input a list of indices of Cactus variables to interpolate. If one of these indices is -1, no error is given, and meaningless data is returned for this variable (probably from another gridfunction). This can happen easily if you get the variable index using CCTK_VarIndex and make a spelling mistake in the variable name, and don't check the return value. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1455> 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 October 2013