#1983: Multipole: ouput all hdf5 modes at once
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: Multipole |
-----------------------------------+----------------------------------------
This change reduces the number of times the same file is opened and closed
from once per mode and radius to once per output iteration.
This is very beneficial on clusters with slow metadata performance (which
currently means all "big" clusters that run lustre).
Pull request is:
https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-requests/5
/multipole-ouput-all-hdf5-modes-at-once/diff
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1983>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1771: Improve performance of CarpetInterp2 interpolation
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
The branch
https://bitbucket.org/eschnett/carpet/branch/ianhinder/fasterp_opt#diff
contains an optimisation to the CarpetInterp2 interpolation routine which
improved the performance of Llama interpatch interpolation in my test by a
factor of 5. I did this a while ago, and haven't looked at it recently.
Before merging, the following should be done:
1. Check that is applies cleanly to the current version of Carpet
2. Decide whether the vectorisation pragmas need to be protected by Cactus
preprocessor guards
Or any other changes which people think might be necessary.
This should wait until after the upcoming (May 2015) release of the ET.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1771>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1801: Certificate for svn.cct.lsu.edu not trusted
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: Other | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
I just tried to check out the ET Hilbert release on my OSX laptop (OSX
10.10.4, subversion version 1.7.19) and get for the LSUThorns:
--8<--
Could not checkout module LSUThorns/SummationByParts
svn: E175002: Unable to connect to a repository at URL
'https://svn.cct.lsu.edu/repos/numrel/LSUThorns/SummationByParts/branches/ET…'
svn: E175002: OPTIONS of
'https://svn.cct.lsu.edu/repos/numrel/LSUThorns/SummationByParts/branches/ET…':
Server certificate verification failed: issuer is not trusted
(https://svn.cct.lsu.edu)
--8<--
https://www.sslshopper.com/ssl-checker.html#hostname=https://svn.cct.lsu.edu reports the certificate to
be ok though (with the exception of it using SHA1 as a hash).
Doing a manual svn checkout
https://svn.cct.lsu.edu/repos/numrel/LSUThorns/QuasiLocalMeasures/branches/…
asks me whether I would want to trust the certificate.
1. I thought the LSU certificates were trusted by common OS by default by
now (and OSX is certainly common)
2. I thought we had special code in GetComponents to make it automatically
not try and verify signatures because of this
3. this is really becoming a nuisance (if indeed caused by an uncommon
certificate issuer and not by something odd on my laptop) :-)
{{{
openssl ssl_client -connect svn.cct.lsu.edu:443 </dev/null >ssl.out
}}}
reports a self-signed certficate though this may well be the untrusted
certificate.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1801>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2002: include jacobi cluster at UWM
-------------------------+--------------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: SimFactory | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Jacobi is a private cluster (10 nodes, 80 cores) at the physics department
at UWM. It is currently being used to debug and run some simulations.
Pull request is at https://bitbucket.org/simfactory/simfactory2/pull-
requests/15/jacobi-uwm-add-new-machine-at-uwm/diff
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2002>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1743: Reduce number of output files per directory
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: Other | Version: development version
Keywords: |
----------------------+-----------------------------------------------------
Reduce the number of output files per directory in CarpetIOHDF5 by
creating a hierarchy of subdirectories.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1743>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1819: CarpetMask: add option to exclude boxes
-------------------------------------+--------------------------------------
Reporter: bmundim | Owner: eschnett
Type: enhancement | Status: new
Priority: unset | Milestone:
Component: Carpet | Version: development version
Keywords: CarpetMask CarpetReduce |
-------------------------------------+--------------------------------------
I would like to be able to exclude boxes in addition to spherical surfaces
when setting the CarpetMask::weight (which is used by CarpetReduce to
exclude regions when performing
reductions). The following pull request implements this functionality:
{{{
https://bitbucket.org/eschnett/carpet/pull-requests/5/bcm-carpetmask/diff
}}}
I have some parameter files I used to test my implementation. I can turn
them into testsuites after the revision of this ticket.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1819>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1987: QuasyLocalMeasures: Speed up building with gfortran
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
Speed up gfortran builds by splitting expensive routines into two,
separating compute kernels from boundary condition calls.
See <https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-
requests/6/quasylocalmeasures-speed-up-building-with/diff>.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1987>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1997: Backport several simfactory commits to ET_2016_11
----------------------+-----------------------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version: development version
Keywords: backport |
----------------------+-----------------------------------------------------
Several simfactory commits should be backported to ET_2016_11. These are:
{{{
* a02707c - (HEAD, origin/master) fedora: add hdf5_hl to HDF5_LIB for
PITTNullCode/SphericalHarmonicRecon (2016-12-12) <Roland Haas>
* ce1ee9b - fedora: explicitly install python2 since python3 is the
default in FC25 (2016-12-12) <Roland Haas>
* 72518a0 - minerva: update cluster name (2016-12-12) <Roland Haas>
}}}
Some other commits relating to jacobi-uwm may also be candidates for
backport. Roland?
There should then be an ET_2016_11_v1 release tag created, unless someone
feels that we may have more commits to backport soon.
OK?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1997>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit