#745: the flesh allows two implemantion of the same interface to have different
default values for restricted parameters
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
--------------------+-------------------------------------------------------
since the flesh creates paramters for all compiled in (rather than
activated) thorns initially, this affects the default value that a thorn
sees. Thorns seem to be initialized (and thus their parameter structures
being created) in alphabetical order, which means that the thorn
alphabetically '''last''' (How, I have no idea, the parameter handling
logic seems a bit of a mess) will determine the default parameter value.
Attached is a parameter file to demonstrate this with Carpet and PUGH who
both declare parameters periodic and periodic_[xyz] but differ in their
defaults.
To demonstrate, create an executable with only Carpet compiled in and run
the parameter file. Then look at the paramters in the checkpoint it
creates eg.
{{{
h5dump -r -d /Parameters\ and\ Global\ Attributes/All\ Parameters
output/checkpoint.chkpt.it_0.h5 | grep periodic
}}}
Do the same with an executable that contains both PUGH and Carpet. Notice
that parameter values are now PUGH's defaults.
This can actually cause a runs to abort when recovering from a checkpoint
when one switches from an executable with PUGH compiled in to one that
does not. (Beyond the fact that some thorn might actually use it's
parameters rather than the Carpet/PUGH pair where happily Carpet ignores
these parameters and PUGH who actually used them gets to set the default).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/745>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#669: Rewrite users of deprecated HDF5 C++ API
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: task | Status: new
Priority: minor | Milestone:
Component: Other | Version:
Keywords: |
----------------------+-----------------------------------------------------
The C++ API for HDF5 is decprecated. We should examine which code uses it,
and rewrite it to use the C API instead. This would allow us to use more
system-provided HDF5 installations.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/669>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#788: Produce movie about history of Einstein Toolkit
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: task | Status: new
Priority: optional | Milestone:
Component: Other | Version:
Keywords: |
----------------------+-----------------------------------------------------
Do this <https://www.youtube.com/watch?v=ZEAlhVOZ8qQ> for the Einstein
Toolkit.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/788>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#531: Problem with adding/removing configuration.ccl files
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
Cactus doesn't handle well adding or removing configuration.ccl files.
When a new configuration.ccl file is added, Cactus ignores it until the
next "rebuild" (i.e. until another ccl file changes, until the thorn list
changes, or until the user calls *-rebuild explicitly). When a
configuration.ccl file is removed, make aborts with an error message, and
a rebuild is forced.
One way to remedy this would be to have (empty) configuration.ccl file in
all thorns. After all, param.ccl and schedule.ccl files also need to be
present even if they are empty. This would also remove a bit of complex
logic from the Cactus make system.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/531>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#628: Configuring on Kraken leads to warnings
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
Using current simfactory to build on Kraken leads to the following warning
during configuration:
{{{
This is probably a Cray XT4 series system.
Using known-architectures xt4-cray-linux
This is an Cray XT4: you always need MPI!
Forcing MPI to NATIVE.
Unknown Linux f90 compiler.
Please add appropriate information to
/nics/d/home/hinder/Cactus/EinsteinToolkit/lib/make/known-
architectures/linux
and send the updated file to CactusMaint
We will try anyway ...
}}}
Cactus should learn about this system.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/628>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#380: AHFinderDirect failure with qc0-mclachlan.par
--------------------+-------------------------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: major | Milestone: ET_2011_05
Component: Other | Version:
Keywords: |
--------------------+-------------------------------------------------------
Trying to run the par/qc0-mclachlan.par in the ET trunk gives the
following error:
INFO (AHFinderDirect): proc 0: searching for horizons 1,5/6
WARNING level 0 in thorn CarpetInterp processor 0 host kop193.datura.admin
(line 1683 of
/home/ianhin/Cactus/etrelease/arrangements/Carpet/CarpetInterp/src/interp.cc):
-> Grid function "AHFINDERDIRECT::ahmask" has only 1 active time levels
on refinement level 1; this is not en
ough for time interpolation
See also #373, which might be related.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/380>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#488: Reduce space taken by Formaline tarballs
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: Formaline |
-------------------------+--------------------------------------------------
When syncing lightweight data of simulations from a cluster, much of the
time and disk space on the local system is taken with Formaline tarballs.
It would be good to reduce this.
I propose opportunistically replacing the generated tarballs with hard-
links to existing tarballs on the same filesystem after Formaline has
written them to the new output directory if the files compare equal.
These could be from previous restarts of the same simulation when using
simfactory. Then, if an entire simulation is rsynced with the appropriate
options, hard-links will be transferred as hard-links, and the overall
transfer time and disk space used will be significantly reduced.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/488>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#708: Cannot submit on Surveyor
------------------------+---------------------------------------------------
Reporter: eschnett | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
Surveyor is a BlueGene/P, and the operating system apparently does not
support hard links. Submitting a job via Simfactory fails:
DISTRIBUTE: Executing: ./simfactory/bin/sim --remote surveyor create-
submit testsuite-surveyor-2011.12.21-19.31.05 --testsuite
--parfile=recover.par --walltime=2:00:00 --procs=4 --ppn-used=4 --num-
threads=2
Skeleton Created
Job directory: "/pvfs-surveyor/eschnett/simulations/testsuite-
surveyor-2011.12.21-19.31.05"
Executable: "/gpfs/home/eschnett/Cbeta/exe/cactus_sim"
Option list: "/pvfs-surveyor/eschnett/simulations/testsuite-
surveyor-2011.12.21-19.31.05/SIMFACTORY/cfg/OptionList"
Submit script: "/pvfs-surveyor/eschnett/simulations/testsuite-
surveyor-2011.12.21-19.31.05/SIMFACTORY/run/SubmitScript"
Run script: "/pvfs-surveyor/eschnett/simulations/testsuite-
surveyor-2011.12.21-19.31.05/SIMFACTORY/run/RunScript"
Assigned restart id: 0
Copying testsuite data
Traceback (most recent call last):
File "/home/eschnett/Cbeta/simfactory/bin/../lib/sim.py", line 147, in ?
main()
File "/home/eschnett/Cbeta/simfactory/bin/../lib/sim.py", line 143, in
main
CommandDispatch()
File "/home/eschnett/Cbeta/simfactory/bin/../lib/sim.py", line 105, in
CommandDispatch
module.main()
File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 397,
in main
CommandDispatch()
File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 376,
in CommandDispatch
exec("command_%s()" % command)
File "<string>", line 1, in ?
File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 161,
in command_create_submit
command_submit()
File "/gpfs/home/eschnett/Cbeta/simfactory/lib/sim-manage.py", line 262,
in command_submit
restart.userSubmit(simulationName)
File "/gpfs/home/eschnett/Cbeta/simfactory/lib/simrestart.py", line 346,
in userSubmit
self.submit(submitScript)
File "/gpfs/home/eschnett/Cbeta/simfactory/lib/simrestart.py", line 739,
in submit
self.copyTestsuiteData()
File "/gpfs/home/eschnett/Cbeta/simfactory/lib/simrestart.py", line 487,
in copyTestsuiteData
os.link(self.Properties.executable,
os.path.join(testexe,simlib.BaseName(self.Properties.executable)))
OSError: [Errno 95] Operation not supported
Simfactory should catch this, and should copy the file if it cannot be
linked.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/708>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit