#2203: accumulated Carpet updates
-------------------------+---------------------------------
Reporter: Roland Haas | Owner: Roland Haas
Type: defect | Status: assigned
Priority: minor | Milestone:
Component: Carpet | Version: development version
Keywords: |
-------------------------+---------------------------------
Pull requests https://bitbucket.org/eschnett/carpet/pull-requests/22
/rhaas-carpetupdates/diff https://bitbucket.org/cactuscode/cactus/pull-
requests/53/rhaas-updates/diff https://bitbucket.org/cactuscode/cactuspugh
/pull-requests/3/pugh-initialize-new-cgh-fields/diff contain accumulated
updates to Carpet, Cactus and PUGH in the funhpc branches.
I have verified that the three pull requests produce bit-identical output
for the qc0-mclachlan.par parfile using 5 MPI ranks and 2 threads per rank
on my workstation (debian-buster, gcc 8.2).
A summary of changes:
* add support for very large grids where 64bit integer are needed for grid
indices and sizes of transfer buffers
* fix how how physical_time_per_hour is computed
* add functionality to align interior of grid functions to cache
boundaries. This requires changes to Cactus and PUGH as well.
* add a parameter "granularity" to make sure the interior of components is
a multiple of N points in each direction
* always align data if VECTORISE_ALIGN_FOR_CACHE is set in option list
indep. of pad_to_cachelines runtime parameter
* cleanup, reformatting, minor speedups
To compare the changes it is not advisable to look at the diff directly.
It is much better to run both the current and the new version through
clang-format first:
{{{
cd repos/carpet
git checkout master
git checkout -b master-formatted
clang-format -style=file -i */src/*.{cc,hh}
git commit -a -m 'Beautify code'
git checkout rhaas/carpetUpdates
git checkout -b rhaas/carpetUpdates-formatted
clang-format -style=file -i */src/*.{cc,hh}
git commit -a -m 'Beautify code'
git diff master-formatted..rhaas/carpetUpdates-formatted
}}}
which is more manageable (but still multiple thousands of lines)
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2203>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2104: Support NixOS
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: unset | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
NixOS is a new Linux-based distribution. To make things work, a few small
changes are necessary.
https://bitbucket.org/cactuscode/cactus/pull-requests/46/flesh-support-
nixos/diff
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2104>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2206: make LORENE2 the default LORENE in the ET
---------------------------------+-----------------------------------
Reporter: Roland Haas | Type: enhancement
Status: new | Priority: minor
Milestone: | Component: EinsteinToolkit thorn
Version: development version | Keywords:
---------------------------------+-----------------------------------
We are currently shipping two versions of LORENE with the ET:
* ExternalLibraries/LORENE
* ExternalLibraries/LORENE2
which are different snapshots of LORENE which produce / read incompatible
binary blobs as data files for the produced initial data. See
ticket:1817#comment:28 .
Frank used to spearhead this effort (with me arguing for a new name to
keep backwards compatibility).
By now LORENE2 should be made the default code used and LORENE the one
downloaded but not compiled in (they cannot both be compiled due to linker
conflicts).
This has become a bit more urgent since Debian (and hence Ubuntu soon) are
including LORENE in the version from cvs20161116 in their stable release
(stretch): https://packages.debian.org/stretch/liblorene-dev
CVS being what it is (and us not knowing which commit caused the change in
binary format in the first place) it is not clear whether this is what the
ET calls LORENE or LORENE2, but my guess would be it is LORENE2.
Ideally there would be a one release warning before this happens,
unfortunately the release announcement mentioning LORENE2 does not do so:
https://www.einsteintoolkit.org/about/releases/ET_2017_06_announcement.html
Having a LORENE copy present would speed up compilation a bit and is
already being proposed on the wiki: https://docs.einsteintoolkit.org/et-
docs/Simplified_Tutorial_for_New_Users#Speed_up_installation_by_using_native_packages
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2206>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2200: some test may be non-deterministic
---------------------------------+--------------------
Reporter: Roland Haas | Type: defect
Status: new | Priority: unset
Milestone: | Component: Other
Version: development version | Keywords:
---------------------------------+--------------------
For the ET_2018_09 release it seems that tests run on Sep 6th and Sept
22nd differ and these tests show a different number of failed tests:
* comet__1_24.log
* cori__1_16.log
* osx-homebrew__2_2.log
* osx-macports__2_2.log
and given that there should not have been a change in code between those
days this seems suspicious.
The particular tests that changed are:
{{{
+++ b/results/comet__1_24.log
@@ -1434,7 +1434,7 @@
AHFinderDirect: misner1.2-025
Success: 55 files compared, 9 differ in the last digits
AHFinderDirect: recoverML-EE
- Success: 5 files compared, 5 differ in the last digits
+ Failure: 2 files missing, 3 files compared, 3 differ, 3 differ
significantly
Carpet: 64k2
Success: 0 files identical
Carpet: test_restrict_sync
}}}
{{{
+++ b/results/cori__1_16.log
@@ -1446,7 +1446,7 @@
CarpetIOHDF5: CarpetWaveToyNewRecover_test_1proc
Success: 12 files compared, 7 differ in the last digits
CarpetIOHDF5: CarpetWaveToyRecover_test_1proc
- Failure: 12 files missing, 0 files compared, 0 differ
+ Success: 12 files compared, 7 differ in the last digits
CarpetIOHDF5: CarpetWaveToyRecover_test_newcp_1proc
Success: 12 files compared, 7 differ in the last digits
CarpetIOHDF5: newsep
}}}
{{{
+++ b/results/osx-homebrew__2_2.log
@@ -1631,7 +1631,7 @@
PeriodicCarpet: testperiodicinterp
Success: 1 files identical
QuasiLocalMeasures: qlm-bl
- Failure: 54 files missing, 115 files compared, 115 differ
+ Success: 169 files compared, 143 differ in the last digits
QuasiLocalMeasures: qlm-ks
Success: 169 files compared, 138 differ in the last digits
QuasiLocalMeasures: qlm-ks-EE
}}}
{{{
+++ b/results/osx-macports__2_2.log
@@ -1631,7 +1631,7 @@
PeriodicCarpet: testperiodicinterp
Success: 1 files identical
QuasiLocalMeasures: qlm-bl
- Failure: 54 files missing, 115 files compared, 115 differ
+ Success: 169 files compared, 144 differ in the last digits
QuasiLocalMeasures: qlm-ks
Success: 169 files compared, 136 differ in the last digits
QuasiLocalMeasures: qlm-ks-EE
}}}
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2200>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2176: Test "Binary neutron star" example
-------------------------------------+---------------------------------
Reporter: Roland Haas | Owner: Peter Diener
Type: task | Status: assigned
Priority: major | Milestone: ET_2018_08
Component: EinsteinToolkit website | Version: development version
Keywords: |
-------------------------------------+---------------------------------
Before each release, check that
http://einsteintoolkit.org/gallery/bns/index.html still works and produces
correct output.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2176>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2205: hwloc in OpenMPI self-built code uses CUDA and OpenCL
---------------------------------+-----------------------------------
Reporter: Roland Haas | Type: defect
Status: new | Priority: major
Milestone: | Component: EinsteinToolkit thorn
Version: development version | Keywords: MPI
---------------------------------+-----------------------------------
This causes problems since we do not then link against CUDA or OpenCL.
This happens even if one passes the {{{--with-cuda=no}}} option to
OpenMPI's configure script.
Possibly one has to follow the fix in OpenMPI's 2.x and 3.x branches to
fix this: https://github.com/open-mpi/ompi/issues/4248
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2205>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2165: Cactus: output actual path to config-info on failure
---------------------------------+-------------------------
Reporter: Roland Haas | Type: enhancement
Status: new | Priority: minor
Milestone: | Component: Cactus
Version: development version | Keywords:
---------------------------------+-------------------------
Pull request is here:
https://bitbucket.org/cactuscode/cactus/pull-requests/51/cactus-output-
actual-path-to-config-info/diff
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2165>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2151: thorn NSTracker cannot track unequal mass neutron star systems
---------------------------------+-------------------------
Reporter: Roland Haas | Type: enhancement
Status: new | Priority: optional
Milestone: | Component: Other
Version: development version | Keywords: NSTracker
---------------------------------+-------------------------
NSTracker makes the hard-coded assumption that if there are two NS then
one is at (x,y,z) and the other one at (-x,-y,z).
It (and the code in Hydro_Analysis) should support an arbitrary number of
NS with arbitrary symmetries imposed.
Note that NSTracker is not part of the ET but used by one of the gallery
examples.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2151>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2126: SimFactory should choose an appropriate cfg on a Mac.
------------------------+---------------------------------------------------
Reporter: sbrandt | Owner:
Type: defect | Status: new
Priority: unset | Milestone: ET_2018_08
Component: SimFactory | Version: development version
Keywords: |
------------------------+---------------------------------------------------
generic.cfg does not work on a mac because gcc doesn't exist (one needs to
use gcc-7 instead, for example). Simfactory should detect and use the
correct cfg file from the set generic.cfg, osx-homebrew.cfg, and osx-
macports.cfg.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2126>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2199: Cleanup Distros
---------------------------------+------------------------
Reporter: Steven R. Brandt | Type: defect
Status: new | Priority: unset
Milestone: | Component: SimFactory
Version: development version | Keywords:
---------------------------------+------------------------
Get rid of obsolete/problematic configs: centos.cfg, debian.cfg, etc.
Branch: cleanupdistros
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2199>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit