#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
#1232: Improve output format of Carpet timer trees
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version:
Keywords: |
-------------------------+--------------------------------------------------
Marek Blazewicz reports:
I was using the timer tree in Carpet. Because it was not too nicely
outputted, and I had to format it manually each time, I've fixed it ;).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1232>
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
#1229: provide downloadable tarball of ET
-------------------------------------+--------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit website | Version:
Keywords: |
-------------------------------------+--------------------------------------
I created a mock up download page (with one paragraph changed) with a tar
ball of the current release version of the ET.
http://www.tapir.caltech.edu/~rhaas/ET/
To provide the tarball we would need some way to store data on the web-
sever that is not archived via svn (or live with ~200MB commmits).
Alternatively I am happy to have the tarball live in in my webspace and
keep the link though a more "permanent" storage site might be more useful.
The tarball would need to be updated whenever the release branch(es)
change.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1229>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1221: Reduction weight anomaly when using zero CoordBase::boundary_shiftout_*
------------------------+---------------------------------------------------
Reporter: bentivegna | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: Carpet | Version: development version
Keywords: |
------------------------+---------------------------------------------------
When using a refinement level that covers the entire grid, and setting the
CoordBase::boundary_shiftout_* parameters to zero, the following warning
appears:
INFO (CarpetReduce): Simulation domain volume: 8000
INFO (CarpetReduce): Additional excised volume: 0
INFO (CarpetReduce): Reduction weight sum: 9141
WARNING level 1 in thorn CarpetReduce processor 0 host socket.local
(line 137 of
/Users/bennie/CactusTrees/TrueAMR/arrangements/Carpet/CarpetReduce/src/mask_test.c):
-> Simulation domain volume and reduction weight sum differ
This can be reproduced using the attached parameter file. The problem
seems to arise at the boundaries of the restricted region: I would expect
the coarse grid to carry zero reduction weight everywhere (as it does if
the shiftout is one), but the boundaries have a non-zero weight instead,
which leads to double counting, and hence the difference between domain
volume and weight sum.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1221>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1171: WeylScal4 schedule order is incorrect
-----------------------------------+----------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: WeylScal4 testsuite |
-----------------------------------+----------------------------------------
WeylScal4 contains a calculation for computing the I and J invariants from
the Psis. This calculation is not scheduled explicitly after the Psis.
Therefore, Cactus will probably schedule the routines alphabetically,
which should be wrong. This should be corrected either with an After or
Schedule element in the calculation.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1171>
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