Trac March 2013

trac@lists.einsteintoolkit.org

1 participants
161 discussions

[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] #1210: CarpetIOASCII should not write column names info each iteration
by Einstein Toolkit 01 Jun '14

01 Jun '14

#1210: CarpetIOASCII should not write column names info each iteration --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- Currently, CarpetIOASCII writes the column names header each iteration, leading to bloated output - easily double the size of what should suffice. Once after file creation would be much better. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1210> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1302: Reduce time spent in deciding not to do output.
by Einstein Toolkit 21 May '14

21 May '14

#1302: Reduce time spent in deciding not to do output. --------------------------------------+------------------------------------- Reporter: diener | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: performance optimization | --------------------------------------+------------------------------------- I noticed, during some scaling tests, that for my code a significant amount of time was spent by CarpetIOASCII, even though I only had it activated and didn't actually request any output. The reason is that in order to figure out whether to do output or not, there is a loop over all grid variables and a routine (TimeToOutput) is called. In this routine there is a check if the out_dir and out_vars parameters have been steered and if so update some internal data structures. It should be sufficient to do this before entering the loop over grid variables. The same issue is present in CarpetIOScalar and CarpetIOHDF5. The attached patches for CarpetIOASCII, CarpetIOScalar and CarpetIOHDF5 moves this check outside of the loop over grid variables and in addition bypasses the loop completely if the out_vars parameter string is the empty string. Note that the code where I noticed this problem uses large vectors of 1D grid arrays, and it turns out that Cactus counts each vector element as a distinct grid variables and the length of the loop over grid variables in my case was close to 100.000, which might explain why nobody has noticed this before. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1302> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1207: Einstein toolkit sites with invalid security certificates
by Einstein Toolkit 19 May '14

19 May '14

#1207: Einstein toolkit sites with invalid security certificates -------------------------------------+-------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- https://einsteintoolkit.org exists but has an invalid security certificate (http://www.sslshopper.com/ssl-checker.html#hostname=einsteintoolkit.org). I don't think we need SSL/TLS on this server. It should either be disabled or a valid certificate used. The same applies to https://cactuscode.org (http://www.sslshopper.com/ssl- checker.html#hostname=cactuscode.org). Note that Frank's page (http://www.cct.lsu.edu/~knarf/cgi-bin/monitor.cgi) reports these certificates as self-signed; they are also expired. Self- signed certificates on public websites are bad: they encourage people to click through the warnings. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1207> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #590: McLachlan should allow other thorns to set the gauge
by Einstein Toolkit 28 Apr '14

28 Apr '14

#590: McLachlan should allow other thorns to set the gauge -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The parameters lapse_evolution_method and shift_evolution_method are usually set to ML_BSSN in McLachlan. However they are never checked in the code. McLachlan indeed seems to ignore their values and overwrite whatever the values of lapse or shift set elsewhere, preventing therefore other thorns from setting them differently. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/590> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 22

[Einstein Toolkit] #1215: Source browsing not working
by Einstein Toolkit 24 Apr '14

24 Apr '14

#1215: Source browsing not working ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- The repositories in the "Browse source" TRAC interface (https://trac.einsteintoolkit.org/browser) are not being updated. The last Cactus flesh commit visible there is from 10 months ago. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1215> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #849: Drop explicit support for Fortran 77 in Cactus
by Einstein Toolkit 19 Apr '14

19 Apr '14

#849: Drop explicit support for Fortran 77 in Cactus -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I suggest to drop explicit support for Fortran 77 in Cactus. Fortran 77 is, for all practical purposes, a subset of Fortran 90, and thus Fortran 77 code can be compiled by Fortran 90 compilers. There is currently no platform that has a Fortran 77 and no Fortran 90 compiler, and there is no Fortran source code in Cactus that cannot be compiled by a Fortran 90 compiler. In a way, supporting Fortran 77 as language is similar to supporting K&R C as a language. We don't do this either. I suggest to remove/ignore all configuration options regarding Fortran 77, and to compile .f77 and .F77 files with a Fortran 90 compiler. This change will simplify the configuration stage of Cactus. I don't expect any user to notice. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/849> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #882: Create ThornGuideHTML target
by Einstein Toolkit 14 Mar '14

14 Mar '14

#882: Create ThornGuideHTML target ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- Barry Wardell suggests: The only issue is that there doesn't seem to be a HTML version of the configuration specific ThornGuide make target, so we should add this as a target at the same time as removing the patch. I'd imagine this would just be a matter of copy-and-paste from the existing ThornGuideHTML target. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/882> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1117: Wrong CarpetIOASCII headers for complex 2D output.
by Einstein Toolkit 25 Jan '14

25 Jan '14

#1117: Wrong CarpetIOASCII headers for complex 2D output. ----------------------------------------+----------------------------------- Reporter: reisswig@… | Type: defect Status: new | Priority: minor Milestone: | Component: Other Version: | Keywords: ----------------------------------------+----------------------------------- I am outputting a 2d _complex_ array (called "extracted_vars") using 2d CarpetIOASCII output. Using the standard output format, the data starts at column 13. So the first array element "extracted_vars[0]" is at column 13. Now, since I have a complex array, the second element, "extracted_vars[1]", must be at column 15 (column 14 contains the imaginary part of element [0]). In older versions of Carpet, this was reported correctly in the header. In the current version, it is incorrect. The second element, "extracted_vars[1]" is reported to be in column 14 instead of 15. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1117> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

← Newer
1
...
4
5
6
7
8
9
10
...
17
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2013