#1487: Documentation build should be tested as part of the automated build and
test
--------------------+-------------------------------------------------------
Reporter: hinder | Owner: hinder
Type: defect | Status: new
Priority: minor | Milestone:
Component: Other | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
The build of the ET documentation should be tested as part of the
automated build and test.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1487>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#791: Output timer tree as XML
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version:
Keywords: |
-------------------------+--------------------------------------------------
The attached patch to Carpet adds a parameter (off by default) which
outputs the timer tree from each process to an XML file in the output
directory at the end of the run. The output looks like this:
{{{
<timer name = "main"> 7.7702
<timer name = "CallFunction"> 0.000241
<timer name = "thorns"> 0.000233
<timer name = "CaKernel_FreeDevMem"> 0.000221
<timer name = "PostCall"> 2e-06 </timer>
<timer name = "PreCall"> 1e-06 </timer>
</timer>
</timer>
</timer>
<timer name = "CarpetStartup"> 0.00982
<timer name = "AllocateGridHierarchy"> 5e-06 </timer>
}}}
An alternative schema would be to have the name and timer value as
subelements; i.e.
{{{
<timer>
<name>main</name>
<value>7.7702</value>
<children>
<timer>
<name>CallFunction</name>
<value<0.000241</name>
...
</timer>
}}}
The <children> tag might not be necessary, but might make it easier to
parse. Having one file per process is not ideal; we would like to add
reductions across processes to give min, max, average, standard deviation
etc, also for the standard output display.
OK to commit as a work-in-progress? We can change the schema later if it
turns out to be easier to deal with.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/791>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#727: Test output changes every time some tests are run
-----------------------------------------------------------+----------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: testsuites QuasiLocalMeasures IDAxiOddBrillBH |
-----------------------------------------------------------+----------------
Each time a new run of the test suites is performed, the test output of
IDAxiOddBrillBH and QuasiLocalMeasures changes a little. These changes
are below the tolerances set in the test.ccl files, so the tests pass, but
there should be no change at all when the tests are run on the same
machine.
An example of the difference from one test run to the next is shown at
http://git.barrywardell.net/EinsteinToolkitTestResults.git/blobdiff/95fe088….
Another example, from QuasiLocalMeasures, is at
http://git.barrywardell.net/EinsteinToolkitTestResults.git/blobdiff/95fe088…
/qlm-ks-shifted/admbase::metric.average.asc.
The only thorns to exhibit this behaviour are IDAxiOddBrillBH and
QuasiLocalMeasures. All other test data remains unchanged from one test
run to the next. Note that the two test runs will be performed with
different executables, since a new configuration is created for each run.
I think I remember testing that simply re-running the same executable
resulted in the same test output.
Is it possible that there are a small number of points which access
uninitialised memory which changes on each run for these thorns?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/727>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#1071: ensure atmosphere is properly set after ID
-----------------------------------+----------------------------------------
Reporter: knarf | Owner:
Type: defect | Status: new
Priority: major | Milestone: ET_2012_11
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
At the moment GRHydro doesn't ensure properly that the atmosphere is set
after initial data. This is no problem as long as the ID thorn takes care
of this, the ID doesn't contain atmosphere or the EOS is sufficiently
robust to 'recover'. However, this is not always the case. Thus, I propose
to set the atmosphere mask in PostInitial, initializing it according to
whatever was setup there by some other thorn.
The patch to do that is attached. It is only a change to schedule.ccl as
the corresponding function already exists.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1071>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1152: Add option to compute center of mass to hydro_analysis and lots of smaller
changes
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: Hydro_Analysis |
-----------------------------------+----------------------------------------
The attached set of patches adds the possibility to compute a center of
mass location to hydro_analysis. It works by computing the center of mass
(via x[idx]*rho[idx]) of the matter in a region of radius
Hydro_Analysis_r_core around the point of maximum density. Only points
whose density is above a fraction Hydro_Analysis_rho_core_rel_min of the
maximum density are considered.
I also include a number of bugfix patches and patches to make
Hydro_Analysis more controllable by user input rather than hard-coded
values. All patches contain a short description in the patch (ie. the git
commit message).
The ones adding extra control and/or warnings are:
* Hydro_Analysis: add verbosity_level option to control how much data to
output to stdout
* Hydro_Analysis: use Fortran modules for prototypes if available
* Hydro_Analysis: add parameters to control which interpolator is used
* Hydro_Analysis: make parameters steerable
* Hydro_Analysis: warn if grid point with maximum value cannot be found on
grid
* Hydro_Analysis: add parameter Hydro_Analysis_comp_rho_max_every
* Hydro_Analysis: add option rho_max_loc_use_rotatingsymmetry180
* Hydro_Analysis: add option to average the location of multiple identical
maxima
* Hydro_Analysis: fiddle with when to warn about multiple identical maxima
Bugfixes are:
* Hydro_Analysis: checkpoint grid scalars
* Hydro_Analysis: do reduction in global mode
New feature:
* Hydro_Analysis: add routine to compute center of mass in core region
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1152>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1006: ExternalLibraries' configure.sh scripts handle /usr inconistently
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: ExternalLibraries |
-----------------------------------+----------------------------------------
library path used for -L should not contain the system paths at least
/lib, /lib64, /usr/lib, /usr/lib64, /usr/local/lib, /usr/local/lib64 (plus
MacOS equivalents, and any other OS we support).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1006>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1338: Rename Carpet output files
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version:
Keywords: |
----------------------+-----------------------------------------------------
Windows does not allow colons in file names. Output files produced by
Carpet's should therefore not use colons.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1338>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1537: Deprecate complex number functions
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: ET_2014_11
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
The complex number functions in Cactus are not necessary any more since
all languages (Fortran, C, C++) have built-in support that should rather
be used. These functions should be marked "deprecated" in the
documentation (but not removed).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1537>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1555: Simfactory: intel optionlists with rdynamic option
-------------------------+--------------------------------------------------
Reporter: bmundim | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone: ET_2014_05
Component: SimFactory | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Hi,
While reviewing some options in my config file I noticed that the
-rdynamic gcc option for the linker is applied also to the intel compiler
option lists in symfactory. However there seems to have no such an option
when using icc or
icpc. Wouldn't be better then to pass this option as --export-dynamic
directly to the linker ld instead? Maybe as follows:
LDFLAGS = -Wl,--export-dynamic -Wl,-rpath,/path/to/whatever
instead of
LDFLAGS = -rdynamic -Wl,-rpath,/path/to/whatever
Thanks,
Bruno.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1555>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit