#410: CarpetIOHDF5 may segfault when one_file_per_group is selected
--------------------------------+-------------------------------------------
Reporter: bmundim | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version:
Keywords: Carpet git version |
--------------------------------+-------------------------------------------
I was facing one of those cryptic MPI error messages on Ranger,
where your job quits without any useful error message. It turns out
that this parameter file had
CarpetIOHDF5::one_file_per_group = "yes"
CarpetIOHDF5::out2D_vars = " ADMBase::gxx"
and CarpetIOHDF5 would try to loop over the group variables when
just one of them was selected. As a result it has accessed memory
address that it was not supposed to, consequently killing the job.
I have attached the stack back trace.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/410>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#431: Update some external libraries
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Several external libraries have new versions available:
LAPACK
PETSc
curl
git
These are only minor updates. I suggest to apply them.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/431>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#136: Don't rebuild external libraries so often
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
One way to keep the external libraries that have been built would be the
following. Create a dummy configuration "ext" where all external libraries
are built. When another configuration is built, it should be easy to
specify to look there for the external libraries, or maybe this should
even be the default.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/136>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#222: Dubious code in Hydro_InitExcision.c
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
Hydro_InitExcision.c contains the following code:
if ( (hydro_initexcision_coordinate_length <= 0.0) &&
( ( x_frac > 0.5 - hydro_initexcision_fraction) &&
( x_frac < 0.5 + hydro_initexcision_fraction) &&
( y_frac > 0.5 - hydro_initexcision_fraction) &&
( y_frac < 0.5 + hydro_initexcision_fraction) &&
( z_frac > 0.5 - hydro_initexcision_fraction) &&
( z_frac < 0.5 + hydro_initexcision_fraction)
) ||
( (hydro_initexcision_coordinate_length > 0.0) &&
( fabs(x[point]-hydro_initexcision_position_x) <=
hydro_initexcision_coordinate_length*0.5) &&
( fabs(y[point]-hydro_initexcision_position_y) <=
hydro_initexcision_coordinate_length*0.5) &&
( fabs(z[point]-hydro_initexcision_position_z) <=
hydro_initexcision_coordinate_length*0.5)
)
)
This code has an "and" (&&) and an "or" (||) operation at top level. Is
this intended? The code would be clearer with an additional set of
parenthesis, or by introducing a suitable set of temporaries for sub-
expressions.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/222>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#235: Improve performance of Fortran index calculations
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
In Fortran, Cactus currently declares grid functions e.g. as (this is the
expansion of DECLARE_CCTK_ARGUMENTS)
REAL*8 gxx (X0metric,X1metric,X2metric)
where X0metric etc. are integers passed into the routine. Each grid
function group has its own, independent size. This has two disadvantages:
1. The compiler does not know that all grid functions have the same size
(namely cctk_lsh), and thus has to perform array index calculations
separately for each group
2. The argument list is longer than neded
The enclosed patch declares grid functions via cctk_lsh. Grid arrays are
still declared independently.
This reduces the code size of e.g. GRHydro/GRHydro_Tmunu.F90 from 6836 to
6241 bytes on my system. I have not attempted to measure a performance
difference.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/235>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#458: Improve bboxset efficiency (e.g. for regridding)
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner: eschnett
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Carpet | Version:
Keywords: |
-------------------------+--------------------------------------------------
The attached patch modifies the algorithm used to insert a new bbox into
an existing bboxset. It reduces the computational complexity of this
operation from O(n^2) to O(n), where n is the number of elements in the
bboxset. This has the potential to speed up regridding significantly.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/458>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#329: SimFactory/ranger-intel11.cfg: Are BLAS and LAPACK compilations on Ranger
optimized?
-------------------------+--------------------------------------------------
Reporter: bmundim | Owner: mthomas
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
ranger-intel11.cfg now sets BLAS and LAPACK to be built along with the
Cactus and other external libraries. Usually the host system BLAS and
LAPACK are fine tuned to
take advantage of the particular memory hierarchy of the host machine. I
was wondering if this fine tuning is performed when we set BLAS = BUILD or
LAPACK = BUILD, and, in case it is not, if it would be interesting to
define Cactus env variables to set the size of the several cache memories
for example and use it for this necessary fine tuning.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/329>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#271: python simfactory submit creates only the SubmitScript
----------------------------------------------+-----------------------------
Reporter: alexander.beck-ratzka@… | Type: defect
Status: new | Priority: major
Milestone: | Component: Other
Version: | Keywords: simfactory submit
----------------------------------------------+-----------------------------
The python version of simfactory submit creates only the submitScript
called PreparedSubmitScript. The RunScript is created at the moment of the
simfactory run call at the end of the SubmitScript.
So a user has no possibilty to check whether his settings e.g. for mpirun
have been correct or not for all the time where the job is only queued. I
feel this is not a user friendly solution. The RunScript should be created
together with the SubmitScript.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/271>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#326: Update gsl path in Ranger option file to gsl 1.13
---------------------------------------------+------------------------------
Reporter: bmundim | Owner: mthomas
Type: task | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: Ranger option configuration gsl |
---------------------------------------------+------------------------------
Ranger config file has been updated recently, so I thought to bring to
your attention that gsl library on Ranger now defaults to version 1.13.
Cheers,
Bruno.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/326>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#327: Simfactory: ranger-intel11.run question.
------------------------+---------------------------------------------------
Reporter: bmundim | Owner: mthomas
Type: defect | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
Shouldn't we load intel/11.1 there, since the default on Ranger is
intel/10.1?
Also unless "module load intel/11.1" is in your .login_user, it will fail
to "module load mvapich" since no compiler has been selected.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/327>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit