#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
#472: Correct scheduling of TmunuBase's SetTmunu
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Other | Version:
Keywords: |
----------------------+-----------------------------------------------------
I notice that TmunuBase doesn't schedule the group SetTmunu often enough.
In particular, it is not scheduled after recovery, and it's scheduling at
evol is also questionable. I also notice that GRHydro "fixes" this by
scheduling SetTmunu by itself. This needs to be cleaned up.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/472>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#480: Problem with determining host name in SimFactory 1
------------------------+---------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
On the new Scientific Linux 6 installation at the AEI, SimFactory 1 thinks
that the local machine is called localhost.localdomain:
$ simfactory/sim build --thornlist WaveToy.th --optionlist damiana_sl6.cfg
Simulation Factory:
Configuration name(s) not specified -- using default configuration "sim"
Uncaught exception from user code:
Unknown machine name "localhost.localdomain" at simfactory/sim
line 5061.
at simfactory/sim line 5061
main::get_machine('') called at simfactory/sim line 1498
main::command_build() called at simfactory/sim line 454
Looking at the code for get_hostnamealias, it appears to look for all the
host name aliases of the current machine and select the first one in the
returned list which contains a dot. On the workstation in question, I
get:
[ianhin@sl-18 ~]$ hostname -a
localhost.localdomain localhost localhost6.localdomain6 localhost6 sl-18
sl-18.damiana.admin
which explains the behaviour. My first reaction would be to filter the
list to remove all the "local" aliases. This might break peoples'
existing setup. I have seen mailing list posts which indicate that people
use localhost as their machine name in simfactory. Since SimFactory 1 is
approaching end-of-life, it might just be better to say that you need to
use the --hostname option directly if you run into this problem, rather
than breaking peoples' existing workflow. Thoughts?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/480>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#147: Write transition guide for EOS_Omni
-------------------------------------+--------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit website | Version:
Keywords: |
-------------------------------------+--------------------------------------
The Einstein Toolkit pages need a wiki tutorial for switching to EOS_Omni.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/147>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#162: Document CCTK_GFINDEX3D and friends in reference manual
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
I believe the reference manual does not describe any of the CCTK_GFINDEX*
and CCTK_VECTGFINDEX* functions.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/162>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#367: When a repo URL changes, GetComponents should offer more help
---------------------------+------------------------------------------------
Reporter: eschnett | Owner: eric9
Type: enhancement | Status: new
Priority: major | Milestone:
Component: GetComponents | Version:
Keywords: |
---------------------------+------------------------------------------------
When a repo URL changes, GetComponents currently suggests to check out the
repo from scratch (and presumably delete/ignore the old repo). This is
very inflexible, in particular when the user has changes in the old
repository, which often happens during development.
SVN (and presumably all other VC software) offer commands to update the
URL, so that one can keep the current checkout. Of course, this makes only
sense if this is the same repository that only moved to a new URL, but
this seems to happen often enough.
GetComponents should at least output instructions for updating the URL.
It would be even better if GetComponents detected that new and old repo
are the same, and then update the repo URL by itself.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/367>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#414: --parallel option not documented in GetComponents
---------------------------+------------------------------------------------
Reporter: bmundim | Owner: eric9
Type: defect | Status: new
Priority: minor | Milestone:
Component: GetComponents | Version:
Keywords: |
---------------------------+------------------------------------------------
The --parallel option is not documented in both versions of GetComponents,
the released and development ones.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/414>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit