#1419: Cactus should produce no errors in Valgrind
-------------------------+--------------------------------------------------
Reporter: sbrandt | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Cactus_4.3.0
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Valgrind is a useful tool for identifying a large number of coding
problems. Currently, running Cactus under valgrind produces a large number
of spurious errors due to the implementation of the string library.
Attempts to use the valgrind suppression mechanism to eliminate them have
proven difficult.
However, these errors all go away if we simply replace all calls to
strdup() with calls to util_Strdup(), a function which is already part of
Cactus. Making this replacement shouldn't have any negative impacts, and
it would make valgrind more usable.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1419>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#706: External Library Support
-------------------------+--------------------------------------------------
Reporter: sbrandt | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Cactus_4.1.0
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
We should remove support for all external library support that's wired
into the flesh (except maybe MPI) in favor of the newer more generic
mechanism.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/706>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#641: Parameter files and thornlists could be tested as part of the release
process
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: ET_2012_05
Component: Other | Version:
Keywords: |
-------------------------+--------------------------------------------------
There are a number of parameter files and thornlists included as examples
with thorns in the ET, and in Cactus. Would it be feasible to have these
tested as part of the release process? For example, they should run
without crashing or missing thorns, should not trigger NaNs etc, and we
should minimise any warnings that are emitted. It would be nice to
automate this, though it probably requires a cluster, so would be distinct
from the usual test suite procedure, due to requiring more memory than
tests.
Something to think about for the next release.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/641>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1762: thorn lists in utils refer to old svn repositories
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone: ET_2015_05
Component: Other | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
The thornlists in https://bitbucket.org/cactuscode/utilities.git refer to
the old Subversion repositories. This should be fixed before the next
release.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1762>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1839: McLachlan no longer accepts ML_BSSN::UseSpatialBetaDriver = "yes"
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: McLachlan |
-----------------------------------+----------------------------------------
McLachlan (I suspect as part of being re-written) no longer accepts
boolean arguments for ML_BSSN::UseSpatialBetaDriver and instead declares
the parameter as an int. This seems nonsensical to me since BOOLEANs
already appear as INT to the code.
This looks like a regression to me.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1839>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#697: Repository and thorn names cannot be different
---------------------------+------------------------------------------------
Reporter: eschnett | Owner: eric9
Type: defect | Status: new
Priority: critical | Milestone:
Component: GetComponents | Version:
Keywords: |
---------------------------+------------------------------------------------
I am accessing some thorns stored in git repositories at bitbucket.org,
which insists that all repository names are all lower case. I don't know
how to specify this in GetComponents. When I say
!TARGET = $ARR
!TYPE = git
!URL = git@bitbucket.org:user/thorn.git
!AUTH_URL = git@bitbucket.org:user/thorn.git
!CHECKOUT =
Arrangement/Thorn
then GetComponents does not create a symbolic link from Thorn to
../../repos/thorn, but to ../../repos/thorn/Arrangement/Thorn instead. How
do I avoid this?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/697>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1834: Thorn CT_Analytic does not build on Shelob
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
The file CT_Analytic_Exact_Calc.cc takes more than 30 minutes to build on
Shelob, and the build process is thus aborted by the operating system:
{{{
COMPILING arrangements/CTThorns/CT_Analytic/src/CT_Analytic_Exact_Calc.cc
Message from root@shelob1 on <no tty> at 17:25 ...
{string1}
EOF
icpc: error #10106: Fatal error in
/usr/local/compilers/Intel/composer_xe_2013.5.192/bin/intel64/mcpcom,
terminated by kill signal
compilation aborted for
/project/eschnett/shelob/Cvanilla/configs/sim/build/CT_Analytic/CT_Analytic_Exact_Calc.cc
(code 1)
}}}
I've looked at the source code. It seems Kranc-generated, with expressions
spanning many lines and many calls to pow. Maybe a small change to the
Kranc script choosing different options (e.g. enabling CSE, or replacing
calls to pow by explicit multiplication) could remedy this.
At the moment I will disable this thorn on Shelob.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1834>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit