Trac June 2012

trac@lists.einsteintoolkit.org

1 participants
175 discussions

[Einstein Toolkit] #526: Reorder ticket states
by Einstein Toolkit 23 May '13

23 May '13

#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

1 1

[Einstein Toolkit] #519: Add all ET repositories to TRAC
by Einstein Toolkit 23 May '13

23 May '13

#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

1 4

[Einstein Toolkit] #650: User is not asked for Mercurial authentication information initially
by Einstein Toolkit 23 May '13

23 May '13

#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

1 7

[Einstein Toolkit] #283: Update and make CoreDoc.pdf available in the EinsteinToolkit website
by Einstein Toolkit 10 May '13

10 May '13

#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

1 16

[Einstein Toolkit] #931: CartGrid3D's dependency on Boundary
by Einstein Toolkit 10 May '13

10 May '13

#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

1 10

[Einstein Toolkit] #808: testsuites in HDF5
by Einstein Toolkit 10 May '13

10 May '13

#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

1 13

[Einstein Toolkit] #322: SimFactory metadata deleted by periodic filesystem purges
by Einstein Toolkit 19 Apr '13

19 Apr '13

#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

1 4

[Einstein Toolkit] #591: Add harmonic shift to McLachlan
by Einstein Toolkit 15 Apr '13

15 Apr '13

#591: Add harmonic shift to McLachlan -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: McLachlan | -----------------------------------+---------------------------------------- The attached patch adds a harmonic shift condition to McLachlan. It does this by introducing a new real-valued parameter harmonicShift. This should be set to 0 for gamma-driver shift (the default, and the existing behaviour), and to 1 for harmonic shift. This is useful for code- correctness tests with the shifted gauge wave which is an exact solution of the Einstein equations in harmonic gauge. The harmonic shift equation has been tested with the shifted gauge wave exact solution and yields convergence to the exact solution. The current way that gauge conditions is handled in McLachlan is not very elegant, and I don't think this patch should be applied as-is. I am putting it here for anyone who might find it useful. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/591> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #624: Replace Cactus complex number implementation with C/C++ standard implementation
by Einstein Toolkit 08 Mar '13

08 Mar '13

#624: Replace Cactus complex number implementation with C/C++ standard implementation -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Cactus offers CCTK_COMPLEX. This maps to the standard datatype in Fortran, but not in C or C++. It should map to the standard datatypes in C and C++ as well, so that the growing body of code written in C and C++ can reasonably make use of complex numbers. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/624> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #950: "Correct" Weyl Scalar symmetries
by Einstein Toolkit 19 Feb '13

19 Feb '13

#950: "Correct" Weyl Scalar symmetries ---------------------------------+------------------------------------------ Reporter: yosef@… | Type: defect Status: new | Priority: major Milestone: | Component: Other Version: | Keywords: ---------------------------------+------------------------------------------ RotatingSymmetry180 and the ReflectionSymmetry thorns define a tensor alias "weylscalars_real", but the symmetries given there do not correspond to those of the usual re[psi0], im[psi0], re[psi1], im[psi1], etc scalars. The Weyl symmetries as provided in RotatingSymmetry180 static int const weylparities[10][3] = {{+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}}; The symmetries for rpsi0, ipsi0, rpsi1, ipsi1, ..., rpsi4, ipsi4 static int const weylparities[10][3] = {{+1,+1,+1}, /* rpsi0 */ {-1,-1,-1}, /* ipsi0 */ {+1,+1,-1}, /* rpsi1 */ {-1,-1,+1}, /* ipsi1 */ {+1,+1,+1}, /* rpsi2 */ {-1,-1,-1}, /* ipsi2 */ {+1,+1,-1}, /* rpsi3 */ {-1,-1,+1}, /* ipsi3 */ {+1,+1,+1}, /* rpsi4 */ {-1,-1,-1}}; /* ipsi4 */ attached is a diff between the current ET version of the Reflection and RotatingSymmetry180 thorns and the "corrected" version. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/950> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

← Newer
1
...
4
5
6
7
8
9
10
...
18
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac June 2012