Trac September 2013

trac@lists.einsteintoolkit.org

1 participants
141 discussions

[Einstein Toolkit] #1225: GRHydro_UpdateMask takes too long to compile
by Einstein Toolkit 24 Nov '13

24 Nov '13

#1225: GRHydro_UpdateMask takes too long to compile -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- GRHydro_UpdateMask takes more than an hour to compile. This is with Intel Version 12.1.1.256 Build 20111011 on a modern workstation Intel(R) Xeon(R) CPU X5675 @ 3.07GHz: 11110 eschnett 32 12 251m 206m 14m R 100 0.9 68:29.24 fortcom Could we simplify the source code, e.g. moving the pointer assignments and the actual loops into different files? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1225> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1416: Use Carpet memory statistics in SystemStatistics
by Einstein Toolkit 08 Nov '13

08 Nov '13

#1416: Use Carpet memory statistics in SystemStatistics -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Call Driver_TotalMemoryUsed from SystemStatistics, so that this information can be output together with the malloc statistics obtained from the operating system. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1416> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #392: Strange message "already on master"
by Einstein Toolkit 07 Nov '13

07 Nov '13

#392: Strange message "already on master" ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ GetComponents outputs "already on master" for every git repository. This message should not appear. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/392> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1009: MPI is not automatically detected on Mac OS
by Einstein Toolkit 05 Nov '13

05 Nov '13

#1009: MPI is not automatically detected on Mac OS -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- There is logic in ExternalLibraries/MPI/configure.sh to automatically detect the location of MPI. This code looks for $X/lib/libmpi.a and $X/include/mpi.h for various values of X. This is not a robust way to locate MPI because libmpi.a is not the correct filename on Mac OS. We could make a special case for Mac OS and use ".dylib" instead of ".a", or we could remove the library file from the test, and rely on the header file alone. I prefer the latter. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1009> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1446: use hwloc to choose ideal number of threads
by Einstein Toolkit 30 Oct '13

30 Oct '13

#1446: use hwloc to choose ideal number of threads -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently if OMP_NUM_THREADS is not set Cactus ends up using the "default" number of threads, which usually is as many as there are cores. This is however not always ideal, eg if one uses 2 MPI processes per machine or when using SMT or when running on a magny cours CPU which has 1/2 of a FPU unit per SMT unit. Instead it might be useful to have the driver consult with hwloc to choose a more ideal number of threads. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1446> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1387: example par files for Z4 don't work
by Einstein Toolkit 29 Oct '13

29 Oct '13

#1387: example par files for Z4 don't work -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2013_11 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The parameter file examples in repos/McLachlan/par/CCZ4 don't work (they activate ML_BSSN and not ML_CCZ4). It would be good to update these, or maybe have a qc0 example using Z4 and remove these old files. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1387> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1395: GetComponents --parallel does not work
by Einstein Toolkit 29 Oct '13

29 Oct '13

#1395: GetComponents --parallel does not work ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: blocker | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ I receive svn errors when I use {{{ /GetComponents --parallel https://svn.einsteintoolkit.org/manifest/branches/ET_2013_05/einsteintoolki… }}} for the initial checkout, as described in the tutorial. Things work without the --parallel option. This is a blocker since it affects the tutorial. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1395> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 45

[Einstein Toolkit] #1411: Align memory allocation in PUGH
by Einstein Toolkit 28 Oct '13

28 Oct '13

#1411: Align memory allocation in PUGH --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: PUGH | --------------------+------------------------------------------------------- the attached patch optionally uses thorn vectors to query the vector size and aligns memory allocation to this size. This is needed for aligned reads and writes generated eg by Kranc generated thorns when Vectors is present. Without the thorn present at build time, no alignment is performed. Failure to align results in segmentation faults at runtime. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1411> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #626: Recovery fails in AHFinderDirect RecoverML with out-of-bounds assertion in CarpetLib
by Einstein Toolkit 28 Oct '13

28 Oct '13

#626: Recovery fails in AHFinderDirect RecoverML with out-of-bounds assertion in CarpetLib --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2011_10 Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- when trying to recover in AHFinderDirect's RecoverML test (parfiles attached) I get: {{{ cactus_et: /home/rhaas/ET_2011_10/arrangements/Carpet/CarpetLib/src/th.hh:79: double th::get_time(int, int, int) const: Assertion `tl>=0 and tl<timelevels' failed. }}} After some debuggin I traced this down to the metric which in CarpetIOHDF5/src/Input.cc:762 is reported (by gf->timelevels (ml, rl)) to have three timelevels. However the timelevels member of gf->t (a th) gives the number of timelevels as two {{{ gf->t.timelevels $28 = 2 }}} Since timelevels is new in Carpet/Hg my suspicion would be that it is not properly updated when gf->set_timelevels is called (the comments in th.hh seem to indicated that it is assumed to be const which seems odd given that ggf::set_timelevels exists). I don't understand enough of Carpet to fix or further debug this. Marking its as major and release relevant in case it is actually a Carpet bug. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/626> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 21

[Einstein Toolkit] #1364: be mor careful extracting $MAKE in RunTestSuite
by Einstein Toolkit 28 Oct '13

28 Oct '13

#1364: be mor careful extracting $MAKE in RunTestSuite ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: critical | Milestone: ET_2013_05 Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- currently sim --testsuite fails on kraken since the extracted $MAKE command is incorrect since it splits at the second "=" in the make definition: {{{ make = env LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/opt/gcc/4.5.1/snos/lib64:/opt/gcc/mpc/0.8.1/lib" make -j2 }}} the attached patch rectifies this. Tested on kraken and lonestar. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1364> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 17

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2013