#1531: GRHydro updates
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: GRHydro EOS_Omni |
-----------------------------------+----------------------------------------
A large number of GRHydro updates have accumulated. Attached please find
them all as well as a required update to EOS_Omni.
Patches to follow in a bit.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1531>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1536: Wrong code in Piraha.hpp
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: critical | Milestone:
Component: Cactus | Version: development version
Keywords: |
----------------------+-----------------------------------------------------
Piraha.hpp contains in lines 171 ff the code
{{{
const char c;
Literal(char b) : c(b) {}
bool match(Matcher *m);
std::string fmt() {
std::string s = "literal(";
s += c+")";
return s;
}
}}}
In this code, the expression c+")" adds a character to a pointer, in
effect adding to the pointer. This does not append to the string s, as was
intended.
There seem to be several similar cases in other locations as well.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1536>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1568: Reduce overhead of Formaline
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
The Formaline thorn, used for storing important information about a
simulation in the simulation output, currently has some performance and
size overheads which discourage people from using it. These should be
reduced or mitigated to encourage people to use this important thorn.
This ticket is based on discussion in #1565.
Problems with Formaline:
* During compilation, Formaline stores the built source tree in a
cactusjar.git repository. My impression is that this takes a lot of time
on slow filesystems.
* During compilation, Formaline stores the whole source tree as tarballs
in the executable. My impression is that this is also slow.
* The source tarballs output in the simulation output directory are
often many times larger than the rest of the simulation, and cause a lot
of overhead when transferring simulations for analysis. This might be
improved by a better sync tool (simfactory 3?) which identified that
tarballs were identical to those which have already been transferred, and
skipped the transfer. I would like that the source tarballs are identical
if the contents are identical, even if Cactus has been rebuilt. I think I
observed that this was not the case (maybe a build ID is included?).
* As an aside: there is a message at link time that Formaline has
finished doing something, but this is misleading; Formaline has other
tasks which it does after this message is displayed; the wait for the
final executable is not due solely to linking, but also to some archiving
task of formaline.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1568>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1569: captcha test
-----------------------+----------------------------------------------------
Reporter: anonymous | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version: development version
Keywords: |
-----------------------+----------------------------------------------------
you may be interested in this.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1569>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1566: Update Cactus autoconf
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version: development version
Keywords: |
----------------------+-----------------------------------------------------
We are using autoconf 2.13 for Cactus. This release is by now 15 years old
and doesn't support Fortran (nor modern C++ features). It is time to
update.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1566>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1564: EinsteinExact should output the RHS as well
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
The EinsteinExact arrangements should output not only the analytic
solution, but also its time derivative, so that one can study convergence
of the RHS e.g. at t=0.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1564>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1557: include thorn TestMoL in ET
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: MoL |
-----------------------------------+----------------------------------------
the thorn TestMoL (for the CactusTest arrangment) exercises most of MoL's
integrators (not the Adams-Bashforth ones yet nor the generic one since
they are "different").
It would be useful to include in the ET to have a basic test of the
central ODE solver.
The thorn is currently in incoming
{{{
svn co https://svn.einsteintoolkit.org/incoming/TestMoL
}}}
it contains test cases (that's the whole point) and some documentation. I
have used it to test the recent MoL commits and found two outstanding bugs
that way.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1557>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1561: Show paths relative to CCTK_HOME in non-verbose output
---------------------------+------------------------------------------------
Reporter: barry.wardell | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version: development version
Keywords: |
---------------------------+------------------------------------------------
When Cactus is compiling a thorn, it currently prints the absolute path to
the file being compiled. This can lead to very long output lines. I
suggest instead printing just the path relative to CCTK_HOME. The attached
patch implements this, but only when in non-verbose mode.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1561>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1560: Calculate solution error in EinsteinExact
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
I implemented a facility to calculate the solution error as analysis
quantity in EinsteinExact. I pushed this to a new branch eschnett
/solution-error.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1560>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1505: remove the MoL number of variables accumulators
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: MoL |
-----------------------------------+----------------------------------------
The attached patches removes the need for MoL's accumulator parameters to
count the number of evolved, constrained and save-and-restore variables.
Instead it counts them during MoL_RegisterVariables and using timelevels
as a way of creating new variable storage for the scratch levels. This
means unfortunately that it will create C pointers for 99 (the current max
in interface.ccl) scratch timelevels ie there is ScratchSpace_p_p_p_p..._p
.
Currently applies on top of trunk.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1505>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit