#1791: Allow aligning the interior of grid functions in looping macros
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Currently, when grid functions are aligned, Cactus expects their origin to
be aligned. These changes update the looping macros to allow aligning the
interior of grid functions instead.
Whether and how grid functions are aligned is still determined by the
driver -- this only makes it possible to still use the looping macros in
this case.
Implemented in <https://bitbucket.org/cactuscode/cactus/pull-request/16
/allow-aligning-the-interior-of-grid/diff> and
<https://bitbucket.org/cactuscode/cactustest/pull-request/1/allow-
aligning-the-interior-of-grid/diff>.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1791>
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
#960: Dissipation thorn schedules LOCAL routines after GLOBAL ones
----------------------------------------------+-----------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: Dissipation and SphericalSurface |
----------------------------------------------+-----------------------------
Dissipation currently contains a schedule item {{{
SCHEDULE setup_epsdis AT cctk_poststep after SphericalSurface_HasBeenSet
{
LANG: C
SYNC: epsdisA_group
} "Setup spatially varying dissipation"
}}}
However SphericalSurface_HasBeenSet is AFTER SphericalSurface_Set which is
a GLOBAL routine. Since GLOBAL routines run last in POSTSTEP (which is in
EVOL) the AFTER modifier is ignored for all but the last (finest)
refinement level. This can lead to the wrong surface shape to be used by
the local routines.
It might actually make sense to teach the flesh about GLOBAL/LOCAL etc and
refuse AFTER/BEFORE statements that span different modes. This of course
depends on how much work this is and if we expect the dependency and task
based scheduler to be finished soon and if there are legitimate uses for
AFTER/BEFORE to span modes.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/960>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#912: Use CACTUS_CONFIGS_DIR in Formaline
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Formaline assumes that configurations are stored in a "configs"
subdirectory of $CCTK_HOME. Use $CACTUS_CONFIGS_DIR instead.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/912>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1595: Is {{{*)}}} allowed as upper boundary for a parameter range?
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: |
----------------------+-----------------------------------------------------
I sometimes see these warnings when Cactus starts:
{{{
WARNING[L1,P0] (Cactus): Invalid end of real-valued parameter range; range
descriptor is "(0.0 : *)" (value is 1)
}}}
Presumably the warning depends on which thorns are active.
This warning looks as if the syntax {{{*)}}} was accepted by the CST when
parsing a param.ccl file, but was later not recognized by the flesh when
checking a parameter value against this range. (The flesh uses HUGE_VAL as
fallback, which happens to be correct in this case.)
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1595>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit