#1624: remove MOLDOESCOMPLEX from MoL
-----------------------------------+----------------------------------------
Reporter: knarf | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
MOLDOESCOMPLEX is an old #define in MoL, and seems to be unused for quite
some time now. It also comes with the comment "even using it probably
doesn't work" in the commit. I suggest to remove it (removing the code
within).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1624>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1518: Parameter parser and CCTK_ParameterSet interpret leading zeros in numbers
differently
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
the parameter parser allows things like:
{{{
thorn::param1 = 011
thorn::param2 = 012.34
}}}
in parameter files. For floating point values this is a bit unexpected but
otherwise mostly harmless. For integers the situation is a bit more
complex since in C a leading zero is used to indicate a octal number. And
(worse) while the parameter file parser converts the string "011" to the
number 11 the Cactus call CCTK_ParameterSet will convert it to 9. The
difference is ultimately the difference between calling atof (Parser) and
strtol (CCTK_ParameterSet).
To avoid confusion it would likely be good to change CCTK_ParameterSet to
behave the way the Parameter parser does. This is a change in behaviour
compared to the pre-Piraha parser, however I suspect the number of users
that actually used octal (or hexedecimal) notation in their parameter
files is small.
The change is to change {{{inval = strtol (value, &endptr, 0);}}} to
{{{inval = strtol (value, &endptr, 10);}}} in line 2209 of
src/main/Parameters.c and similar in line 2270.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1518>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1635: hwloc requires a certain minimum version, but does not check for it
--------------------+-------------------------------------------------------
Reporter: knarf | Owner:
Type: defect | Status: new
Priority: major | Milestone: ET_2014_11
Component: Cactus | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
Currently, hwloc's configuration.sh searched for any hwloc library and
uses it. However, it requires a pretty new version within some of its own
files, which leads to build failure on, e.g. Debian stable systems.
The attached patch uses pkg-config to get the version of the installed
hwloc library and if that version is older than 1.6 (educated guess, but
see
http://lists.einsteintoolkit.org/pipermail/users/2013-February/002860.html),
builds the bundled version even if another version is installed (but too
old).
Note that this is done (intentionally) only if no library was specified,
and the script was looking for it by itself. This allows users to specify
something which will not be overwritten by this mechanism.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1635>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#428: Forbid configuration names ending in -reconfig
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
I accidentally created a Cactus configuration with a name like "sim-
reconfig". This confuses Cactus, because the command "make sim-reconfig"
can then mean either to build the "sim-reconfig" configuration, or to
reconfigure the "sim" configuration.
Cactus should catch and forbid these cases.
This is probably most cleanly handled by using a script instead of a
Makefile to interpret the user commands.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/428>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1610: Switch Cactus to 64 bits
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Although pointers can have 64 bits, integers in Cactus are de facto (since
we use "int" in many places) restricted to 32 bits. This limit is easily
reached, and this has in fact been a problem on at least two occasions.
One issue comes from Carpet's numbering of grid points. With 25 refinement
levels, the coarse grid can be at most 127^3, and this limit was reached
in production simulations years ago.
Another issue comes from large 1D arrays. It is easily possible to have a
1D array with 10M (10^7) elements that is replicated across processes
(distrib=const). In this case, one can use at most 200 MPI processes.
We should devise a plan to switch Cactus to 64 bits. One option would be
to replace most "int" by "CCTK_INT", so that those affected can switch
these to 64 bits.
I want to note that using 64-bit loop counters is often slightly faster
than using 32-bit loop counters (on 64-bit architectures), since the
32->64 bit conversion for array indexing can be omitted.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1610>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1565: change default of IOUtil::out_save_parameters to true
-------------------------+--------------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
it would be useful of HDF5 files contained the full set of parameter
values. This can be used by postprocessing scripts to find out eg about
the symmetry conditions or some of the grid structure parameters as well
as atmosphere settings.
IOUtil::out_save_parameters controls whether the full set of parameters or
only those that have been steered are written to file (for regular output,
checkpoints always write all parameters).
I would like to change the default so that all parameters are always
written. If feasible I would even want to write all parameter changes to
file (either as full parameter dumps for each output or as a full dump
when the simulation starts then deltas afterwards).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1565>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1628: Enable padding by default
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
Enable padded allocation in Carpet by default.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1628>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1630: ML_BSSN harmonic shift is ill-posed
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
The implementation of the ML_BSSN harmonic shift is ill-posed. It should
use the evolved Gamma variables instead of taking metric derivatives. A
robust stability test clearly shows an instability: higher resolutions
have faster growing errors.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1630>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1632: problem with compilation
-----------------------------------+----------------------------------------
Reporter: barmv | Owner: new user
Type: defect | Status: new
Priority: critical | Milestone: ET_2014_05
Component: EinsteinToolkit thorn | Version: development version
Keywords: GRHydro Utils F90 |
-----------------------------------+----------------------------------------
Ubuntu workstation, gcc and gfortran compilers.
$./GetComponents --parallel
https://svn.einsteintoolkit.org/manifest/branches/ET_2014_05/einsteintoolki…
after that make the configuration
$./simfactory/bin/sim setup --optionlist=ubuntu.cfg --runscript debian.sh
but fail to do build of the project
$./simfactory/bin/sim build
********************************************************************************
Running configuration script for thorn HWLOC:
hwloc selected, but HWLOC_DIR not set. Checking some places...
Found hwloc in /usr
Finished running configuration script for thorn HWLOC.
Checking consistency...
Creating Thorn-Flesh bindings...
Creating implementation bindings...
Creating parameter bindings...
Creating variable bindings...
Creating schedule bindings...
Creating function bindings...
------------------------------------------------------
There were 2 errors during execution of the CST
These must be corrected before compilation can proceed
------------------------------------------------------
------------------------------------------------------
Warnings were generated during execution of the CST
------------------------------------------------------
CST error 1:
-> Configuration script for thorn FORTRAN returned exit code 1
Error message: 'Fortran thorn requires that a Fortran compiler is
defined, but F77 = 'none' and F90 = 'none'. Aborting.'
CST error 2:
-> Configuration script for thorn LORENE returned exit code 1
(no error message)
------------------------------------------------------
make[1]: *** [/home/Cactus/configs/sim/config-data/make.thornlist] Error 1
make: *** [sim] Error 2
///////////////////////////////////////////////////////
After that
$make config
$make test1
$make test1 2&> test1_log.txt
The compilation of the cactus report errors in file
Cactus/configs/test1/build/GRHydro/Utils.f90
COMPILING arrangements/EinsteinEvolve/GRHydro/src/Utils.F90
Warning: Nonexistent include directory
"/home/bmv/utils/soft/cactus/Cactus/arrangements/EinsteinEvolve/GRHydro/src/include"
Warning: Nonexistent include directory
"/home/bmv/utils/soft/cactus/Cactus/arrangements/EinsteinEvolve/GRHydro/src/include"
/home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2879.10:
pointer (pg11,g11), (pg12,g12), (pg13,g13), (pg22,g22), (pg23,g23),
(pg33,g33)
1
Error: Cray pointer declaration at (1) requires -fcray-pointer flag
/home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2882.8:
pg11 = loc(gaa)
1
Error: Symbol 'pg11' at (1) has no IMPLICIT type
/home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2883.8:
pg12 = loc(gab)
1
Error: Symbol 'pg12' at (1) has no IMPLICIT type
/home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2884.8:
pg13 = loc(gac)
1
Error: Symbol 'pg13' at (1) has no IMPLICIT type
/home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2885.8:
pg22 = loc(gbb)
1
Error: Symbol 'pg22' at (1) has no IMPLICIT type
/home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2886.8:
pg23 = loc(gbc)
1
Error: Symbol 'pg23' at (1) has no IMPLICIT type
/home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2887.8:
pg33 = loc(gcc)
1
Error: Symbol 'pg33' at (1) has no IMPLICIT type
make[3]: *** [Utils.F90.o] Error 1
make[2]: *** [make.checked] Error 2
make[1]: *** [/home/Cactus/configs/test1/lib/libthorn_GRHydro.a] Error 2
make: *** [test1] Error 2
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1632>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1636: check and abort if more timelevels are requested than time hierarchy
supports
-------------------------+--------------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
In order to provide a more user friendly fix for #626 we want to change
Carpet (and PUGH?) such that they check at runtime, when memory is
allocated that the number of requested timelevels is less or equal than
what the time hierarchy (controlled by the max_timelevels) parameter
supports.
This check should be done early and should take the checkpoint tag as well
as prolongation operator tags into account.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1636>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit