Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1655: Cannot compile on Mac OS
by Einstein Toolkit 23 Sep '14

23 Sep '14

#1655: Cannot compile on Mac OS ----------------------+----------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: critical | Milestone: ET_2014_11 Component: Cactus | Version: development version Keywords: MPI | ----------------------+----------------------------------------------------- I tried to compile the ET on Mac OS using a fresh checkout from yesterday, and got linker errors. {{{ Undefined symbols for architecture x86_64: "_MPI_Abort", referenced from: _CactusDefaultAbort in libthorn_Cactus.a(CactusDefaultComm.c.o) MPI::Comm::Abort(int) in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Comm::Abort(int) in libthorn_Carpet.a(helpers.cc.o) MPI::Comm::Abort(int) in libthorn_CarpetEvolutionMask.a(evolution_mask.cc.o) MPI::Comm::Abort(int) in libthorn_CarpetIOASCII.a(ioascii.cc.o) MPI::Comm::Abort(int) in libthorn_CarpetIOBasic.a(iobasic.cc.o) MPI::Comm::Abort(int) in libthorn_CarpetIOHDF5.a(Input.cc.o) }}} This used to work before the recent rewrite of the MPI configure script. I am using the simfactory optionlist osx-mountain-lion-macports-gcc.cfg and OpenMPI from MacPorts. The auto-detection logic in the MPI thorn won't work, as MacPorts uses nonstandard names for the compilation wrappers (mpicc-openmpi-mp mpicxx-openmpi-mp mpiexec-openmpi-mp mpif77-openmpi-mp mpif90-openmpi-mp). However, the optionlist specifies the library locations explicitly, and for some reason this is not working: MPI_DIR = NO_BUILD MPI_INC_DIRS = /opt/local/include/openmpi-mp MPI_LIB_DIRS = /opt/local/lib/openmpi-mp While it would be good for the script to be updated to find the configuration scripts that OpenMPI in MacPorts provides, we should also fix whatever is stopping the explicit settings from working. It should always be possible to configure using the explicit settings; this is more important than having the auto-detection working. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1655> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1652: thorn MPI parses library names wrong if they contain dash
by Einstein Toolkit 18 Sep '14

18 Sep '14

#1652: thorn MPI parses library names wrong if they contain dash --------------------+------------------------------------------------------- Reporter: knarf | Owner: sbrandt Type: defect | Status: new Priority: major | Milestone: ET_2014_11 Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- mpicc --showme returns on my system: {{{ gcc -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -pthread -L/usr/lib/openmpi/lib -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export- dynamic -lnsl -lutil -lm -ldl }}} which MPI parses to be {{{ MPI_LIBS = mpi open open dl nsl util m dl }}} (note the missing part after the "open" in two libraries... -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1652> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1651: Problems with expansions in parameter files
by Einstein Toolkit 16 Sep '14

16 Sep '14

#1651: Problems with expansions in parameter files --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- If I have a parameter file containing {{{ CoordBase::ymin = -CoordBase::dy * 2 CoordBase::dy = 0.1 }}} it looks like Cactus silently ignores the CoordBase::dy in CoordBase::ymin, and tries to set ymin = 2, presumably because dy has not been set "yet". This raises two points: 1. The parser should raise a fatal error if it does not have a value for a parameter it is expanding; 2. The order of parameters listed in the parameter file should not matter. I think that parameter files should be declarative rather than imperative; i.e. you should think of them as a static mapping from parameter names to values rather than as a program which sets (and resets?) variables in the sequence written in the parameter file. A simple way to transform the current "set each parameter in sequence" implementation would be to sort the assignments so that parameters are set before they are used, and to raise a fatal error if a parameter is set twice. Would it be possible to implement this? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1651> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 19

[Einstein Toolkit] #1653: ExternalLibraries/MPI missing C++ library names
by Einstein Toolkit 15 Sep '14

15 Sep '14

#1653: ExternalLibraries/MPI missing C++ library names -----------------------------------+---------------------------------------- Reporter: barry.wardell | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The MPI thorn currently uses mpicc to automatically detect the list of libraries to link against. On my machine this causes '-lmpi' to be added to the list of libraries to link. This is wrong in cases where thorns use C++. In that case, '-lmpi_cxx' should also be included. I have tested this using a simple hello world MPI program (code [http://mpitutorial.com/mpi-hello-world/ here]). When I compile this with gcc and '-lmpi' it works fine, but if I compile with g++ I also need to include '-lmpi_cxx'. This is on Mac OS X 10.9 with OpenMPI installed by Homebrew, but I would imagine it could also affect other systems. A simple fix in my case is to replace mpicc with mpic++ in the configure.pl of the MPI thorn. In that case, both libraries are correctly included and I can compile Cactus without any problems. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1653> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1483: speed up reading metadata of HDF5 files in visit
by Einstein Toolkit 15 Sep '14

