Trac December 2014

trac@lists.einsteintoolkit.org

1 participants
153 discussions

[Einstein Toolkit] #428: Forbid configuration names ending in -reconfig
by Einstein Toolkit 12 Jan '15

12 Jan '15

#428: Forbid configuration names ending in -reconfig ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- I accidentally created a Cactus configuration with a name like "sim- reconfig". This confuses Cactus, because the command "make sim-reconfig" can then mean either to build the "sim-reconfig" configuration, or to reconfigure the "sim" configuration. Cactus should catch and forbid these cases. This is probably most cleanly handled by using a script instead of a Makefile to interpret the user commands. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/428> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1610: Switch Cactus to 64 bits
by Einstein Toolkit 29 Dec '14

29 Dec '14

#1610: Switch Cactus to 64 bits -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Although pointers can have 64 bits, integers in Cactus are de facto (since we use "int" in many places) restricted to 32 bits. This limit is easily reached, and this has in fact been a problem on at least two occasions. One issue comes from Carpet's numbering of grid points. With 25 refinement levels, the coarse grid can be at most 127^3, and this limit was reached in production simulations years ago. Another issue comes from large 1D arrays. It is easily possible to have a 1D array with 10M (10^7) elements that is replicated across processes (distrib=const). In this case, one can use at most 200 MPI processes. We should devise a plan to switch Cactus to 64 bits. One option would be to replace most "int" by "CCTK_INT", so that those affected can switch these to 64 bits. I want to note that using 64-bit loop counters is often slightly faster than using 32-bit loop counters (on 64-bit architectures), since the 32->64 bit conversion for array indexing can be omitted. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1610> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1723: Output "increasing logging level" only on one process
by Einstein Toolkit 20 Dec '14

20 Dec '14

#1723: Output "increasing logging level" only on one process ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- When running on 40,000 processes, then the message "INFO (Cactus): Increasing logging level from 0 to 3" is output 40,000 times. This is just crazy. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1723> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1722: hwloc could warn the user if a process spans more than one NUMA node
by Einstein Toolkit 15 Dec '14

15 Dec '14

#1722: hwloc could warn the user if a process spans more than one NUMA node -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- If running on a NUMA architecture, performance could be very bad if a process allocates memory from one NUMA node, and also has threads running on cores of another NUMA node, as they will attempt to access the memory from the first node, which will be slow. It is probably better in that situation if there is one process per NUMA node, so that each process allocates memory it has fast access to. hwloc could detect whether the threads in a process are all on the same NUMA node or not, and output a warning (or error?) if there are threads running on more than one NUMA node in the same process. See also #1446 and #1528. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1722> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1565: change default of IOUtil::out_save_parameters to true
by Einstein Toolkit 15 Dec '14

15 Dec '14

#1565: change default of IOUtil::out_save_parameters to true -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- it would be useful of HDF5 files contained the full set of parameter values. This can be used by postprocessing scripts to find out eg about the symmetry conditions or some of the grid structure parameters as well as atmosphere settings. IOUtil::out_save_parameters controls whether the full set of parameters or only those that have been steered are written to file (for regular output, checkpoints always write all parameters). I would like to change the default so that all parameters are always written. If feasible I would even want to write all parameter changes to file (either as full parameter dumps for each output or as a full dump when the simulation starts then deltas afterwards). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1565> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 19

[Einstein Toolkit] #1721: Simfactory's test mechanism should use softlinks instead of rsync
by Einstein Toolkit 10 Dec '14

10 Dec '14

#1721: Simfactory's test mechanism should use softlinks instead of rsync -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- Simfactory's test mechanism copies all test cases from the source tree into the simulation directory. This takes a long time and a lot of space. This should rarely be necessary, since these test usually run soon after being submitted, so that there is little chance of the source tree becoming outdated. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1721> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1693: NoExcision internal compiler error
by Einstein Toolkit 10 Dec '14

10 Dec '14

#1693: NoExcision internal compiler error -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- When compiling the NoExcision thorn on Hydra at the RZG with ifort (IFORT) 15.0.0 20140723, I get the following error: {{{ /hydra/u/ihinder/Cactus/EinsteinToolkitGit/arrangements/EinsteinInitialData/NoExcision/src/cg.F90(373): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'. write (res_message, '(16(a3,es9.3))' ) (' | ', infnormresid(i), i=1, 16 ) ----------------------------------^ /hydra/u/ihinder/Cactus/EinsteinToolkitGit/configs/sim/build/NoExcision/cg.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. compilation aborted for /hydra/u/ihinder/Cactus/EinsteinToolkitGit/configs/sim/build/NoExcision/cg.f90 (code 1) }}} I will just disable this thorn for this machine for the moment, but the problem might also arise with other machines which use this compiler version. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1693> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1720: Provide a mechanism for determining why a Cactus simulation stopped running
by Einstein Toolkit 10 Dec '14

10 Dec '14

#1720: Provide a mechanism for determining why a Cactus simulation stopped running -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- I would like to know programatically why a given Cactus simulation has terminated. Was it due to TerminationTrigger running out of walltime, in which case the simulation is not complete? Or was it due to reaching cctk_final_time, in which case it is. Alternatively, if termination is from CCTK_Error, it would be good to get the error message in a file which is easy to parse, so that it can be displayed in tables of simulation statuses. Probably we want to write a termination file, as suggested in #1690, but we would need to define the format for the content. We should brainstorm on what other things we might want in this file. Does Cactus already "know" the reason for a termination, or do we need to extend the flesh for this? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1720> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1667: ExternalLibraries/MPI should report error messages
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1667: ExternalLibraries/MPI should report error messages --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: MPI | --------------------+------------------------------------------------------- I am trying to compile the ET on Datura, and MPI configuration is failing. The error message is: {{{ Running configuration script for thorn MPI: Found mpi compiler wrapper at /cluster/openmpi/SL6/1.7.2/intel14/bin/mpic++! MPI could not be configured. CST error 1: -> Configuration script for thorn MPI returned exit code 5 (no error message) Finished running configuration script for thorn MPI. }}} The configuration script should report any errors to the user. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1667> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 23

[Einstein Toolkit] #1628: Enable padding by default
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1628: Enable padding by default -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Enable padded allocation in Carpet by default. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1628> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

← Newer
1
...
9
10
11
12
13
14
15
16
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2014