#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
#394: Testsuite log file should contain more information
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: testsuites |
-------------------------+--------------------------------------------------
It is useful to look at the testsuite log file for information about how
the tests were run. For example, which compiler was used, and with what
compiler options. We need to balance this against providing information
which will always change, making diffs hard to read.
The most extreme case would be to output all make variables. Maybe better
would be to output CC, CFLAGS, CXX, etc. Another option would be to parse
these and say "intel compiler", "gcc", "pgi" etc.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/394>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1717: hwloc: lnuma & lltdl *really* required?
-----------------------------------+----------------------------------------
Reporter: zachetie@… | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
I downloaded the ET devel version (ca. Nov 26) on my (ubuntu) laptop and
compiled it, using gcc.
I compiled to the linker stage, and the linker complained:
ld: cannot find -lnuma
ld: cannot find -lltdl
I found references to these libraries in:
configs/[buildname]/bindings/Configuration/Capabilities/make.HWLOC.defn
After removing these references, the code compiled and seemed (on the
surface) to run okay. Are these libraries really necessary?
I ask because every time I need to install ET on a new machine, it would
be more convenient if the step "apt-get install libnuma-dev libltdl-dev"
were left out, particularly since reliable Internet access may not exist
at that time.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1717>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1656: CarpetInterp and MoL do not work properly together
--------------------+-------------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
I am trying to integrate interpolated quantities using MoL. I call the
interpolator in MoL_CalcRHS, and want it to perform only a spatial
interpolation of the current content of timelevel 0. This current content
is what has been set by MoL; it is not the final value that will be at
t_{n+1} or was at t_N, but is the intermediate value that should be used
when computing the RHS at a given MoL substep. Since MoL does not set the
Carpet time hierarchy values, CarpetInterp seems to get confused about how
to do the interpolation. I need to tell CarpetInterp not to interpolate
in time at all, but to use timelevel 0 only. Unfortunately, setting the
interpolator option to use only one timelevel does not work. There is
commented-out code to "use cctk_time to decide whether to interpolate",
which essentially guarantees that no time interpolation will happen (since
the interpolation is requested for cctk_time, and the current time is
cctk_time, so they are always equal). Re-enabling this code allowed me to
achieve 4th order convergence for integrated interpolated quantities,
though I am not sure I understand everything that is going on in
CarpetInterp. I have added a parameter which controls this, and with this
parameter set to the default, nothing changes (i.e. it is not going to
change anyone's results unless they set the parameter). I would like to
commit this, so that collaborators can work off the same version. Since
the patch is very small, I hope this will not add too much unneeded
complexity. Is it OK to commit? Patch is attached.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1656>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1657: ExternalThorns/pciutils ignores most option list options
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: pciutils |
-----------------------------------+----------------------------------------
It does not contain a configure script and its Makefile hard-codes the
compiler and linker to be gcc. This is an issue if LDFLAGS (or CFLAGS
possibly) contain {{{-openmp}}} like they do when using the intel
compiler. Also using mkl could (should) be done with the {{{-mkl}}} switch
to the intel compiler but gcc (as used in pciutils) will naturally not
accept this.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1657>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1697: testing system starts tests for which thorns are missing
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
We apparently have a bug in the perl script that drives the testsuite. On
hydra (a machine at RZG that Ian and I are testing) it tries to run the
test_ah test of Dissipation even though that test parfile uses NoExcision
which is commented out.
A quick test indicates that the script only looks at the first
ActiveThorns line in the parfile when it determines if a parfile is
runnable. Movin NoExcision into the first ActiveThorns line correctly
ignores the test on hydra.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1697>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1623: using ENV in parfiles is not documented
---------------------------+------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: documentation |
---------------------------+------------------------------------------------
the user guide does not explain how to use ENV in parfiles (at least grep
ENV doc/UsersGuide/*.tex does not find anything) nor do the peg files in
src/piraha/peg contain.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1623>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1759: need tensorparity=-1 for WeylScal4::curvIi_group and curvJi_group
------------------------------------+---------------------------------------
Reporter: physicsbeany@… | Owner: Bernard Kelly
Type: defect | Status: new
Priority: minor | Milestone: ET_2014_11
Component: EinsteinToolkit thorn | Version: development version
Keywords: weylscal4, parity |
------------------------------------+---------------------------------------
The WeylScal4 gridfunctions curvIi and curvJi are pesudoscalars with the
same parity properties as Psi2r and Psi2i. However, they're currently
assigned no tensorparity attribute, so they're treated as scalars.
As a result, for a z-aligned Kerr BH (EinsteinInitialData/IDAnalyticBH)
evolved with reflection symmetry across the x-y plane, an interpolation of
curvIi to a coordinate sphere will yield different values for the z<0
points than the same data on a full grid.
Can we set "tensorparity=-1" for both these groups, to fix this issue?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1759>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#382: SimFactory home directory on Kraken is too specific
------------------------+---------------------------------------------------
Reporter: hinder | Owner: mthomas
Type: defect | Status: new
Priority: major | Milestone: ET_2011_05
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
The mdb entry for Kraken in SimFactory has
'sourcebasedir' => '/nics/b/home/@USER@',
My home directory is
'/nics/d/home/@USER@'
Either we could leave the source base dir as unset to force the user to
set it, or we could automatically detect the location of the user's home
directory (better).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/382>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit