Trac November 2013

trac@lists.einsteintoolkit.org

1 participants
148 discussions

[Einstein Toolkit] #1193: CarpetReduce uses lsh for index calculations
by Einstein Toolkit 24 Oct '17

24 Oct '17

#1193: CarpetReduce uses lsh for index calculations --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2013_05 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- CarpetReduce (e.g. reduce.cc:644) uses lsh to calculate GF indices. This is wrong in case lsh!=ash. Either use ash or the Cactus macros (which would probably be even better). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1193> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1181: Parameter file parsing error message is hidden
by Einstein Toolkit 24 Oct '17

24 Oct '17

#1181: Parameter file parsing error message is hidden ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- Parse errors in parameter files are hidden among other output, and are thus difficult to spot. This example shows this: {{{ cactus::cctk_itlast = 3 ; ActiveThorns = "HDF5" }}} The problem is that the error message is output among the activation messages. If the parameter file is long and the syntax error is in the beginning, then several hundred lines may be output after the error message, which makes it very difficult to spot it. The parsing errors should be output in the same way as other parameter errors, which are prefixed by WARNING etc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1181> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[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] #1494: Allow skipping of MoL_PostStep and MoL_PseudoEvolutionBoundaries in POSTRESTRICT
by Einstein Toolkit 24 Oct '17

24 Oct '17

#1494: Allow skipping of MoL_PostStep and MoL_PseudoEvolutionBoundaries in POSTRESTRICT -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- It is not always necessary to call MoL_PostStep and MoL_PseudoEvolutionBoundaries in POSTRESTRICT, and it can introduce a performance penalty. The main reason for these calls is that restriction does not fill (outer or symmetry) boundary points, and this is usually done in MoL_PostStep. MoL_PseudoEvolutionBoundaries also sets boundary conditions. However, if restriction does not modify boundary points, for example in the case that boundary points are always far from refined regions, there is no reason to apply boundary conditions (e.g. by calling MoL_PostStep) after restriction. Eventually, Carpet and MoL should be modified to determine automatically whether the BCs need to be applied, but until that is implemented, the attached patch provides parameters for careful users to optimise their simulations in the case where this is safe to do. Additionally, recalculations performed in MoL_PostStep may replace more accurate restricted values computed on finer grids, leading to a loss of accuracy. OK to commit? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1494> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2013