Trac July 2012

trac@lists.einsteintoolkit.org

1 participants
161 discussions

[Einstein Toolkit] #928: openmp parallelization within Exact broken
by Einstein Toolkit 13 Oct '12

13 Oct '12

#928: openmp parallelization within Exact broken --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2012_05 Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- Exact uses openmp for the loop over grid points. However, quite a few metrics (which get called pointwise) use static (saved) data. In all cases I have looked at this is only used to initialize some local variables with values from Cactus parameters - and only as long as a 'global' variable 'firstcall' is true. This variable is set to 'false' after the other variables had been initialized, which should be ok even when using multiple threads. However, the compiler can switch the two (and does according to the assembly output), leading to another thread 'seeing' first_call being false, but the global variables not being initialized yet. The right solution would be to remove these variables. They are not really necessary, because the Cactus parameters could directly be used. However, that patch would be quite large. A simple and quick workaround would be to remove the openmp parallelization for that loop, at least for the upcoming release. We have to do one of the two - or something else in case someone comes up with another idea. This is currently breaking several testsuites (sometimes). In case you want to see an example: look at de_Sitter.F77 and firstcall and arad. Thoughts? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/928> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 19

[Einstein Toolkit] #902: carpetioascii with compact_format writes wrong set of columns
by Einstein Toolkit 11 Oct '12

11 Oct '12

#902: carpetioascii with compact_format writes wrong set of columns ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: carpetioascii | ---------------------------+------------------------------------------------ For 0d output (in my case systemstatistics data) I get: {{{ # SYSTEMSTATISTICS::PROCESS_MEMORY_MB (systemstatistics::process_memory_mb) # # column format: 1:it 2:ix 3:time 4:x 5:data # data columns: 5:maxrss_mb 6:majflt_mb 7:arena_mb 8:ordblks_mb 9:hblks_mb 10:hblkhd_mb 11:uordblks_mb 12:fordblks_mb 13:keepcost_mb 14:swap_used_mb 3840 0 5.76 4956 23 628 0 0 651 -1189 1818 17 0 4096 0 6.144 5100 23 726 0 0 651 -1188 1915 21 0 }}} Note that the headers claim 14 columns but counting them, there are only 13 columns. From the look of it the "x" column is absent (since 4956 makes sense for being MB of memory used and 5.76 is clearly the time) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/902> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #946: Undefined symbol ___emutls_get_address
by Einstein Toolkit 09 Oct '12

09 Oct '12

#946: Undefined symbol ___emutls_get_address ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- When I try to compile on Mac OS using the SimFactory optionlist macos- fink-gcc.cfg (https://svn.cct.lsu.edu/repos/numrel/simfactory2/trunk/mdb/optionlists /macos-fink-gcc.cfg), I get the following error at link time: {{{ ld: warning: alignment lost in merging tentative definition _tmunubaserest_ ld: warning: alignment lost in merging tentative definition _admmacrosrest_ ld: warning: alignment lost in merging tentative definition _staticconformalrest_ Undefined symbols: "___emutls_get_address", referenced from: __ZN4dist25collect_total_num_threadsEv.omp_fn.0 in libthorn_CarpetLib.a(dist.cc.o) dist::collect_total_num_threads() in libthorn_CarpetLib.a(dist.cc.o) Carpet::SetupGH(tFleshConfig*, int, _cGH*) in libthorn_Carpet.a(SetupGH.cc.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[1]: *** [/Users/ian/Cactus/Kerrness/exe/cactus_sim] Error 1 make: *** [sim] Error 2 }}} I don't know if the "alignment lost" warnings are related to the fatal error. This seems to be some issue related to OpenMP. The problem appeared fairly recently, as I have been able to compile older versions of the ET with no problem, and this option list has not been changed. I am reporting this against SimFactory because the problem does not happen with other option lists in the machine database, but I suspect that the issue arose due to a change in Carpet (maybe related to affinity?). From some Google searching, this symbol is part of GCC's thread-local storage emulation for Mac OS. Some people have had this problem when mixing object files compiled by different versions of GCC. I am using GCC 4.4.4 from Fink: {{{ > g++-4 --version g++-4 (GCC) 4.4.4 }}} This page, http://stackoverflow.com/questions/7885246/what-is-the-emutls- get-address-symbol, says {{{ Using thread local storage (e.g. OpenMP ThreadPrivate variables) on Darwin requires manually linking to TLS emutls, via either -lgcc_s.so.1 or -lgcc_eh }}} There is also a suggestion to upgrade the version of GCC, which I am trying now. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/946> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #720: check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active
by Einstein Toolkit 19 Sep '12

19 Sep '12

#720: check at runtime that all REQUIREd and OPTIONAL thorns and capabilities are active -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- This is an offshot of a discussion on the Cactus developers mailing list: http://cactuscode.org/pipermail/developers/2011-November/006258.html On 6 Jan 2012 12:54:13 -0500 eschnett said: > What is currently missing is the mechanism that checks that all thorns > providing required capabilities are activated. If they are not, code > in inactive thorns is called -- this is fine as long as no Cactus > infrastructure is used (parameters, scheduled routines, grid > functions, etc.). > > Yes, we should implement the respective checks; yes, we should > automatically activate thorns required for capabilities (and maybe > some others as well?); yes, we should then output this thorn list to > the screen (done anyway) and into a file. > > By the way, Cactus already determines which thorns need to be > activated automatically as a service to the user in the error message > that complains about missing thorns. The idea seems to be to document all thorns whose code is executed in the parameter file. Ian's original need might be served by an "OPTIONAL" statement in configuration.ccl (http://einsteintoolkit.org/documentation/UsersGuide/UsersGuidech12.html#x17…) and some #ifdefs, maybe. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/720> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #929: GRHydro_test_tov_ppm_ML fails intermittently
by Einstein Toolkit 19 Sep '12

19 Sep '12

#929: GRHydro_test_tov_ppm_ML fails intermittently -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- The test GRHydro_test_tov_ppm_ML sometimes fails on Datura. This seems to be nondeterministic. The most recent occurrence of this (http://git.barrywardell.net/EinsteinToolkitTestResults.git/blob/0fed62edfcc…) is due to differences in the constraints and vel[0]_norm1.xg very close to the tolerance. This does not happen every time. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/929> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #988: testsuite can't find MPI when CACTUS_CONFIGS_DIR is set
by Einstein Toolkit 19 Sep '12

19 Sep '12

#988: testsuite can't find MPI when CACTUS_CONFIGS_DIR is set ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: minor | Milestone: Cactus_4.1.0 Component: Cactus | Version: development version Keywords: | ---------------------+------------------------------------------------------ testsuite can't find MPI when CACTUS_CONFIGS_DIR is set, a patch correcting this problem is attached -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/988> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #762: support git-svn repositories
by Einstein Toolkit 17 Sep '12

17 Sep '12

#762: support git-svn repositories ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: eric9 Type: enhancement | Status: new Priority: optional | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ I have a number of svn repositories that are each wrapped within a git-svn checkout (to more easily handle local modifications). It would be nice to have GetComponents handle these for me in the same way it already handles svn and git repositories. With git-svn checkouts are {{{git svn clone URL DIR}}}, updates are {{{git svn rebase}}}, diff is {{{git diff remotes/git-svn}}} and local changes have to be stashed the way they are with git. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/762> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #832: ExternalLibraries/zlib gives bad error message if "patch" is not available
by Einstein Toolkit 16 Sep '12

16 Sep '12

#832: ExternalLibraries/zlib gives bad error message if "patch" is not available -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The PATCH variable is used in the zlib configuration script but there is no check that it has been set. It is also not declared in the configuration.ccl as being used. Should all environment variables used in the script be declared? PATCH is usually set by autoconf, unless it is unavailable, in which case it is not set. Replacing $PATCH with ${PATCH?} would be enough to give a sensible error message. I don't know if there are versions of bash that would not understand this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/832> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #895: PITTNullCode does not work with Devel AEILocalInterp
by Einstein Toolkit 13 Sep '12

13 Sep '12

#895: PITTNullCode does not work with Devel AEILocalInterp ---------------------------------+------------------------------------------ Reporter: yosef@… | Type: defect Status: new | Priority: major Milestone: | Component: EinsteinToolkit thorn Version: | Keywords: CCE complex interpolation ---------------------------------+------------------------------------------ The CCE testsuite fails in the development version of ET. The interpolation calls in NullNews fail with the error WARNING[L1,P0] (AEILocalInterp): CCTK_InterpLocalUniform(): input datatype 111 not supported! (0-origin) input #in=0 The interpolation call is for a variable of type CCTK_VARIABLE_COMPLEX. The call works with the Maxwell version of AEILocalInterp -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/895> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #745: the flesh allows two implemantion of the same interface to have different default values for restricted parameters
by Einstein Toolkit 05 Sep '12

05 Sep '12

#745: the flesh allows two implemantion of the same interface to have different default values for restricted parameters --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- since the flesh creates paramters for all compiled in (rather than activated) thorns initially, this affects the default value that a thorn sees. Thorns seem to be initialized (and thus their parameter structures being created) in alphabetical order, which means that the thorn alphabetically '''last''' (How, I have no idea, the parameter handling logic seems a bit of a mess) will determine the default parameter value. Attached is a parameter file to demonstrate this with Carpet and PUGH who both declare parameters periodic and periodic_[xyz] but differ in their defaults. To demonstrate, create an executable with only Carpet compiled in and run the parameter file. Then look at the paramters in the checkpoint it creates eg. {{{ h5dump -r -d /Parameters\ and\ Global\ Attributes/All\ Parameters output/checkpoint.chkpt.it_0.h5 | grep periodic }}} Do the same with an executable that contains both PUGH and Carpet. Notice that parameter values are now PUGH's defaults. This can actually cause a runs to abort when recovering from a checkpoint when one switches from an executable with PUGH compiled in to one that does not. (Beyond the fact that some thorn might actually use it's parameters rather than the Carpet/PUGH pair where happily Carpet ignores these parameters and PUGH who actually used them gets to set the default). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/745> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2012