15 Sep '14

#1483: speed up reading metadata of HDF5 files in visit -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: CarpetHDF5 | -------------------------+-------------------------------------------------- The attached patch tries to extract as much information about a dataset from the dataset name as possible. Since accessing attributes is slow but the dataset name comes for free this speeds up opening HDF5 files in VisIt drastically (I had a factor of 6 when I measured it quite a while ago). This is certainly not the nicest way of parsing the string, one could think of sequentially looking for "name=value" constructs in the string and acting based on the name rather than just matching against all possible options. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1483> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1575: Declare cctkGH as "const cGH*"
by Einstein Toolkit 05 Sep '14

05 Sep '14

#1575: Declare cctkGH as "const cGH*" -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- cctkGH is declared as "const cGH*" in several places, but DECLARE_CCTK_ARGUMENTS still declares it only as "cGH*". This should be changed. I checked, and some thorns need updating to deal with this. I propose to make this change after the release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1575> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1633: backport MoL revision 225
by Einstein Toolkit 26 Aug '14

26 Aug '14

#1633: backport MoL revision 225 --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: MoL backport | --------------------------+------------------------------------------------- Before MoL did not initialize the RHS grid functions of the slow evolved variables to zero (but GRHydro did explicitly so this never showed up). Revision 225 adds the initialization. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1633> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #499: Prolongation fails with vectorisation enabled
by Einstein Toolkit 25 Aug '14

25 Aug '14

#499: Prolongation fails with vectorisation enabled --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- The development version of Carpet uses vectorisation to speed-up prolongation. This fails with various errors, including corruption of the malloc heap. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/499> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 23

[Einstein Toolkit] #445: Make Carpet timers hierarchical
by Einstein Toolkit 25 Aug '14

25 Aug '14

#445: Make Carpet timers hierarchical -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- With the current flat structure of timers in Carpet, it is difficult to identify which timers are contained in which other timers, and hence to avoid double-counting when adding up the times. This series of patches modifies the timer infrastructure in Carpet to generate a tree of timers where the hierarchy reflects the call-graph of the program. This makes it much easier to interpret the timer output than with the previous flat structure, where it was not possible to see which timers "contained" which others. More implementation details are given at the top of TimerNode.hh. Note that the Timer source and header files have been renamed as CactusTimer and a new Timer file and object has been created. This is because the Timer object now only provides a wrapper around the Cactus timer mechanism which was contained in the old Timer object. New parameters output_initialise_timer_tree and output_timer_tree_every control output of a new "timer tree diagram" to standard output for the Initialise and Evolve timer trees respectively. These diagrams indicate: 1. the value of each timer; 2. the percentage of the given tree taken by each timer; 3. which timers are contained in which other timers; 4. any untimed code for any timer which takes more than 1% of the tree time. Making the timers hierarchical means that the ad-hoc methods used before to identify the hierarchy (such as naming the timer Evolve::Sync, for example, to indicate that the Sync timer was a child of the Evolve timer) are no longer necessary and have been removed. Additionally, the construction of timers in a "dynamic" manner is now handled automatically for all timers, so special-case code is no longer needed and has been removed. Additionally some previously-untimed parts of the code are now timed, and timer names have been made more consistent in some places. There is code in the patches to output the entire timer tree as an XML file, but it is not enabled. Ideally the timer tree printed to standard output would contain reductions across processes, but at the moment it contains only the timer from the current process. The attached "tree-example.txt" file shows an example of the timer tree that is printed for a simulation using the qc0-mclachlan parameter file from the Einstein Toolkit. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/445> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #1618: Compile with adaptive MPI (based on Charm++)
by Einstein Toolkit 18 Aug '14

18 Aug '14

#1618: Compile with adaptive MPI (based on Charm++) ------------------------------+--------------------------------------------- Reporter: jtao@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | ------------------------------+--------------------------------------------- Gengbin Zheng, one of the leading developer of the Charm++ and I managed to get Cactus compile against the AMPI (http://charm.cs.illinois.edu/research/ampi). The patch against Revsion 5120 is attached. The major changes are in the flesh to deal with global variables. We started with PUGH to get started and changes in Carpet could be done later on. NR applications might not benefit from this work though this effort could make Cactus appealing to many other applications as a computational framework. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1618> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac