#582: Semi-automatically split McLachlan's calculations
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Split McLachlan's calculations semi-automatically in two ways: (a) by
variable, so that e.g. dot[g] and dot[K] are calculated separately, and
(b) by pattern, so that advection terms, dissipation, and "everything
else" are calculated separately. Also introduce parameters to choose which
routines are called at run time.
This is somewhat a work in progress, in that the patch is good, but the
API defined to split kernels is more complex and less failsafe than it
should be.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/582>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#499: Prolongation fails with vectorisation enabled
--------------------+-------------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version:
Keywords: |
--------------------+-------------------------------------------------------
The development version of Carpet uses vectorisation to speed-up
prolongation. This fails with various errors, including corruption of the
malloc heap.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/499>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#445: Make Carpet timers hierarchical
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Carpet | Version:
Keywords: |
-------------------------+--------------------------------------------------
With the current flat structure of timers in Carpet, it is difficult to
identify which timers are contained in which other timers, and hence to
avoid double-counting when adding up the times.
This series of patches modifies the timer infrastructure in Carpet to
generate a tree of timers where the hierarchy reflects the call-graph of
the program. This makes it much easier to interpret the timer output than
with the previous flat structure, where it was not possible to see which
timers "contained" which others. More implementation details are given at
the top of TimerNode.hh.
Note that the Timer source and header files have been renamed as
CactusTimer and a new Timer file and object has been created. This is
because the Timer object now only provides a wrapper around the Cactus
timer mechanism which was contained in the old Timer object.
New parameters output_initialise_timer_tree and output_timer_tree_every
control output of a new "timer tree diagram" to standard output for the
Initialise and Evolve timer trees respectively. These diagrams indicate:
1. the value of each timer;
2. the percentage of the given tree taken by each timer;
3. which timers are contained in which other timers;
4. any untimed code
for any timer which takes more than 1% of the tree time.
Making the timers hierarchical means that the ad-hoc methods used before
to identify the hierarchy (such as naming the timer Evolve::Sync, for
example, to indicate that the Sync timer was a child of the Evolve timer)
are no longer necessary and have been removed. Additionally, the
construction of timers in a "dynamic" manner is now handled automatically
for all timers, so special-case code is no longer needed and has been
removed.
Additionally some previously-untimed parts of the code are now timed, and
timer names have been made more consistent in some places.
There is code in the patches to output the entire timer tree as an XML
file, but it is not enabled.
Ideally the timer tree printed to standard output would contain reductions
across processes, but at the moment it contains only the timer from the
current process.
The attached "tree-example.txt" file shows an example of the timer tree
that is printed for a simulation using the qc0-mclachlan parameter file
from the Einstein Toolkit.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/445>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#590: McLachlan should allow other thorns to set the gauge
-----------------------------------+----------------------------------------
Reporter: bmundim | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
The parameters lapse_evolution_method and shift_evolution_method are
usually set to ML_BSSN in McLachlan. However they are never checked
in the code. McLachlan indeed seems to ignore their values and
overwrite whatever the values of lapse or shift set elsewhere,
preventing therefore other thorns from setting them differently.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/590>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#849: Drop explicit support for Fortran 77 in Cactus
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
I suggest to drop explicit support for Fortran 77 in Cactus. Fortran 77
is, for all practical purposes, a subset of Fortran 90, and thus Fortran
77 code can be compiled by Fortran 90 compilers.
There is currently no platform that has a Fortran 77 and no Fortran 90
compiler, and there is no Fortran source code in Cactus that cannot be
compiled by a Fortran 90 compiler.
In a way, supporting Fortran 77 as language is similar to supporting K&R C
as a language. We don't do this either.
I suggest to remove/ignore all configuration options regarding Fortran 77,
and to compile .f77 and .F77 files with a Fortran 90 compiler. This change
will simplify the configuration stage of Cactus. I don't expect any user
to notice.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/849>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#882: Create ThornGuideHTML target
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
Barry Wardell suggests: The only issue is that there doesn't seem to be a
HTML version of the configuration specific ThornGuide make target, so we
should add this as a target at the same time as removing the patch. I'd
imagine this would just be a matter of copy-and-paste from the existing
ThornGuideHTML target.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/882>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#542: Remove thorn CactusArchive/ADM from thorn list
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Remove thorn CactusArchive/ADM from thorn list. This thorn is outdated,
and we should updated out test cases instead. It also takes a long time
and a lot of memory to compile.
If we want an ADM formulation (which is doubtful since we don't use it
ourselves), we should implement one via Kranc.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/542>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#114: per-variable tolerances for Cactus testsuites
-------------------------+--------------------------------------------------
Reporter: knarf | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: ET_2011_06
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
It would be nice to be able to specify per-variable testsuite tolerances
in Cactus (per regexp for the name in the ideal case).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/114>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#809: Add CactusExamples to Einstein Toolkit
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
I notice that the CactusExample thorns are not part of the Einstein
Toolkit
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/809>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#896: Create testsuites for GRMHD sector of GRHydro
---------------------------------------+------------------------------------
Reporter: bmundim | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: GRHydro, GRMHD, testsuite |
---------------------------------------+------------------------------------
Create testsuites for GRMHD sector of GRHydro even though it's currently
in rapid and constant development.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/896>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit