#1574: update AEIThorns::Trigger doc, correct parameter steerabiblity, fix
skipping non-set triggers
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: Trigger |
-----------------------------------+----------------------------------------
the attached patches do:
* reduce_int.patch: allow reductions on non-integer variables
* int_param.patch: allow non-real parameters to be checked
* doc_scalars.patch: update documentation to mention handling of grid
scalars
* no-checkpoint-scalars.patch: don't checkpoint temporary variables
* ignore_empty_triggers.patch: fix code so that empty paramater/variable
names cause it to skip a trigger which is what param.ccl documents it to
do
* fix_parameter_steerability.patch: some parameters are parsed into a GH
extension at STARTUP and thus cannot be (meaningfully) steered afterwards.
This patch marks those parameters as STEERABLE=RECOVER.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1574>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1585: Changes in einsteintoolkit.th thornlist
--------------------------------+-------------------------------------------
Reporter: bmundim | Owner:
Type: task | Status: new
Priority: optional | Milestone: ET_2014_05
Component: Other | Version: development version
Keywords: einsteintoolkit.th |
--------------------------------+-------------------------------------------
Hi,
I have noticed a few changes in the einsteintoolkit.th thornlist from
Noether release to current development on trunk. I just would like to
confirm that the
following thorns were supposed to go (r268):
CactusArchive/ADM
EinsteinEvolve/LegoExcision
On top of that I noticed that on r269 some thorns were added to be
downloaded only but not compiled, however they are still commented out in
the thornlist. For example:
!CHECKOUT = CactusElliptic/EllPETSc
...
#CactusElliptic/EllPETSc
Wouldn't be better to clean this up before the release?
Thanks,
Bruno.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1585>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1586: All Carpet documentation should be integrated into the Cactus documentation
system
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
The Carpet arrangement has several documentation tex files:
{{{
documentation.tex
domain-decomposition.tex
first-steps.tex
internals.tex
scheduling.tex
}}}
but only documentation.tex is included in the Cactus-generated
documentation, and hence appears on the web. I suggest that
documentation.tex should include the other documents as well, even if as
appendices. The information about modes in scheduling.tex seems very
useful.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1586>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1584: CarpetIOHDF5 should support extensible datasets
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Currently, CarpetIOHDF5 outputs one dataset per iteration. This makes
sense for gridfunctions, as the datasets are typically large and can
change shape if there is regridding. However, for grid arrays, the size
is fixed from one iteration to the next, and there are often only a few
values of interest. This means that output consists of hundreds of
separate datasets, all of the same shape, and each with only a handful of
elements.
HDF5 supports "extensible datasets"
<http://www.hdfgroup.org/HDF5/Tutor/extend.html>. These are datasets
which can be extended with new data in some directions after being first
created. I propose that CarpetIOHDF5 should support output of grid arrays
using this format. Multipole already does this. We would add a dimension
for "iteration" and extend the dataset in that dimension when new output
is available. This would mean that a grid array could be read from a
single dataset, rather than having to loop over all iterations.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1584>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1582: Release status page is hidden
-------------------------------------+--------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit website | Version: development version
Keywords: |
-------------------------------------+--------------------------------------
I cannot find a path from the front page of the ET web site to the release
status, i.e. the test suite results. Those should be easily accessible, so
that everybody (including the developers) can see.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1582>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1580: Move recorded talks to separate repository
-------------------------------------+--------------------------------------
Reporter: eschnett | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit website | Version: development version
Keywords: |
-------------------------------------+--------------------------------------
Please move the large files containing the recorded talks to a separate
repository, or a separate location. Having them in the main svn repo for
the ET web site is inconvenient when one uses a slow wireless connection.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1580>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1562: ExternalLibraries/hwloc unbuildable after a make clean.
-----------------------+----------------------------------------------------
Reporter: anonymous | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version: development version
Keywords: |
-----------------------+----------------------------------------------------
ExternalLibraries/hwloc seems to get into an unbuildable state after
doing a "make MY-CONFIG-clean". In other words, after executing
the clean target a subsequent make encounters returns an error:
arrangements/ExternalLibraries/hwloc/src/system_topology.cc:47:19:
error: hwloc.h: No such file or directory
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1562>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1573: Simfactory aborts when --basedir is added as option to 'sim create-submit'
------------------------+---------------------------------------------------
Reporter: bmundim | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone: ET_2014_05
Component: SimFactory | Version: ET_2013_11
Keywords: |
------------------------+---------------------------------------------------
I was trying to group several simulations under the same directory name
and thought of using the option --basedir to overwrite my machine default.
I was
able to submit the job without a problem:
{{{
sim create-submit BLAH --config blahblah --machine loewe --basedir
/path/to/new/basedir --parfile blah.par --walltime 2:00:00 --num-threads
12 --procs 96
}}}
The simulation directory and paths to executable, run and submit scripts
were
correctly created and saved in properties.ini in the simulation SIMFACTORY
directory. However when the job was supposed to start running, Simfactory
aborted with the following error message:
{{{
Error: unable to load simulation BLAH for execution
Aborting Simfactory.
}}}
I suspect this error occurs because the run command doesn't inherit the
new
--basedir option. I tracked down message in the definition of
command_run() in sim-manage.py. Looking at SimRestart in simrestart.py we
can see it loads
the basedir from the machine entry:
{{{
self.BaseDir = simlib.GetBaseDir(machineEntry)
}}}
Would it be possible to save basedir to properties.ini and avoid loading
it from the machine entry? This would allow the user to overwrite the
machine entry.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1573>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1493: testsuite Carpet/outer-buffers fails
--------------------+-------------------------------------------------------
Reporter: knarf | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone: ET_2014_05
Component: Carpet | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
The testsuite Carpet/outer-buffers fails because it sets the parameter
Carpet::use_outer_buffer_zones which doesn't exist anymore.
This testsuite was not usually run because a required thorn wasn't part of
the toolkit. This now changed, triggering a failure in the regular builds
and tests.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1493>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1558: trying to activate more thorns than compiled into Cactus leads to strange
error message
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
Right now if one tries to activate more thorns than the total number of
thorns compiled into the executable, Cactus aborts with
{{{
WARNING level 0 in thorn Cactus processor 0 host horizon.tapir.caltech.edu
(line 951 of
/mnt/data/rhaas/postdoc/gr/Zelmani/configs/null/build/Cactus/main/ActiveThorns.c):
-> Internal error
}}}
this is utimately due to Cactus creating a list of maximum size number-of-
compiled-in-thorns to record the number of thorns that are requested to be
activated.
The attached patches automatically grows this list whenever it would
otherwise be too small (doubles the size).
An alternative would be to implement stringlist using a std::map object,
however the mapping of the std::map interface to what StringList provides
is cumbersome.
ok to apply?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1558>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit