#392: Strange message "already on master"
---------------------------+------------------------------------------------
Reporter: eschnett | Owner: eric9
Type: defect | Status: new
Priority: minor | Milestone:
Component: GetComponents | Version:
Keywords: |
---------------------------+------------------------------------------------
GetComponents outputs "already on master" for every git repository. This
message should not appear.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/392>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1009: MPI is not automatically detected on Mac OS
-----------------------------------+----------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
There is logic in ExternalLibraries/MPI/configure.sh to automatically
detect the location of MPI. This code looks for $X/lib/libmpi.a and
$X/include/mpi.h for various values of X. This is not a robust way to
locate MPI because libmpi.a is not the correct filename on Mac OS. We
could make a special case for Mac OS and use ".dylib" instead of ".a", or
we could remove the library file from the test, and rely on the header
file alone. I prefer the latter.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1009>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#626: Recovery fails in AHFinderDirect RecoverML with out-of-bounds assertion in
CarpetLib
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone: ET_2011_10
Component: Carpet | Version:
Keywords: |
--------------------+-------------------------------------------------------
when trying to recover in AHFinderDirect's RecoverML test (parfiles
attached) I get:
{{{
cactus_et:
/home/rhaas/ET_2011_10/arrangements/Carpet/CarpetLib/src/th.hh:79: double
th::get_time(int, int, int) const: Assertion `tl>=0 and tl<timelevels'
failed.
}}}
After some debuggin I traced this down to the metric which in
CarpetIOHDF5/src/Input.cc:762 is reported (by gf->timelevels (ml, rl)) to
have three timelevels. However the timelevels member of gf->t (a th) gives
the number of timelevels as two
{{{
gf->t.timelevels
$28 = 2
}}}
Since timelevels is new in Carpet/Hg my suspicion would be that it is not
properly updated when gf->set_timelevels is called (the comments in th.hh
seem to indicated that it is assumed to be const which seems odd given
that ggf::set_timelevels exists).
I don't understand enough of Carpet to fix or further debug this. Marking
its as major and release relevant in case it is actually a Carpet bug.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/626>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1066: Implement IMEX integrators in MoL
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Dana Alic contributed an implementation of IMEX integrators for MoL.
I attach the implementation as a patch (based on r133 of MoL). The
implementation is well tested. The patch does not apply cleanly, and seems
to make some modifications to the schedule etc. as well that have since
been superseded by other changes to MoL.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1066>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#652: CACTUS_CONFIGS_DIR should be documented
-------------------------+--------------------------------------------------
Reporter: knarf | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
At the moment CACTUS_CONFIGS_DIR is only mentioned in doc/FAQ. It should
be documented in the regular documentation as well.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/652>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#963: Improve McLachlan accuracy
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
James van Meter provided me with an optimised version of McLachlan. He
states:
1. You are not taking full advantage of the chi=exp(-2phi) variable.
There are several terms you divide by chi or chi^2 in expressions with
overall factors exp(-4phi). I rewrote the BSSN equations to make these
cancellations before coding. So where you have an expression of the form
chi^2(A+B/chi^2), I have chi^2A+B. This gives a slight but noticeable
advantage in both accuracy and performance.
2. I added Hamiltonian-constraint-damping terms due to Duez et al. These
terms don't seem to be well-known but they are effective.
3. I added a Gamma-constraint-damping term due to Yo et al.
4. I enforce det(g)=1.
I have not tested this new version yet, but James suggests to include it
into the Einstein Toolkit.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/963>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#605: Simfactory does not find the right 'path' for symlinked cactus directories
------------------------+---------------------------------------------------
Reporter: knarf | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone: ET_2011_10
Component: SimFactory | Version: development version
Keywords: |
------------------------+---------------------------------------------------
Simfactory currently does not detect the 'right' path to a Cactus
sourcetree if this is from within a symlink, e.g. Cactus ->
/mnt/data/Cactus. This is because while `pwd` returns '/home/user/Cactus',
simfactory uses a wrapper to the C-library getcwd(), which dereferences
symlinks. Simfactory then gets '/mnt/data/Cactus' and tries to use this
path on remote machines when syncing - which of course does not work.
The attached patch fixes this by using os.environ.get("PWD") and, if this
is not defined, using os.getcwd() as workaround.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/605>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#117: Error while building multiple configurations
------------------------+---------------------------------------------------
Reporter: eschnett | Owner: mthomas
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
I wanted to build multiple configurations at once with the command
./simfactory/sim build sim-debug sim
sim-debug is a debug configuration, sim is optimised. SimFactory built
sim-debug, then aborted with the error:
optionlist is: /Users/eschnett/EinsteinToolkit-hg/configs/sim/OptionList
Error: pattern '^\s*DEBUG\s*=.*$' exists already
It assumes that SimFactory doesn't properly distinguish between the
different build options of the different configurations.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/117>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#874: Reduce warnings during an ET build
--------------------+-------------------------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Other | Version:
Keywords: |
--------------------+-------------------------------------------------------
A new user of the ET might be disconcerted to see warnings during
compilation such as:
{{{
/home/ianhin/Cactus/EinsteinToolkit/arrangements/Carpet/CarpetLib/src/bboxset.hh(206):
warning #1224: #warning directive: "TODO: this is incorrect"
#warning "TODO: this is incorrect"
^
}}}
I propose that such directives are replaced with a comment and a link to a
TRAC ticket concerning the problem.
Further, we should aim to eliminate as many warnings as possible from the
build, similarly to avoid eroding confidence.
Warnings can also make it hard to find the real error messages, when a
build fails with errors.
Other warnings I see are similar to:
{{{
In file included from
/home/ianhin/Cactus/GBSC12/arrangements/CactusUtils/Formaline/src/thornlist.cc:13:
/home/ianhin/Cactus/GBSC12/configs/bbh/bindings/include/thornlist.h:61:
warning: deprecated conversion from
string constant to ‘char*’
}}}
{{{
/home/ianhin/Cactus/GBSC12/arrangements/EinsteinInitialData/TwoPunctures/src/Newton.c:
In function ‘TestRelax’:
/home/ianhin/Cactus/GBSC12/arrangements/EinsteinInitialData/TwoPunctures/src/Newton.c:287:
warning: passing
argument 6 of ‘resid’ from incompatible pointer type
/home/ianhin/Cactus/GBSC12/arrangements/EinsteinInitialData/TwoPunctures/src/Newton.c:75:
note: expected
‘const int * const restrict* const restrict’ but argument is of type ‘int
**’
}}}
{{{
/home/ianhin/Cactus/GBSC12/configs/bbh/bindings/Variables/ADMBase.c: In
function ‘CCTKi_BindingsFortranWrapperADMBase’:
/home/ianhin/Cactus/GBSC12/configs/bbh/bindings/Variables/ADMBase.c:34:
warning: passing argument 22 of ‘function’
from incompatible pointer type
/home/ianhin/Cactus/GBSC12/configs/bbh/bindings/Variables/ADMBase.c:34:
note: expected ‘const struct cGH * const*’
but argument is of type ‘struct cGH **’
}}}
This last warning appears very many times during a build (though I believe
it may be triggered only by GCC and not by the Intel compiler).
{{{
/home/ianhin/Cactus/GBSC12/src/main/Parameters.c: In function
‘ParameterSetBoolean’:
/home/ianhin/Cactus/GBSC12/src/main/Parameters.c:2394: warning: passing
argument 4 of ‘Util_ExpressionEvaluate’
discards qualifiers from pointer target type
/home/ianhin/Cactus/GBSC12/src/include/util_Expression.h:38: note:
expected ‘void *’ but argument is of type
‘const int *’
}}}
There are probably more as well.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/874>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#780: missing small packages
----------------------------------------------+-----------------------------
Reporter: knarf | Owner: dcastl2
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Einstein Toolkit Virtual Machine | Version:
Keywords: |
----------------------------------------------+-----------------------------
Some tools to be installed:
mmv
screen
tmux
texlive (probably quite large, but also probably necessary)
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/780>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit