Trac December 2011

trac@lists.einsteintoolkit.org

4 participants
150 discussions

[Einstein Toolkit] #705: Activation Order in Parameter Files
by Einstein Toolkit 24 May '13

24 May '13

#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

1 7

[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] #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] #620: Simplify timelevel handling for Cactus thorn writers
by Einstein Toolkit 21 Nov '12

21 Nov '12

#620: Simplify timelevel handling for Cactus thorn writers -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Currently, a thorn writer must declare the maximum number of timelevels for a variable in the interface.ccl file, then allocate a specific number of timelevels for which storage is allocated in the schedule.ccl file. There are rules for how many timelevels a variable should have. For example, to evolve using MoL I think you need at least two, whereas to evolve using mesh refinement with time prolongation order 2 you need three. The problem is that the person writing the thorn shouldn't have to know how it is going to be used. If I write an evolution thorn, I should not care whether it is used with mesh refinement or not. I certainly shouldn't have to care what prolongation order is going to be used. Would it be possible for Cactus to automatically determine the number of timelevels needed for a given variable? My proposal is that it should not be necessary for the user to specify the number of timelevels in the interface.ccl or schedule.ccl file for variables declared in that thorn. The only time a thorn writer should have to do that is if that thorn specifically uses the other timelevels. For example, a thorn which couples to MoL will probably only ever read or write to the current timelevel. MoL, on the other hand, could tell Cactus that it needs a certain number of timelevels at runtime for those variables. Similarly for mesh refinement. This goes along with the planned changes to the scheduling system to make it easier to program Cactus thorns and make it harder to make errors. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/620> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #695: Don't buffer output from configuration scripts
by Einstein Toolkit 15 Nov '12

15 Nov '12

#695: Don't buffer output from configuration scripts ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- Output from configuration scripts is buffered, and is only output after the script has finished. This is inconvenient for long-running scripts. Instead, the output should be shown right away. This buffering is done in file lib/sbin/ConfigScriptParser.pl, which uses Perl backquotes `` to collect all of the script's output. Instead, Cactus should use a pipe to read the script's output line-by-line, and process it immediately. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/695> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

← Newer
1
2
3
4
5
6
7
8
...
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2011