#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
#508: list-simulations displays job ID when it doesn't make any sense
------------------------+---------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
The list-simulations command displays a restart number and job ID even for
simulations for which there is no job in the queue. The attached patch
omits these in that case.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/508>
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
#545: Use ssh ProxyCommand instead of multiple ssh commands
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner: eschnett
Type: enhancement | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
This would simplify quoting, thus also simplify the screen output, and may
speed up things on remote connections.
Here is an example:
ssh -Y -o ProxyCommand='ssh eschnetter(a)mars.perimeterinstitute.ca nc -w 1
curry.pi.local 22' eschnett(a)curry.pi.local
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/545>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#544: Enable optimisation in Fortran array index calculations
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
In Fortran, Cactus passes all grid functions as arguments to routines,
and the size of the grid functions are declared in
DECLARE_CCTK_ARGUMENTS. In these declarations, Cactus assumes that the
size of each grid variable group can be different, and the compiler
thus does not see that all grid functions have (locally) the same
array shape. The compiler can thus not simplify array index
calculations. This is probably only relevant in short loops accessing
grid functions from multiple groups (GRHydro?).
The attached patch passes three additional integer arguments
(cctk_lsh[123]) which contain the shape of grid functions, and uses
these to declare grid functions.
This patch is quite old, but was never applied. It comes from a time
when g77 didn't support declaring array shapes via an integer array
(since this is not allowed in Fortran 77). If this is now possible,
one could use the array cctk_lsh instead of passing three extra
integer arguments.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/544>
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