#1109: LoopControl::printstats should default to "no"
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version:
Keywords: |
-------------------------+--------------------------------------------------
LoopControl::printstats should default to "no". The output is not
important enough to show to the user unless they ask for it.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1109>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1122: build problems on Ubuntu with gcc 4.6
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
--------------------+-------------------------------------------------------
Building ET trunk on a "Linux version 3.2.0-29-generic-pae
(buildd@roseapple) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) )
#46-Ubuntu SMP Fri Jul 27 17:25:43 UTC 2012" Ubuntu virtual machine
(32bit) I get:
{{{
COMPILING
/home/lovelace/trunk/Cactus/arrangements/Carpet/CarpetLib/src/backtrace.cc
In file included from
/home/lovelace/trunk/Cactus/arrangements/Carpet/CarpetLib/src/dist.hh:20:0,
from
/home/lovelace/trunk/Cactus/arrangements/Carpet/CarpetLib/src/backtrace.cc:405:
/home/lovelace/trunk/Cactus/arrangements/Carpet/CarpetLib/src/defs.hh: In
function ‘int myisinf(double)’:
/home/lovelace/trunk/Cactus/arrangements/Carpet/CarpetLib/src/defs.hh:234:18:
error: call of overloaded ‘isinf(const double&)’ is ambiguous
/home/lovelace/trunk/Cactus/arrangements/Carpet/CarpetLib/src/defs.hh:234:18:
note: candidates are:
/usr/include/i386-linux-gnu/bits/mathcalls.h:203:1: note: int
isinf(double)
/usr/include/c++/4.6/cmath:534:3: note: bool std::isinf(long double)
/usr/include/c++/4.6/cmath:530:3: note: bool std::isinf(double)
/usr/include/c++/4.6/cmath:526:3: note: bool std::isinf(float)
/home/lovelace/trunk/Cactus/arrangements/Carpet/CarpetLib/src/defs.hh: In
function ‘int myisnan(double)’:
/home/lovelace/trunk/Cactus/arrangements/Carpet/CarpetLib/src/defs.hh:249:18:
error: call of overloaded ‘isnan(const double&)’ is ambiguous
/home/lovelace/trunk/Cactus/arrangements/Carpet/CarpetLib/src/defs.hh:249:18:
note: candidates are:
/usr/include/i386-linux-gnu/bits/mathcalls.h:236:1: note: int
isnan(double)
/usr/include/c++/4.6/cmath:552:3: note: bool std::isnan(long double)
/usr/include/c++/4.6/cmath:548:3: note: bool std::isnan(double)
/usr/include/c++/4.6/cmath:544:3: note: bool std::isnan(float)
make[3]: *** [backtrace.cc.o] Error 1
make[2]: *** [make.checked] Error 2
make[1]: ***
[/home/lovelace/trunk/Cactus/configs/sim/lib/libthorn_CarpetLib.a] Error 2
make: *** [sim] Error 2
lovelace@ETUbuntu:~/trunk/Cactus$
}}}
This might be related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891
. The options list used was the simfactory ubuntu.cfg one.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1122>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#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
#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
#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
#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
#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
#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