Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1198: Add an option to sim build to disable parallel building
by Einstein Toolkit 14 Dec '12

14 Dec '12

#1198: Add an option to sim build to disable parallel building -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- It would be useful to have an option to "sim build" to disable parallel build. We could then ask users to run with this when they have build problems so that we can clearly see the error. This would need a more structured "make" simfactory variable. Perhaps there could be a MAKE_TASKS variable, and then we could set "make = make -j@MAKE_TASKS@". MAKE_TASKS could be set either by an entry in the machine database, an option in the optionlist, or by simfactory when a --no-parallel-build option was set. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1198> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1196: Improve performance of Multipole interpolation
by Einstein Toolkit 12 Dec '12

12 Dec '12

#1196: Improve performance of Multipole interpolation -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- For codes which don't use OpenMP, the interpolation of a large number of points by Multipole limits performance in some situations. One workaround is to reduce the number of points, and possibly use one of the more accurate integration methods which is already implemented. Multipole performs interpolation by calling the standard Cactus interpolation API. To increase the speed of interpolation, Multipole could be modified to implement the interpolation interface from CarpetInterp2. I understand that the standard Cactus interpolation interface is not provided by CarpetInterp2 because more information needs to be passed than the interface allows. Was this just the fastest way to get something working, or is it really a fundamental problem? I thought that the major difference was that CarpetInterp2 computes and stores interpolation weights from the coordinates so that they can be used again in subsequent interpolations to the same points. Could the standard Cactus interpolation interface be used for this, perhaps by passing a table entry which says "store the interpolation coefficients for these points for later reuse"? This would allow existing codes to use faster interpolation without having their interpolation code rewritten to use the new interface. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1196> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1191: CaKernel not compiling under Cactus
by Einstein Toolkit 06 Dec '12

06 Dec '12

#1191: CaKernel not compiling under Cactus ---------------------------------+------------------------------------------ Reporter: marqs@… | Type: defect Status: new | Priority: major Milestone: | Component: Cactus Version: development version | Keywords: ---------------------------------+------------------------------------------ Hi, Cactus is not compiling with CaKernel. I wrote about it about a month ago to the "Users" list and it is related to std namespace not recognized by CUDA compiler in mathematical functions. I attach a patch. Erik can you submit it to trunk and branches/4.1? Regards, Marek Blazewicz -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1191> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1164: Checking out thorn in arrangements before flesh hinders flesh checkout
by Einstein Toolkit 02 Dec '12

02 Dec '12

#1164: Checking out thorn in arrangements before flesh hinders flesh checkout --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2013_05 Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- Checking out a thorn before the flesh creates the arrangements directory. When checking out the flesh (which contains this directory) an error occurs: {{{ svn: Failed to add directory 'arrangements': an unversioned directory of the same name already exists }}} Usually, this does not happen as the flesh is mentioned first in thornlists. However, when using parallel checkouts it might actually be the case (and did happen for me). Running the same command a second time didn't produce this problem, which confirms that this is very much timing- dependent. Possible solutions: 1) A notion to tell GetComponents about dependencies 2) A notion to tell Getcomponents about 'breakpoints', a poor-mans version of 1) 3) Removing the 'arrangements' directory from the flesh repository -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1164> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1187: Cactus allows for negative error level
by Einstein Toolkit 02 Dec '12

02 Dec '12

#1187: Cactus allows for negative error level -------------------------+-------------------------------------------------- Reporter: knarf | Owner: knarf Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently, Cactus allows to set a negative error level through the command line option. This leads to CCTK_WARN(0,"") not necessarily aborting. While this is not wrong by itself, a lot of code assumes an abort at that point. I propose to change CCTKi_SetErrorLevel() to only accept non-negative error levels and to change the command-parsing code to give an error message for that case as well. Patch is attached. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1187> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1190: The default for WARN should be 'yes' in simfactory option lists
by Einstein Toolkit 30 Nov '12

30 Nov '12

#1190: The default for WARN should be 'yes' in simfactory option lists -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- I propose to change the default for WARN in simfactory option lists (for generic machines, especially osx*.cfg and sl6.cfg) to "yes". Most other option lists already follow that. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1190> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1189: Make data parameter of expression evaluation functions const
by Einstein Toolkit 30 Nov '12

30 Nov '12

#1189: Make data parameter of expression evaluation functions const -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The data argument of Util_ExpressionEvaluate, and of the evaluator functions it uses, should be const. data is a pointer to user-supplied data used for evaluating the expression. It should not be modified by the evaluation. Note that this modifies the flesh API to the (undocumented) thorn-visible function Util_ExpressionEvaluate. The attached patch makes this modification as well as modifying the evaluators in the flesh. OK to apply? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1189> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1153: Do not describe outdated flesh MPI options in UsersGuide/Notes.txt
by Einstein Toolkit 29 Nov '12

29 Nov '12

#1153: Do not describe outdated flesh MPI options in UsersGuide/Notes.txt ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1153> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1003: Add optional support for CarpetEvolutionMask to GRHydro
by Einstein Toolkit 29 Nov '12

29 Nov '12

#1003: Add optional support for CarpetEvolutionMask to GRHydro -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- the attached patch adds access to CarpetEvolutionMask's evolution mask to GRHydro. CarpetEvolutionMaks tracks which points on each level contribute to the final answer, roughly speaking anything that would show up in a call to the interpolators. The functional change to GRHydro is trivial (just a parameter, a GF access and a cycle in the routine that checks for C2P failures). However getting the equivalent of CCTK_VarDataPtr to work in Fortran turned out to be ugly. Better solutions are very welcome. Desired features are: * easy to use * not error prone * allows to run GRHydro without CarpetEvolutionMask (this means inheriting won't work) * low memory footprint -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1003> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1188: GetComponents should output the total number of components to be downloaded
by Einstein Toolkit 29 Nov '12

29 Nov '12

#1188: GetComponents should output the total number of components to be downloaded ---------------------------+------------------------------------------------ Reporter: hinder | Owner: eric9 Type: enhancement | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ If GetComponents outputs the total number of components it is about to download, then Mohave will be able to give a better progress report. This would also be helpful for users as they can see how far through the process they are. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1188> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac