#983: Improvements to "list-simulations"
------------------------------+---------------------------------------------
Reporter: anonymous | Owner: eschnett
Type: enhancement | Status: new
Priority: major | Milestone:
Component: SimFactory | Version: development version
Keywords: list-simulations |
------------------------------+---------------------------------------------
The SimFactory command "list-simulations" may be made more useful by
- making it faster
- adding options to output only running, queued and
held simulations (excluding the finished ones)
- adding information on the remaining wall-clock time
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/983>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#981: simfactory fails on hopper when the login shell is csh
------------------------+---------------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
if the login shell is csh on hopper, the I get:
{{{
work/ET_trunk> simfactory/bin/sim build
--thornlist=thornlists/einsteintoolkit.th
Using configuration: sim
/bin/bash: module: command not found
/bin/bash: module: command not found
/bin/bash: module: command not found
/bin/bash: module: command not found
/bin/bash: module: command not found
Reconfiguring sim
Writing configuration to:
/global/project/projectdirs/m152/rhaas/hopper/ET_trunk/configs/sim/OptionList
/bin/bash: module: command not found
}}}
I am not sure if I should classify this as a bug or a feature since it
makes it prevents people from using csh :-P
I am not sure out of which hat simfactory pulls the "/bin/bash" string,
since "bash" does not appear in any hopper related file it seems.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/981>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#855: CCTK_TraverseString should be documented
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
CCTK_TraverseString should be documented
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/855>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#974: Compilation problem in LoopControl with xlc compiler
-----------------------------------------+----------------------------------
Reporter: wolfgang.kastaun@… | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version: development version
Keywords: |
-----------------------------------------+----------------------------------
I was trying to compile ET on MareNostrum (BSC) using the xlc/xlC/xlf
compiler suite version 10.01 and failed. The first relevant error reads:
"/gpfs/home/uv08/uv08986/source/Cactus/configs/z4pisky_std/build/LoopControl/loopcontrol.c",
line 1371.1: 1506-343 (S) Redeclaration of lc_statmap_init differs from
previous declaration on line 631 of
"/gpfs/home/uv08/uv08986/source/Cactus/configs/z4pisky_std/build/LoopControl/loopcontrol.c".
"/gpfs/home/uv08/uv08986/source/Cactus/configs/z4pisky_std/build/LoopControl/loopcontrol.c",
line 1371.1: 1506-376 (I) Redeclaration of lc_statmap_init has a different
number of fixed parameters than the previous declaration.
"/gpfs/home/uv08/uv08986/source/Cactus/configs/z4pisky_std/build/LoopControl/loopcontrol.c",
line 1371.1: 1506-377 (I) The type "char*" of parameter 3 differs from the
previous type "const char* restrict const".
The fist declaration reads:
630 void
631 lc_statmap_init (int * restrict const initialised,
632 lc_statmap_t * restrict const lm,
633 char const * restrict const name)
634 {
while the second is
1374 CCTK_FCALL
1375 void
1376 lc_statmap_init (int * restrict const initialised,
1377 lc_statmap_t * restrict const lm,
1378 ONE_FORTSTRING_ARG)
1379 {
From the compiler message, I guess ONE_FORTSTRING_ARG expanded to
something of type char*
It seems the idea here is to provide a version of a C function callable
from Fortran. However, it ends up having the same name and argument types
(apart from const-ness), which is forbidden. From the Cactus manual I
would guess one needs to wrap the second declaration inside a CCTK_FNAME
macro, like
void CCTK_FCALL CCTK_FNAME(lc_statmap_init)(int * restrict const
initialised, lc_statmap_t * restrict const lm, ONE_FORTSTRING_ARG) {
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/974>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#978: parameters to reverse un-enforced Cactus schedule ordering
-------------------------+--------------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
the attached patch adds two new parameters to the flesh:
* schedule_sort_mode - which affects the order of schedule items before
enforcing BEFORE/AFTER
* schedule_sort_warnings - which outputs warnings if a schedule item
refers to a non-existing item in its BEFORE/AFTER modifiers
Neither one is intended to be used in production runs but they are useful
for debugging a schedule.
schedule_sort_warnings is intended to catch typos in dependency names and
when one tries to order with respect to items hidden within a group. It
will find a number of false positives for items that are only scheduled
based on parameter settings. Eg. MoL's RHS NaN checker.
schedule_sort_mode can be used to ensure that the schedule order does not
depend on the (semi-random) order that Cactus generates for non-enforced
ordering.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/978>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#979: vim syntax files for Cactus types and constructs
-------------------------+--------------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: Other | Version:
Keywords: |
-------------------------+--------------------------------------------------
The attached syntax file, when copied into $HOME/.vim/after/syntax (see
http://vimdoc.sourceforge.net/htmldoc/syntax.html, "ADDING TO AN EXISTING
SYNTAX FILE") enables some syntax highlighting for Cactus types and
DECLARE_CCTK_XXX. Similar files for Fortran also possible. I don't know
anything about Emacs.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/979>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#975: Check dependencies after presubmitting
------------------------+---------------------------------------------------
Reporter: eschnett | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
When presubmitting, it may be that the first job is already done by the
time the second job has been submitted. Since the second job waits until
the first will finish, but the first job does not exist any more, some
queueing systems will keep the second job on hold indefinitely.
Check for this condition after submitting the second job, and if so,
release the hold on the second job explicitly.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/975>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#973: add force-realclean facility to Cactus build system
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
--------------------+-------------------------------------------------------
there is currently no way to force a clean rebuild when low level files
within Cactus change. This happened twice recently (once to introduce
cctk_ash and once to split cctk.h into separate files).
In the both case, failing to recompile causes very strange parameter
related errors at runtime.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/973>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#634: Riemann1D fails to compile on Kraken
-----------------------------------+----------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: GRHydro |
-----------------------------------+----------------------------------------
I'm unable to compile the Riemann1D utility on Kraken. It gives the
following error message.
{{{
Creating Riemann1d in /nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim
from
/nics/d/home/hinder/Cactus/EinsteinToolkit/configs/sim/build/GRHydro/Riemann1d.o
/nics/d/home/hinder/Cactus/EinsteinToolkit/configs/sim/build/GRHydro/Riemann1d.o:
In function `riemann1d':
/nics/d/home/hinder/Cactus/EinsteinToolkit/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d.f90:10:
undefined reference to `__kmpc_begin'
/nics/d/home/hinder/Cactus/EinsteinToolkit/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d.f90:374:
undefined reference to `__kmpc_end'
/usr/bin/ld: link errors found, deleting executable
`/nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim/Riemann1d'
make[1]: ***
[/nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim/Riemann1d] Error 1
make: *** [sim-utils] Error 2
}}}
I think that this needs an Intel library to be linked in, but I'm not sure
which one or how to add it.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/634>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit