#649: simfactory should create the "simulations" directory
------------------------+---------------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
when following the new users tutorial one gets:
{{{
[rhaas@qb1 Cactus]$ ./simfactory/bin/sim submit static_tov
--parfile=par/static_tov.par --procs=32 --walltime=8:0:0
Parameter file: /home/rhaas/Cactus/par/static_tov.par
Error: could not access simulation base directory
/scratch/rhaas/simulations for reading and writing
Aborting Simfactory.
[137450 refs]
}}}
This happens each time I set up a fresh simfactory on a machine. It might
be useful if simfactory would create the simulation base directory if it
does not exist.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/649>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1059: simfactory silent error
--------------------------------------+-------------------------------------
Reporter: anonymous | Owner: eschnett
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: SimFactory | Version:
Keywords: simfactory error message |
--------------------------------------+-------------------------------------
When sim submit -remote ... fails to queue a job because the allocation
has been overdrawn, simfactory does not print any error message to screen
(it is only hidden in the log file).
Could it be made to print an error message to screen?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1059>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#959: Move pthreads to ExternalLibraries
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
We should move pthreads support to ExternalLibraries (or to the flesh).
I have asked CCT to create the respective repository.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/959>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#816: include SphericalHarmonicReconASCII from incoming in PITTNULLCode
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Christian Reisswig provided a copy of SphericalHarmonicReconASCII and
alternative thorn that reads in CCE boundary data (similar
SphericalHarmonicRecon) but supporting a wider variety of input file
formats (HDF5 among them, irrespective of the name).
Used by SpEC and Llama.
There are no docs or test cases as of now. Test data would be welcome
(SpEC, Llama or Cactus provided, I don't think it makes a difference).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/816>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1252: Thorn configuration scripts should not be run if there are missing thorns
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
If there are thorns present in the thornlist which are not present in the
source tree, Cactus currently displays the corresponding error message,
and then runs the rest of the CST including thorn configuration scripts.
Since these can build large external libraries (e.g. LORENE), it can be a
long time before the user notices that the build has failed. I would
prefer if Cactus aborted before running the CST scripts.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1252>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#796: Support https for einsteintoolkit.org
-------------------------------------+--------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit website | Version:
Keywords: |
-------------------------------------+--------------------------------------
To show our commitment to privacy and IT safety, we should enable https
support for our web site.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/796>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1211: CarpetIOScalar should write file info for restart files
--------------------+-------------------------------------------------------
Reporter: knarf | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: Carpet | Version:
Keywords: |
--------------------+-------------------------------------------------------
Currently Carpet doesn't write file info for files created by a restarted
simulation (from a checkpoint, writing into a new file). It should instead
write the header if it created the file - which means it need to check
whether it appends or created the file new.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1211>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1282: Enable HDF5 compression by default in Carpet
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Carpet | Version:
Keywords: |
-------------------------+--------------------------------------------------
The current default for CarpetIOHDF5::compression_level is 0 (no
compression). I have been using compression in most of my HDF5 files for
years, and have never run into any problem. CPUs are typically much
faster than storage nowadays. I propose that the compression level should
default to 9. This would affect output and checkpoint files, and could
lead to huge space savings. Apart from the checkpoint files being written
and read quicker and taking less disk space, the user should not notice,
as the HDF5 library handles compression transparently.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1282>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1326: running loopcontrol on strange number of threads fails
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: LoopControl |
-----------------------------------+----------------------------------------
my machine has 8 cores (according to /proc/cpuinfo). Running eg the
trigger test with 3 threads fails inside of loopcontrol.
To reproduce:
{{{
export OMP_NUM_THREADS=3
mpirun -n 2 exe/cactus_bns_all
arrangements/AEIThorns/Trigger/test/trigger.par
}}}
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1326>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1204: carpet bug
-------------------------------------+--------------------------------------
Reporter: abdik@… | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version:
Keywords: |
-------------------------------------+--------------------------------------
The latest version of carpet seems to contain a bug that affects
AMR+multipatch runs. My stderr and stdout and par file are attached. Found
by Roland and Ernazar.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1204>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit