Trac

trac@lists.einsteintoolkit.org

8708 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] #1107: New thorn ML_WaveToy_Test
by Einstein Toolkit 09 Oct '12

09 Oct '12

#1107: New thorn ML_WaveToy_Test -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I propose to add a new thorn ML_WaveToy_Test to the Einstein Toolkit. This thorn exists in the McLachlan arrangement and complements the auto- generated McLachlan/ML_WaveToy with test cases. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1107> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[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] #1054: Formaline can enter into an infinite loop if git-lock.pl cannot create its lock directory
by Einstein Toolkit 09 Oct '12

09 Oct '12

#1054: Formaline can enter into an infinite loop if git-lock.pl cannot create its lock directory -------------------+-------------------------------------------------------- Reporter: rhaas | Type: defect Status: new | Priority: minor Milestone: | Component: EinsteinToolkit thorn Version: | Keywords: Formaline -------------------+-------------------------------------------------------- if for some reason the source base directory returned by git-get- localdir.pl is not accessible (eg. since one has uses an invalid or empty (simfactory) defs.local.ini) then the loop in line 35 of git-lock.pl: {{{ 32 my $waittime = 0.01; 33 my $maxwaittime = 10; 34 print "Attempting to obtain $lockdir cwd = ".getcwd()." GIT_DIR=$git_dir\n"; 35 while (! (mkdir $lockdir)) { 36 # Wait some time 37 my $unit = $waittime==1 ? "second" : "seconds"; 38 print "Git repository is busy; waiting $waittime $unit...\n"; 39 system "sleep '$waittime'"; 40 # Back off exponentially 41 $waittime *= 2; 42 $waittime = 1 if $waittime>1 && $waittime<2; 43 $waittime = $maxwaittime if $waittime > $maxwaittime; 44 } }}} never quits and without SILENT=no the make system also does not output the "Git repository busy" messages it seems. Possible remedies would seem to either introduce a timeout after which Formaline gives up and does not push into the source code repository (with a loud warning at the end) or to ensure that the print statement's output appears on screen. It might also be useful to add an option to Formaline to not rely on simfactory. Right now without simfactory it will fail at some later point in the build process (since it cannot call simfactory/bin/sim whoami) or might use the wrong local source path (if simfactory is downloaded but not properly set up). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1054> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1108: Formaline should also work with globally installed simfactory
by Einstein Toolkit 08 Oct '12

08 Oct '12

#1108: Formaline should also work with globally installed simfactory --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2012_11 Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- Currently, Formaline doesn't find a globally installed simfactory. The build succeeds, but produces error messages close to the end like sh: 1: /home/knarf/Cactus/bin/sim: not found The attached patch tries, after not finding 'sim' in that location simply 'sim' - to be searched for in the users' search path. It also redirects stderr of the first (but not second) try to /dev/null to avoid these error messages. It doesn't do this for the second try to make sure the users sees 'something' which points towards Formaline not finding something. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1108> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #1113: test parameter file consistency before submission
by Einstein Toolkit 04 Oct '12

04 Oct '12

#1113: test parameter file consistency before submission -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- to avoid silly mistakes in parameter files it would be useful if simfactory had an option to run {{{ cactus_sim -S parfile.par }}} on a simulations parameter file (after all simfactory substitutions are done). This should be done on the head node where possible (ie. not on hopper/kraken/cray-machines-in-general). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1113> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1106: Possible issue in TmunuBase with support_old_CalcTmunu_mechanism=no
by Einstein Toolkit 25 Sep '12

25 Sep '12

#1106: Possible issue in TmunuBase with support_old_CalcTmunu_mechanism=no -----------------------------------------+---------------------------------- Reporter: wolfgang.kastaun@… | Type: defect Status: new | Priority: minor Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: -----------------------------------------+---------------------------------- I think the schedule of the AddToTmunu should be changed from SCHEDULE GROUP AddToTmunu IN SetTmunu AFTER TmunuBase_SetTmunu to SCHEDULE GROUP AddToTmunu IN SetTmunu AFTER (TmunuBase_SetTmunu TmunuBase_ZeroTmunu) since with support_old_CalcTmunu_mechanism=no, Tmunu is initialised by TmunuBase_ZeroTmunu and not by TmunuBase_SetTmunu. Otherwise, it could happen that thorns add to undefined value and afterwards Tmunu is set to zero. This did not happen to me yet, but probably only by luck. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1106> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1104: create "current-release" branch for all ET components
by Einstein Toolkit 22 Sep '12

22 Sep '12

#1104: create "current-release" branch for all ET components -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- right now with each release we have to manually change all references from eg. 2012_05 to 2012_11 and are likely to miss one somewhere. It might be convenient to have a (symbolic link like) branch "current-release" (or so) that always points to the last stable release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1104> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1101: Test system output format should be extensible and easy to parse programmatically
by Einstein Toolkit 19 Sep '12

19 Sep '12

#1101: Test system output format should be extensible and easy to parse programmatically -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The Cactus test system currently outputs a human-readable results file. It is necessary to write a simple parser for this file (e.g. in Perl or Awk) in each application that needs to understand the results. Because the output format is not extensible, it is difficult to add test-specific details in a way which does not break exising ad-hoc parsers. I propose that the test system should output its results in XML format in addition to the current format. This format is extensible and parsers exist for most languages. I started to work on this a while ago, but have not had time to complete it. I attach a work-in-progress patch against revision 4874 of Cactus; I don't remember its status. It uses an imported Perl XML writer module (included in the patch) which seems to have a suitable licence. Since writing this, I have learned that test systems often write their output in a format compatible with the JUnit Java testing framework. As far as I can tell, this is not an officially defined format, but it is understood by many test systems (e.g. Jenkins, which I have been using recently). The code in the attached patch should be modified to output in this format. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1101> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac