#237: AHFinderDirect should set the number of timelevels of ahmask to match the
number needed for e.g. the metric
--------------------+-------------------------------------------------------
Reporter: knarf | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version:
Keywords: |
--------------------+-------------------------------------------------------
The attached patch changes the number of timelevels of the ahmask to match
the number which is used for the metric. Setting this to three
unconditionally leads to problems when running with Carpet and
prolongation_order_time=1 because all GFs in Carpet are expected to have
the same number of timelevels: prolongation_order_time+1.
This is not the ideal solution. That would eliminate also variables ala
metric_timelevels, because they directly depend on prolongation_order_time
and should not have to be set (correctly) in a parameter file. This could
be done automatically.
However, the attached patch for now uses metric_timelevels, in order to
get AHFinderDirect working quickly.
I am asking for a review, and can apply it myself after a positive reply.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/237>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#142: GRHydro synchronises too many variables
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
Variables without storages should not be synchronised. When running
GRHydro, I see the following warnings:
WARNING[L2,P0] (Carpet): Cannot synchronise group "HYDROBASE::TEMPERATURE"
because it has no storage
WARNING[L2,P0] (Carpet): Cannot synchronise group "HYDROBASE::Y_E" because
it has no storage
WARNING[L2,P0] (Carpet): Cannot synchronise group "GRHYDRO::Y_E_CON"
because it has no storage
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/142>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#227: Users cannot receive notifications of ticket changes
----------------------------------+-----------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
When a user reports a bug, they should be able to subscribe to email
notifications for that bug, and that bug alone. It is unlikely that they
will regularly check the TRAC for each bug they reported in the hope that
someone has responded.
There is a TracNotification
(http://trac.edgewall.org/wiki/TracNotification) feature which apparently
is disabled by default. Shall we try this out?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/227>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#231: Missing #include in CactusBase/IOASCII
------------------------------------------------------+---------------------
Reporter: Barry Wardell <barry.wardell@…> | Type: defect
Status: new | Priority: blocker
Milestone: | Component: Cactus
Version: | Keywords:
------------------------------------------------------+---------------------
Since svn revision 212 the thorn CactusBase/IOASCII does not compile. The
problem is that the CCTK_ARGUMENTS macro has not been declared. Adding
#include "cctk_Arguments.h"
in CactusBase/IOASCII/src/ChooseOutput.c fixes the problem. Is this the
correct solution?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/231>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#226: ET wiki has some certificate trouble
-------------------------------------+--------------------------------------
Reporter: bmundim | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit website | Version:
Keywords: einsteintoolkit wiki |
-------------------------------------+--------------------------------------
Hi,
The Einstein Toolkit wiki has some certificate issues. Firefox alerts
about untrusted connection. The technical details are the following:
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)
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/226>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#224: GetComponents doesn't run any more
---------------------------+------------------------------------------------
Reporter: eschnett | Owner: eric9
Type: defect | Status: new
Priority: blocker | Milestone:
Component: GetComponents | Version:
Keywords: |
---------------------------+------------------------------------------------
When I run GetComponents (even without options), it doesn't run any more:
$ bin/GetComponents
Can't locate object method "initialize" via package "Pod::Usage" at
/Users/eschnett/gt5.0.2/lib/perl/Pod/Usage.pm line 531.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/224>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#209: GetComponents --status should not report directories that it created
---------------------------+------------------------------------------------
Reporter: eschnett | Owner: eric9
Type: defect | Status: new
Priority: minor | Milestone:
Component: GetComponents | Version:
Keywords: |
---------------------------+------------------------------------------------
GetComponents creates directories such as arrangements/CactusBase, and
then reports these with a question mark during --status. It should rather
ignore these directories during --status.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/209>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#103: Handle parameter files with DOS newline convention
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
I used a parameter file which used $parfile to indicate the location of
the output directory. This parameter file also used DOS line ending
conventions, i.e. \r\n instead of \n. The symptom was that an output
directory called "$parfile" was created since the $parfile replacement did
not occur.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/103>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit