Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1736: avoid using Fotran compiler to link Riemann1d utility
by Einstein Toolkit 15 Jan '15

15 Jan '15

#1736: avoid using Fotran compiler to link Riemann1d utility -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro | -----------------------------------+---------------------------------------- GRHydro contains a Riemann1d utility which contains a Fotran90 main program. Unfortunately some of the libraries we link against use C++ code and the F90 compiler fails to link the executable (missing vtables, constructors etc). Since the C++ compiler cannot link the main executable either (since it does not know how to start the main Fotran program), the attached patch adds a stub main() function that calls the previous F90 code as a subroutine. Most of the changes are to the build files to make a utility that needs preprocessed C code (for CCTK_FNAME) and contains multiple object files. Pull request is: https://bitbucket.org/einsteintoolkit/einsteinevolve /pull-request/5/grhydro-add-c-main-function-for-riemann1d/diff though given that this is a single commit I'd much rather have it be applied than to get a merge for a single commit. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1736> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1735: support FFTW3_LIBS FFTW3_INC_DIRS FFTW3_LIB_DIRS in FFTW3 ExternalLibrary
by Einstein Toolkit 14 Jan '15

14 Jan '15

#1735: support FFTW3_LIBS FFTW3_INC_DIRS FFTW3_LIB_DIRS in FFTW3 ExternalLibrary -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: FFTW3 | -----------------------------------+---------------------------------------- Right now FFTW3 claims to support FFTW3_LIBS (in configuration.ccl) but ignores the user provided value and always uses fftw3, it does not allow FFTW3_INC_DIRS or LLTW3_LIB_DIRS to be set at all. The attached patch changes this such that if those variables are specified in the option list, they override whatever detect.sh may want to use. This can be used to make use of the fftw implementation inside of MKL which stores its include files inside $MKL_ROOT/include/fftw and which should be used by sepcifying jsut {{{-mkl}} to the compiler rather than an actual library file. This is a bug since FFTW3_LIBS is documented but does not behave as documented. It is major since this should be fixed before the next release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1735> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1734: New Carpet thorns CarpetTest, TestBBoxSet2, TestTimers2
by Einstein Toolkit 13 Jan '15

13 Jan '15

#1734: New Carpet thorns CarpetTest, TestBBoxSet2, TestTimers2 -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- I suggest to add the three existing thorns CarpetTest, TestBBoxSet2, TestTimers2 to the Einstein Toolkit. They contain tests for Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1734> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1724: Don't require configuration name in 'make CONFIG' if only one configuration is present
by Einstein Toolkit 12 Jan '15

12 Jan '15

#1724: Don't require configuration name in 'make CONFIG' if only one configuration is present -------------------------+-------------------------------------------------- Reporter: knarf | Owner: knarf Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- For example 'make' after this pull request works if only one configuration is present. Otherwise a message would be output to tell the user to use 'make sim' (for example) - which is kind of pointless because at that point make "knew" already what was meant. It could, and should, just do it. https://bitbucket.org/cactuscode/cactus/pull-request/6/dont-require- configuration-name-when-only/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1724> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[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] #1732: hw fails to link with cuda
by Einstein Toolkit 06 Jan '15

06 Jan '15

#1732: hw fails to link with cuda --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- I get link errors like this: {{{ /home/knarf/psamr/configs/sim/scratch/external/hwloc/lib/libhwloc.a (topology-cuda.o): In function `hwloc_cuda_backend_notify_new_object': /home/knarf/psamr/configs/sim/scratch/build/hwloc/hwloc-1.7.2/src /topology-cuda.c:122: undefined reference to `cudaGetDeviceProperties' /home/knarf/psamr/configs/sim/scratch/external/hwloc/lib/libhwloc.a (topology-cuda.o): In function `hwloc_cuda_query_devices': /home/knarf/psamr/configs/sim/scratch/build/hwloc/hwloc-1.7.2/src /topology-cuda.c:38: undefined reference to `cudaGetDeviceCount' /home/knarf/psamr/configs/sim/scratch/external/hwloc/lib/libhwloc.a (topology-cuda.o): In function `hwloc_cudart_get_device_pci_ids': /home/knarf/psamr/configs/sim/scratch/build/hwloc/hwloc-1.7.2/include/hwloc/cudart.h:49: undefined reference to `cudaGetDeviceProperties' collect2: error: ld returned 1 exit status }}} hwloc is built (system version present, but deemed too old). The configuration is using the standard debian option list (on spine). Everything is dev-version, clean checkout. It seems to me that hwloc picks up a cuda dependency (present on system), but the linker isn't told about it (no cuda present in Cactus config). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1732> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1731: NaN in Dissipation/test_ah.par test case
by Einstein Toolkit 04 Jan '15

04 Jan '15

#1731: NaN in Dissipation/test_ah.par test case ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | ----------------------+----------------------------------------------------- I see nans returned from the elliptic solver in the test case Dissipation/test_ah.par when I switch off optimization and enable debug information. Things are fine with optimization. I do not know where exactly the nans are generated; the input to the solver looks fine, the output does not. This is on OS X, with gcc 4.9.2. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1731> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac