#1906: CarpetRegrid2: possible off-by-one error when using regrid_every parameter
---------------------------+------------------------------------------------
Reporter: bmundim | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version: development version
Keywords: CarpetRegrid2 |
---------------------------+------------------------------------------------
I was working on a par file for a quick regridding test and found out an
unexpected behaviour regarding regridding. Basically I want a par file
with a few iterations such that it adds a refinement level every 4
iterations for example. I set the following parameters then:
{{{
CarpetRegrid2::add_levels_automatically = "yes"
CarpetRegrid2::regrid_every = 4
}}}
for a grid structure as such:
{{{
Cactus::cctk_itlast = 10
CoordBase::xmin = -0.5
CoordBase::ymin = -0.5
CoordBase::zmin = -0.5
CoordBase::xmax = 0.5
CoordBase::ymax = 0.5
CoordBase::zmax = 0.5
CoordBase::ncells_x = 16
CoordBase::ncells_y = 16
CoordBase::ncells_z = 16
Carpet::max_refinement_levels = 3
CarpetRegrid2::num_centres = 1
CarpetRegrid2::active_1 = "yes"
CarpetRegrid2::num_levels_1 = 1
CarpetRegrid2::radius_1[1] = 0.12
CarpetRegrid2::radius_1[2] = 0.04
}}}
I was expecting then regridding to happen at iterations 4 and 8, however
if you run the attached par file, a modification of balsara shocktube
test, you see that the level additions actually happen at iterations 5 and
9 instead:
{{{
...
INFO (CarpetRegrid2): Increasing number of levels of centre 1 to 2 (it=5)
...
INFO (CarpetRegrid2): Increasing number of levels of centre 1 to 3 (it=9)
}}}
which is apparently an off-by-one kind of error. I tracked down the code
producing these messages and it comes from function
CarpetRegrid2_RegridMaps at CarpetRegrid2/src/regrid.cc, lines 745 to 747.
In order for that piece of code to execute we do have to have do_recompose
set to true. Strangely the condition to set it, compares the previous
iteration to the regrid_every parameter on line 707 of the same file:
{{{
(cctk_iteration - 1) % regrid_every == 0
}}}
Investigating if this actually makes sense I was led to what I think it
might be the source of the problem on line 58 of Carpet/src/Evolve.cc.
Time and iteration is advanced before calling CallRegrid. Skimming over
the AdvanceTime routine it is not clear to me that it really needs to be
called before CallRegrid. If it is really needed then why the condition to
regrid or not is not taken on the current updated iteration as in:
{{{
cctk_iteration % regrid_every == 0
}}}
Thanks,
Bruno
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1906>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1778: Scheduling WHILE Loops in CCTK_ANALYSIS Results in Hang
--------------------------------+-------------------------------------------
Reporter: zachetie@… | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: Other | Version: ET_2015_05
Keywords: |
--------------------------------+-------------------------------------------
When encountering a WHILE loop inside CCTK_ANALYSIS, Cactus simply hangs.
I have created a simple thorn, ScheduleTester, that reproduces this
problem 100% of the time. The thorn only takes as input the number of
iterations desired in the WHILE loop. I have attached this thorn, as well
as example .par and ThornList files to this ticket.
This problem is verified to exist within 2015_05 as well as 2014_11 ET
releases. I have not tried past releases.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1778>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1992: provide bibtext snippets for requested cittations on ET website
----------------------------+-----------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus website | Version: development version
Keywords: |
----------------------------+-----------------------------------------------
Our citing page http://einsteintoolkit.org/documentation/licenses/ right
now lists the bibtex key and the doi for the requested citations. It would
be useful to make the bibtex keys hyperlinks to a bibtex fragment for the
paper in question that could be copied and pasted into a user's bibtext
file. If we don't want to use the fragment from our own
einsteintoolkit.bib we could use INSPIRE's doe search facility using
"bibtex" as the output format, eg:
http://inspirehep.net/search?ln=en&ln=en&p=doi%3A10.1088%2F0264-9381%2F21%2…
for the Carpet reference.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1992>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2025: ssl warning for wiki.einsteintoolkit.org
-------------------------------------+--------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit website | Version: development version
Keywords: |
-------------------------------------+--------------------------------------
My browser (Firefox 45.8.0 ESR) reports
{{{
wiki.einsteintoolkit.org uses an invalid security certificate. The
certificate is only valid for wiki.cct.lsu.edu Error code:
SSL_ERROR_BAD_CERT_DOMAIN
}}}
for https://wiki.einsteintoolkit.org/
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2025>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#502: SimFactory user-guide should be available and updated automatically
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: knarf
Type: enhancement | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
SimFactory has an incomplete user guide in the doc/userguide directory.
This is developed using Sphinx, which is a Python framework for writing
documentation. You need to install sphinx to generate this documentation.
This can be done using something similar to the following:
export PYTHONPATH=/home/ianhin/software/python
export PATH=/home/ianhin/software/python/:$PATH
hash -r
easy_install --install-dir ~/software/python sphinx
Then go into the simfactory/doc/userguide directory and type:
./autogen
make html
to generate HTML documentation (type just "make" to see the other possible
targets like PDF etc).
This should be regenerated on any commit to the SimFactory/doc/userguide
directory and copied to a web-accessible location for inclusion on
simfactory.org.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/502>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1698: The ET tickets should be tidied up
----------------------------------+-----------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit trac | Version: development version
Keywords: |
----------------------------------+-----------------------------------------
Many of the ET tickets have not seen much attention recently or at all.
We should have a session where we run though all the tickets and make sure
that their priorities/state etc are correct. Once we have done this, we
should come up with a strategy for keeping the tickets under control. In
the process, we should decide what is meant by the different ticket
priorities, and whether we need to add additional priorities or states to
allow us to more effectively manage the tickets.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1698>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#719: Mailing lists could have a link to the archived version of the message
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Other | Version:
Keywords: |
-------------------------+--------------------------------------------------
It would be useful for the footer of a mailing list posting to contain a
URL to the archived version of the message so that it is easy to point
people to the message in an email. This would apply to both the Cactus
and the ET lists.
It appears that this is not straightforward in MailMan 2, but is expected
in version 3: http://mail.python.org/pipermail/mailman-
users/2011-October/072378.html.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/719>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1471: Cactus should auto-detect newer versions of GCC from MacPorts
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Currently, during Cactus configuration without an optionlist on Mac OS, I
get
{{{
checking for gcc-mp-4.4... no
checking for gcc-mp-4.3... no
checking for gcc-mp-4.2... no
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
}}}
I have gcc-mp-4.6, and 4.7 and 4.8 are also available in macports. The
configure script should be updated to detect these versions.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1471>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1170: ExtrenalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS
incosistently
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: ExternalLibraries |
-----------------------------------+----------------------------------------
This is a companion ticket to #1006.
Different thorns (eg. MPI and HDF5 and LAPACK) handle XXX_DIR and
XXX_INC_DIRS etc differently. MPI for example sets the include path to
$MPI_DIR/include if MPI_INC_DIRS is not explicitly set and to MPI_INC_DIRS
if it is set. HDF5 has no HDF5_INC_DIRS option and always sets the include
path to HDF5_DIR/include. LAPACK has not INC_DIRS option and sets the
linker path to LAPACK_DIR while the other two thorns set it to XXX_DIR/lib
(unless overridden by MPI_LIB_DIRS in the case of MPI).
I would be good to present a uniform set of option for all these thorns.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1170>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1769: External libraries: moving towards multiarch library directory structure
----------------------------------------------+-----------------------------
Reporter: bmundim | Owner:
Type: defect | Status: new
Priority: major | Milestone: ET_2015_05
Component: EinsteinToolkit thorn | Version: development version
Keywords: ExternalLibraries HDF5 Multiarch |
----------------------------------------------+-----------------------------
Several Linux distributions have already started to move their libraries
to a new directory structure that reflects the target architecture and
allows the installation of packages from multiple architectures in the
same system. The following links provide more details of this change:
{{{
https://wiki.debian.org/Multiarch/TheCaseForMultiarchhttps://wiki.ubuntu.com/MultiarchSpec
}}}
This change potentially affects several of external library scripts
shipped with ET. For example the HDF5/src/detect.sh script is not able to
detect the hdf5 libraries installed in the directory /usr/lib/x86_64
-linux-gnu for Ubuntu 14.04.2 LTS.
I have attached a simple patch to remedy this issue and open a discussion
on the best way to proceed here. This patch does depend on the
availability of gcc on the system. It currently works fine for me, but we
might need a better solution for systems without gcc.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1769>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1474: compile ExternalLibraries with other thorns rather than when CST runs
-------------------------+--------------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Compiling external libraries takes a long time by now. Currently this
happens very early in the compilation phase, before the other thorns are
compiled.
It would be better if the compilation happened at the same time as that of
other thorns.
This will entail splitting the configuration ie. detecting whether to
build the included source or use a system wide copy from the compilation,
most likely either using Cactus makefile variables or temporary files to
transfer the decisions from the configuration stage to the build stage.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1474>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1946: sim setup should create a section for the current machine
-------------------------+--------------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
When calling sim setup on a machine in the machine data base (eg
bluewaters in my case) it it still creates only a {{{[default]}}} section
in defs.local.ini which means that the account information and possibly
non-default sourcebasedir are not used for bluewaters leading to hard to
understand error messages later on.
I would thus like to suggest to change sim setup such that instead (or in
addition to) a "[default]" section it creates a section for the detected
machine if it already knows this machine.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1946>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2050: cctk_startupxxx is a valid group
---------------------+------------------------------------------------------
Reporter: sbrandt | Owner: sbrandt
Type: defect | Status: new
Priority: unset | Milestone:
Component: Other | Version: development version
Keywords: |
---------------------+------------------------------------------------------
Currently, the "at" keyword in the schedule.ccl file is supposed to report
an error if one is scheduling in a group that is not present at startup.
It detects this with a regexp, but the regexp does not include boundaries.
As such cctk_startupxxx is considered valid.
In addition, the new parser is failing to report a CST error for this
violation regardless of group name.
The attached patch to the schedule parser fixes both defects.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2050>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2077: include RNSID in ET
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: Hydro_RNSID |
-----------------------------------+----------------------------------------
Pull request is here:
https://bitbucket.org/einsteintoolkit/einsteininitialdata/pull-requests/3
/new-initial-data-thorn-for-grhydro/diff
It generate ID for rotating star either with uniform rotational
profile or describe by differentialy rotating j-law.
testsuite par file provided and tested
example of usage parfile in par subdirectory as perl script that
generate par file with resolution dx=0.75 suited for workstation tests.
Hydro_RNSID/par/speed.rpar generate par file usefull to peform
speed test
two stand alone utility are generate at compile time to [RNS]
generate initial models (to be imported in Cactus) amd to read [RNS_read]
the generated initial model
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2077>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1911: Hydro_InitExcision sphere_pugh_ppm test fails
---------------------------+------------------------------------------------
Reporter: barry.wardell | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: Other | Version: development version
Keywords: |
---------------------------+------------------------------------------------
The Hydro_InitExcision sphere_pugh_ppm test fails for me when run on 1
process on an Ubuntu 16.04 machine. The diffs are attached.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1911>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2027: testsuite page is not avaiable on website
-------------------------------------+--------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit website | Version: development version
Keywords: |
-------------------------------------+--------------------------------------
The testsuite overview page
http://einsteintoolkit.org/release-info/parse_testsuite_results.php
does not currently work (since the website changed).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2027>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1995: McLachlan constraint tests fail
---------------------------------------------------------------+------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: major | Milestone: ET_2016_11
Component: EinsteinToolkit thorn | Version: development version
Keywords: McLachlan constraints tests compiler optimization |
---------------------------------------------------------------+------------
Several tests fail on several machines, and the cause seems to be the
constraints calculated by McLachlan. Peter is looking into this. We see
test failures in the thorns Dissipation and RotatingSymmetry90/180.
Indications are that most failures happen with Intel 15, but some are
apparently also seen with Intel 16, while others with Intel 16 seem to
work fine. Optimization -O1 instead of -O2 seems to prevent the problem,
but is not a viable workaround. A simple 'print' statement in the affected
(auto-generated) code also makes the problem disappear. Running using one
MPI process and one openMP thread reproduces the problem. valgrind does
not find anything obvious pointing to memory mess-up.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1995>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2078: thorn vectors fails if vectorizatin is disabled
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: Vectors |
-----------------------------------+----------------------------------------
At least in one case (gcc 7.2) thorn Vectors seems to fail with a message
that overloading is not allowed in line 671 of vectors.h
{{{
explicit constexpr vectype(scalar_t const &a) : v(props::set1(a)) {}
}}}
if vectorization is disabled (VECTORISE=no). My guess would be that in
this case scalar_t and vector_t are the same and a conflict exists (or
some other assumption is violated).
I'll provide more details once I have a a nicer testcase.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2078>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2080: Backports for the June 2017 release to compile on the NDS machine
-------------------------+--------------------------------------------------
Reporter: sbrandt | Owner:
Type: enhancement | Status: new
Priority: critical | Milestone:
Component: Other | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
I would like to backport the following files from master to the June 6th
release of the ET. The files are
repos/simfactory2:
bin/sim
mdb/machines/jupyteret.ini
mdb/optionlists/generic.cfg
mdb/runscripts/generic.run
Also, a small modification to the PAPI thorn:
{{{
Index: src/detect.sh
===================================================================
--- src/detect.sh (revision 42)
+++ src/detect.sh (working copy)
@@ -27,7 +27,7 @@
# libraries might have different file extensions
for libext in a dll dll.a dylib lib so; do
# libraries can be in lib or lib64 (or libx32?)
- for libdir in lib64 lib; do
+ for libdir in lib64 lib lib/x86_64-linux-gnu; do
# These files must exist
FILES="include/papi.h ${libdir}/libpapi.${libext}"
# assume this is the one and check all needed files
}}}
With these changes, the ET builds on the NDS machine. Moreover, it should
more easily build on machines which have no explicit entry in Simfactory.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2080>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2029: GW150914 example should be updated to work with the Einstein Toolkit
thornlist
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: Other | Version: development version
Keywords: gallery |
-------------------------+--------------------------------------------------
The GW150914 example currently uses its own thornlist, because Llama was
not part of the ET when it was created. Llama has now been added to the
ET. The GW150914 thornlist uses WaveExtractCPM and ADMConstraints. These
can probably be removed, for the sake of having a parameter file which
works with the ET thornlist. ADMConstraints can be replaced with
ML_ADMConstraints. WaveExtractCPM is an "in-development" code which has
not been extensively tested. It gives the GW strain directly from
Schwarzschild perturbation theory, without needing to go via fixed-
frequency integration of Psi4, so is good for quick plots. However, it
seems to give worse results than Psi4 for the ringdown, and possibly has
bugs in some of the l > 2 modes, so I don't think it is ready for
inclusion in the toolkit just yet.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2029>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2083: ET workbench signup broken for Safari
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version: development version
Keywords: ETWorkbench |
-------------------------+--------------------------------------------------
When trying to sign up for the ET workbench
(https://www.einsteintoolkit.nationaldataservice.org/#/register) using
Safari 9.1.3, the bottom of the page containing the "Request Access"
button is obscured by the gray box with "all rights reserved" ... "UI",
"API" etc. See attached screen grab.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2083>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1725: Disable Fortran 77 support in Cactus
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: unset | Milestone:
Component: Other | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
There are no "Fortran 77" compilers any more. Cactus currently
distinguishes between FCODE and F90CODE (pure Fortran 77, and Fortran 90).
The pure Fortran 77 code has less argument checking etc. and is less safe,
and is not needed any more. It should be removed, both from the makefile
system as well as from the CST that auto-generates code.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1725>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2021: compiling Carpet fails with intel 17 and optimisation
-----------------------------------------+----------------------------------
Reporter: wolfgang.kastaun@… | Owner: eschnett
Type: defect | Status: new
Priority: unset | Milestone:
Component: Carpet | Version:
Keywords: |
-----------------------------------------+----------------------------------
Compiling carpet with intel 17.0.1 and -O2 or -O3 triggers an internal
compiler error ("internal error: 0_76"). It only affects the file bbox.cc.
Happened on two different clusters. ET version is Payne.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2021>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit