#632: Changegroup hook failed when pushing to Carpet repository
--------------------+-------------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: Carpet | Version:
Keywords: |
--------------------+-------------------------------------------------------
When I push to the Carpet repository, I get the following message:
{{{
remote: error: changegroup.cia hook failed: http://cia.vc returned an
error: queued.
}}}
The push succeeds. What is the cause of this error?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/632>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#412: Split Appendices
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
Currently, the appendices of the users' guide are repeated into the
reference manual. This is somewhat confusing, and causes problems because
the appendices cannot easily reference other sections (e.g. "see page 15"
doesn't make sense since one doesn't know in which document this will be
read). I suggest to split the appendices and have some of them in the
users' guide while moving others into the reference manual, so that each
appendix is included in only one document
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/412>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#704: Carpet complains about lack of mpi after ExternalLibraries/OpenMPI is built
---------------------+------------------------------------------------------
Reporter: bmundim | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
---------------------+------------------------------------------------------
I was able to compile ExternalLibraries/OpenMPI successfully, but the
Cactus
compilation stops afterwards with the message:
/home/bruno/tmp/einstein_dev_maxwell/Cactus/arrangements/Carpet/CarpetLib/src/make.configuration.defn:5:
*** Configuration error: The Carpet thorns require MPI. Please configure
with MPI, or remove the Carpet thorns from the ThornList.. Stop.
make: *** [einstein] Error 2
I indicated in my configuration file the following options:
OPENMPI_DIR = BUILD
OPENMPI_INSTALL_DIR = /home/bruno/local/gcc4.6.1/openmpi-1.5.4
I have then tried to indicate in my config file these extra options
after the library was built (and the rest of Cactus compilation stopped):
OPENMPI_DIR = /home/bruno/local/gcc4.6.1/openmpi-1.5.4
OPENMPI_INC_DIRS = /home/bruno/local/gcc4.6.1/openmpi-1.5.4/include
OPENMPI_LIB_DIRS = /home/bruno/local/gcc4.6.1/openmpi-1.5.4/lib
The config-info file does reflect these choices afterwards, and apparently
the flag indicating the presence of mpi library, HAVE_MPI, was set
correctly
at ~/Cactus/configs/einstein/bindings/Configuration/Capabilities:
grep -i have_mpi *
cctki_MPI.h:#define HAVE_MPI 1
make.MPI.defn:HAVE_MPI = 1
however since I didn't use the old mechanism to tell Cactus about MPI, the
~/Cactus/configs/einstein/config-data/make.extra.defn doesn't have
anything
indicating the presence of mpi library there.
It seems to me a compilation order issue. Somehow HAVE_MPI definition is
coming
after Carpet compilation, triggering this error then.
Does anyone have any idea where I should look at in order to fix this
problem?
Thanks,
Bruno.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/704>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#918: Usage of appendix in both UsersGuide and ReferenceManual
-------------------------+--------------------------------------------------
Reporter: knarf | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: ET_2012_11
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
The usage of the appendix of the UsersGuide inside the ReferenceManual led
to a lot of internal references being commented out. This probably
happened when UsersGuide and ReferenceManual had been divided, but it
means that currently a lot of useful information is missing. In #885 there
is agreement that the best solution would be to have the appendix included
only by one of the two documents, and to restore references as much as
possible.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/918>
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
#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
#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
#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