Trac October 2013

trac@lists.einsteintoolkit.org

1 participants
148 discussions

[Einstein Toolkit] #1100: Correct backtrace generation in Carpet
by Einstein Toolkit 24 Oct '17

24 Oct '17

#1100: Correct backtrace generation in Carpet ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | ----------------------+----------------------------------------------------- The file backtrace.cc in CarpetLib does not #include <cctk.h>; hence all HAVE_BACKTRACE* macros are undefined, and only basic backtraces are generated. Correcting this is non-trivial, since the backtrace code is arcane, is written in C, probably expects glibc, contains (I'm fairly certain) memory allocation errors, and doesn't build e.g. on Mac OSX. The code also spends an inordinate amount of time allocating and freeing string buffers, which should be replaced by simply using C++ streams. The backtrace code also probably requires a few more autoconf tests, so that it can be disabled where it does not work. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1100> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #914: Don't use fork()
by Einstein Toolkit 24 Oct '17

24 Oct '17

#914: Don't use fork() -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- It seems that it is in many cases not safe to call fork() in MPI applications. This page <http://www.open-mpi.de/faq/?category=openfabrics #ofa-fork> has some information. The upshot seems to be: - In many (most) cases, one can call system() or popen() to execute external processes while waiting for them. - It is generally not safe to call fork() to execute a certain task in the background. However, it should be possible to use threads in this case. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/914> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #260: produce map of ET users
by Einstein Toolkit 24 Oct '17

24 Oct '17

#260: produce map of ET users -------------------------------------+-------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- It would be nice to produce an (autmatically generated) map of the locations of ET users -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/260> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #980: Remove support for the flesh-based MPI mechanism
by Einstein Toolkit 24 Oct '17

24 Oct '17

#980: Remove support for the flesh-based MPI mechanism -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The flesh-based MPI mechanism has just been deprecated in favour of ExternalLibraries/MPI. Even though the latter is new, it is probably a good idea to completely disable the old mechanism since having any mixture of thorns/optionlists using the old and new mechanisms is completely untested and will likely lead to problems and confusion. It's better to give a useful fatal error message if someone still specifies "MPI = " in their optionlist than to have things break in other weird and wonderful ways. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/980> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #64: Refactory/redesign archiving
by Einstein Toolkit 29 Aug '17

29 Aug '17

#64: Refactory/redesign archiving ------------------------+--------------------------------------------------- Reporter: mthomas | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- Implement archiving using archive machines with an iomethod key. Provide another key like rsync-excludes for people to exclude files from being archived. Provide a lightweight archive-like method for copying a simulation from one machine to another machine. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/64> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #984: SimFactory should store the optionlist used when building in the simulation directory
by Einstein Toolkit 31 Jul '17

31 Jul '17

#984: SimFactory should store the optionlist used when building in the simulation directory ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- SimFactory should store the optionlist used in the simulation directory -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/984> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #583: PITTNullCode lacks test case outputs
by Einstein Toolkit 13 Jun '17

13 Jun '17

#583: PITTNullCode lacks test case outputs -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The PITTNullCode arrangement has several test parameter files without associated output. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/583> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1390: parameter file parser aborts when findeing first error
by Einstein Toolkit 19 May '17

19 May '17

#1390: parameter file parser aborts when findeing first error --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The attached parfile contains multiple errors (one per line). However the parameter file parser only reports the first one, then stops. This makes verifying parfiles for correctness hard. It might be good to defer aborting until the end of the file or until a larger number of parsing errors were encountered. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1390> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1172: Remove unnecessary exp/log calls in EOS_Omni
by Einstein Toolkit 18 May '17

18 May '17

#1172: Remove unnecessary exp/log calls in EOS_Omni -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- EOS_Omni seems to call exp/log more often than necessary in the nuc_eos table lookup routines. Use algebraic identities to remove them. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1172> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #614: relative tolerence in test.ccl of QuasiLocalMeasures very high
by Einstein Toolkit 12 Apr '17

12 Apr '17

#614: relative tolerence in test.ccl of QuasiLocalMeasures very high -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- LSUThorns/QuasiLocalMeasures/test/test.ccl curerntly reads: {{{ ABSTOL 1.e-7 RELTOL 1.e+5 }}} I am curious: is the relative tolerance of 10,000 intentional or should it have been 1e-5 instead? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/614> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac October 2013