#912: Use CACTUS_CONFIGS_DIR in Formaline
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Formaline assumes that configurations are stored in a "configs"
subdirectory of $CCTK_HOME. Use $CACTUS_CONFIGS_DIR instead.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/912>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1893: Compile error in Carpet when CCTK_REAL is single
--------------------------------+-------------------------------------------
Reporter: koppel@… | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: Other | Version: development version
Keywords: |
--------------------------------+-------------------------------------------
When Cactus is configured with REAL_PRECISION = 4 there is a compile error
in CarpetLib due to a hardcoded double type. The attached patch fixes the
problem.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1893>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1892: Compile error when _OPENMP not defined.
-----------------------+----------------------------------------------------
Reporter: anonymous | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: Other | Version: development version
Keywords: |
-----------------------+----------------------------------------------------
There is a compile error when _OPENMP is not defined. The following fixes
it:
{{{
diff --git a/CarpetLib/src/dist.hh b/CarpetLib/src/dist.hh
index acc646d..a5ba5be 100644
--- a/CarpetLib/src/dist.hh
+++ b/CarpetLib/src/dist.hh
@@ -18,6 +18,7 @@
#else
static inline int omp_get_max_threads() { return 1; }
static inline int omp_get_thread_num() { return 0; }
+static inline int omp_get_num_threads() { return 1; }
#endif
#include "defs.hh"
}}}
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1892>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1870: ET_2015_11_v0 of McLachlan does regenerate code for ca6fe74
"McLachlan_BSSN.m: Make evolveA steerable"
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: McLachlan backport |
-----------------------------------+----------------------------------------
the release branch claims to make ML_BSSN::evolveA steerable but fails to
actually do so in the generated code. Commit
0b38cba1f9ee9fce3f1ed2543295266efb86107e of McLachlan fixes this on
master.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1870>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1595: Is {{{*)}}} allowed as upper boundary for a parameter range?
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
----------------------+-----------------------------------------------------
I sometimes see these warnings when Cactus starts:
{{{
WARNING[L1,P0] (Cactus): Invalid end of real-valued parameter range; range
descriptor is "(0.0 : *)" (value is 1)
}}}
Presumably the warning depends on which thorns are active.
This warning looks as if the syntax {{{*)}}} was accepted by the CST when
parsing a param.ccl file, but was later not recognized by the flesh when
checking a parameter value against this range. (The flesh uses HUGE_VAL as
fallback, which happens to be correct in this case.)
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1595>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1891: Formaline: aborts if files are removed from repo
-----------------------------------+----------------------------------------
Reporter: knarf | Owner:
Type: defect | Status: new
Priority: critical | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
Formaline aborts if files are removed from a git repo, trying to 'git add'
that file, and failing because it is not present anymore.
See https://build.barrywardell.net/job/EinsteinToolkit/769/console
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1891>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1890: formaline capture simfactory information
--------------------------------------------+-------------------------------
Reporter: jonah.maxwell.miller@… | Owner: eschnett
Type: enhancement | Status: new
Priority: unset | Milestone:
Component: Other | Version: development version
Keywords: formaline |
--------------------------------------------+-------------------------------
It would be nice if Formaline captured the machine description used by
simfactory (i.e., properties.ini, optionlist, submitscript) for a
simulation. This information would be convenient for reproducing the exact
configuration on a machine later.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1890>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1872: test system does not detect extra lines in output files
-----------------------+----------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: critical | Milestone: ET_2016_11
Component: Cactus | Version: development version
Keywords: testsuite |
-----------------------+----------------------------------------------------
I accidentally removed some lines of output from the stored test suite
data in git hash
[https://bitbucket.org/eloisa/ctthorns/commits/79c5e0d32fb1e3d6b219d7b55211f…
79c5e0d32fb1e3d6b219d7b55211fa3c388f7268] of ctthorns in the files
{{{CT_MultiLevel/test/constraints_spherical/*_norm_eqn?.asc}}}. Yet the
test all passed. I have since restored the changed files.
This I would consider quite serious since extra output lines should always
cause the test to fail rather than being silently ignored.
I am marking this as critical since it potentially renders the test suites
useless when detecting changes. If we fell we can "document away" this
then, it can be downgraded to "major".
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1872>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1888: HDF5 output causing termination with std::out_of_range error
---------------------------+------------------------------------------------
Reporter: barry.wardell | Owner: eschnett
Type: defect | Status: new
Priority: unset | Milestone:
Component: Carpet | Version: development version
Keywords: |
---------------------------+------------------------------------------------
I am getting an std::out_of_range error when I try to run a simulation
with the latest development version of the Einstein Toolkit. Specifically,
the error I am getting is:
{{{
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check
}}}
The backtrace provides more detailed information:
{{{
Backtrace from rank 0 pid 3146:
1. CarpetLib::signal_handler(int)
[/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN9CarpetLib14signal_handlerEi+0x8e)
[0x12a24de]]
2. /lib64/libc.so.6(+0x32920) [0x2aaab2e53920]
3. /lib64/libc.so.6(gsignal+0x35) [0x2aaab2e53885]
4. /lib64/libc.so.6(abort+0x181) [0x2aaab2e54e61]
5. __gnu_cxx::__verbose_terminate_handler()
[/usr/lib64/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x11d)
[0x2aaab29698ad]]
6. /usr/lib64/libstdc++.so.6(+0x63986) [0x2aaab2967986]
7. /usr/lib64/libstdc++.so.6(+0x639b3) [0x2aaab29679b3]
8. /usr/lib64/libstdc++.so.6(+0x63bf3) [0x2aaab2967bf3]
9. std::__throw_out_of_range(char const*)
[/usr/lib64/libstdc++.so.6(_ZSt20__throw_out_of_rangePKc+0x5d)
[0x2aaab29b92cd]]
a. CarpetIOHDF5::IOHDF5<1>::WriteHDF5(_cGH const*, int&, int&,
std::vector<gdata*, std::allocator<gdata*> >, bbox<int, 3> const&, int,
vect<int, 3> const&, vect<int, 1> const&, int, int, int, int
, int, int, double, vect<double, 3> const&, vect<double, 3> const&)
[/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN12CarpetIOHDF56IOHDF5ILi1EE9WriteHDF5EPK4_cGHRiS
5_St6vectorIP5gdataSaIS8_EERK4bboxIiLi3EEiRK4vectIiLi3EERKSF_IiLi1EEiiiiiidRKSF_IdLi3EESO_+0x2516)
[0x123d526]]
b. CarpetIOHDF5::IOHDF5<1>::OutputDirection(_cGH const*, int, std::string,
std::string, vect<int, 1> const&, bool, bool)
[/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_si
m(_ZN12CarpetIOHDF56IOHDF5ILi1EE15OutputDirectionEPK4_cGHiSsSsRK4vectIiLi1EEbb+0xf28)
[0x1239378]]
c. CarpetIOHDF5::IOHDF5<1>::OutputVarAs(_cGH const*, char const*, char
const*)
[/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN12CarpetIOHDF56IOHDF5ILi1EE11OutputVa
rAsEPK4_cGHPKcS6_+0x4a4) [0x1237004]]
d. CarpetIOHDF5::IOHDF5<1>::TriggerOutput(_cGH const*, int)
[/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN12CarpetIOHDF56IOHDF5ILi1EE13TriggerOutputEPK4_cGHi+0x1b
3) [0x1236a23]]
e. CarpetIOHDF5::IOHDF5<1>::OutputGH(_cGH const*)
[/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN12CarpetIOHDF56IOHDF5ILi1EE8OutputGHEPK4_cGH+0x368)
[0x1236568]]
f. Carpet::OutputGH(_cGH const*)
[/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN6Carpet8OutputGHEPK4_cGH+0x6cb)
[0x1136d1b]]
10.
/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim()
[0x1132cf1]
11. Carpet::Initialise(tFleshConfig*)
[/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(_ZN6Carpet10InitialiseEP12tFleshConfig+0x767)
[0x1134b17]]
12.
/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim(main+0x99)
[0x3b2ed29]
13. /lib64/libc.so.6(__libc_start_main+0xe6) [0x2aaab2e3fc36]
14.
/ichec/work/ucd01/bwardell/EinsteinToolkit/bbh/SIMFACTORY/exe/cactus_sim()
[0xd3a609]
}}}
This suggests the problem is in CarpetIOHDF5, and indeed reverting Carpet
commit cf2e12631ed9b6e1eac95ae5f311fdbe5100db75 makes the problem go away.
The parameter file I am using is this one:
[https://bitbucket.org/simulationtools/simulationtoolstestdata/src/master/Si…
bbh.par].
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1888>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1887: Error Running
------------------------------------+---------------------------------------
Reporter: cabarbosad@… | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: ET_2015_05
Keywords: |
------------------------------------+---------------------------------------
I have a .par file "Simple example of Schwarzschild using ADM". I need to
simulate schwarzschild of a black hole but get the following error:
Activating thorn Cactus...Success -> active implementation Cactus
Activation requested for
--->MoL ADMBase ADMAnalysis ADMMacros ADMConstraints ADMCoupling TmunuBase
Boundary CartGrid3D CoordBase CoordGauge SymBase StaticConformal
IDanalyticBH IOBasic IOUtil IOASCII PUGH PUGHreduce PUGHslab Time
LocalReduce SpaceMask MPI hwloc zlib <---
Error: Thorn ADMConstraints not found
Activation failed - 1 errors in activation sequence
[1mWARNING level 0 from host CAMPC process 0
while executing schedule bin (none), routine (no thorn)::(no routine)
in thorn Cactus, file /home/campc/Cactus/src/main/SetParams.c:93:
->[0m CCTKi_SetParameter: Error at line 8 in parameter file
/root/simulations/schwarzschildADM/output-0000/schwarzschildADM.par while
activating thorns
mar may 10 16:45:25 COT 2016
Simfactory Done at date: 0
Attached files
Thanks!
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1887>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit