#705: Activation Order in Parameter Files
-------------------------+--------------------------------------------------
Reporter: sbrandt | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Cactus_4.1.0
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
At the moment the ActiveThorns list is sensitive to the order in which
thorns are activated if the ActiveThorns parameter is updated multiple
times. However, it is not sensitive to the order in which thorns are
activated if all thorns are specified in a single line. This inconsistency
should be removed, and the order should not matter in either case.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/705>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#526: Reorder ticket states
----------------------------------+-----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
The order in which the ticket states is displayed (in the form where one
modifies the ticket state) should be the natural order in which a ticket
progresses. The current order is somewhat random.
I suggest this order:
new
confirmed
accept
reassign
review
resolve
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/526>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#519: Add all ET repositories to TRAC
----------------------------------+-----------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
TRAC provides integration with version control systems. It has a list of
repositories, and specific changesets and files can be referred to in
ticket comments and wiki pages using a convenient syntax. Several ET
repositories have been added already. I think this feature is useful, and
that the remaining repositories should be added.
It would be nice if the links were easier to type. I propose omitting the
arrangement name from the repositories, as all thorn names are probably
unique, and avoiding spaces which require extra quoting. We have several
repositories in Git and Mercurial. It would be nice to include those as
well. I believe that there are TRAC plugins to accomplish this in the
same way as for SVN.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/519>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#650: User is not asked for Mercurial authentication information initially
---------------------------+------------------------------------------------
Reporter: hinder | Owner: eric9
Type: defect | Status: new
Priority: major | Milestone:
Component: GetComponents | Version:
Keywords: |
---------------------------+------------------------------------------------
When running GetComponents without the "-a" (anonymous) option, the user
is asked initially for authentication information for any authenticated
repositories. However, the Carpet repository is not included in this
list. This leads to the authentication prompt much later when Carpet is
actually being checked out, and here it is not possible to say
"anonymous". I believe the problem occurs on line 846 of GetComponents:
{{{
# if AUTH_URL is defined we want to find the username:
if (
defined( $component->{AUTH_URL} )
and ( $component->{TYPE} eq 'cvs'
or $component->{TYPE} eq 'svn'
or $component->{TYPE} eq 'darcs'
or $component->{TYPE} eq 'git' )
)
{
}}}
where Mercurial (hg) is not included in that list. The attached
(untested) patch adds hg to that list, but I don't know if this is
sufficient to fix the problem.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/650>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#283: Update and make CoreDoc.pdf available in the EinsteinToolkit website
-------------------------------------+--------------------------------------
Reporter: bmundim | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit website | Version:
Keywords: |
-------------------------------------+--------------------------------------
The advanced concepts document:
http://cactuscode.org/documentation/CoreDoc.pdf
should be updated and made available in the ET website, both in pdf and
html.
Does anyone know where its .tex file version is located?
Thanks,
Bruno.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/283>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#931: CartGrid3D's dependency on Boundary
--------------------+-------------------------------------------------------
Reporter: jtao | Owner:
Type: defect | Status: new
Priority: minor | Milestone: Cactus_4.1.0
Component: Cactus | Version: Cactus_4.0.0
Keywords: |
--------------------+-------------------------------------------------------
CartGrid3D_ApplyBC in CartGrid3D is scheduled in BoundaryConditions, which
is defined in the Boundary thorn.
I can see that this is related with the symmetric boundary conditions but
could we handle it in boundary ?
It seems to me that it is not a good idea to have the grid thorn depend on
the boundary thorn. While making boundary depending on grid is more
reasonable if we have to introduce the dependency between these two
thorns.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/931>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#808: testsuites in HDF5
-------------------------+--------------------------------------------------
Reporter: jtao | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone: Cactus_4.1.0
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Instead of constructing tools to compare Carpet ascii output from multiple
processes, how about building tools to diff files HDF5 ?
Compared to ASCII:
HDF5 testsuites may have several advantages:
small, fast, portable, independent of number of process.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/808>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1111: Missing fortran compiler prevents CCTK_REAL8 from being defined.
---------------------+------------------------------------------------------
Reporter: sbrandt | Owner:
Type: defect | Status: new
Priority: major | Milestone: Cactus_4.1.0
Component: Cactus | Version: Cactus_4.0.0
Keywords: |
---------------------+------------------------------------------------------
If the fortran compiler is missing or invalid, Cactus does not create the
definition for CCTK_REAL8, CCTK_REAL4, etc.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1111>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1156: Outdated thornlists under McLachlan/doc
-----------------------------------+----------------------------------------
Reporter: bentivegna | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
The two thornlists under McLachlan/doc still reflect pre-ET thorn
locations. Update or remove?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1156>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#322: SimFactory metadata deleted by periodic filesystem purges
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: mthomas
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
Production filesystems are subject to periodic purges (typically on the
order of weeks or months) where data which has not been accessed recently
is deleted. This means that it is possible for some restarts of very
long-running simulations to be deleted by the system. This can be
addressed by an automated archiving system, but such a system does not
address the problem that the simulation metadata directory (currently
called SIMFACTORY) and any restarts which have not been run yet, will also
be purged. This would make it impossible to submit future restarts and
limits the number of chained restarts you can submit to the purge time of
the system.
One possibility to solve this problem would be to store a backup, or
"shadow" copy of all the simulation metadata in a non-volatile location.
This could be the user's home directory, or a "work" directory which is
not purged. The details would need to be worked out.
This is not a serious issue yet.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/322>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit