Trac November 2010

trac@lists.einsteintoolkit.org

1 participants
70 discussions

[Einstein Toolkit] #98: simfactory error message could suggest sim-util setup
by Einstein Toolkit 29 Jan '11

29 Jan '11

#98: simfactory error message could suggest sim-util setup -------------------------+-------------------------------------------------- Reporter: knarf | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Whenever simfactory errors out because the local machine isn't known, it could suggest to run sim-util setup. This would help especially new users to get started. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/98> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #87: "run" should create a simulation
by Einstein Toolkit 29 Jan '11

29 Jan '11

#87: "run" should create a simulation -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- The run command should create a simulation if necessary, similar to the submit command. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/87> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #103: Handle parameter files with DOS newline convention
by Einstein Toolkit 20 Jan '11

20 Jan '11

#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

1 4

[Einstein Toolkit] #105: fatal: git checkout: updating paths is incompatible with switching branches.
by Einstein Toolkit 14 Jan '11

14 Jan '11

#105: fatal: git checkout: updating paths is incompatible with switching branches. ---------------------------+------------------------------------------------ Reporter: knarf | Owner: eric9 Type: defect | Status: new Priority: blocker | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ Using the current ET_2010_11 GetComponents with https://svn.einsteintoolkit.org/manifest/branches/ET_2010_11/einsteintoolki… gives the error message: fatal: git checkout: updating paths is incompatible with switching branches. for three repositories: Unable to process KrancNumericalTools/GenericFD Unable to process McLachlan/doc Unable to process Carpet/doc -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/105> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #71: GetComponents does not correctly handle missing hg
by Einstein Toolkit 14 Jan '11

14 Jan '11

#71: GetComponents does not correctly handle missing hg ---------------------------+------------------------------------------------ Reporter: hinder | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ I have tried to run GetComponents to checkout the Mercurial version of Carpet on a system where Mercurial is not installed. I get the error: Use of uninitialized value in scalar chomp at ./GetComponents line 429. You have requested an hg checkout, but the system was unable to find hg. Please enter the path to hg: ----------------------------------------------------------------- at the start of the GetComponents output, but the checkout continues and finishes with 92 components checked out successfully. 0 components updated successfully. Time Elapsed: 14 minutes, 25 seconds and returns 0. GetComponents should return a failure code in this case and not attempt the checkout. Log is attached. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/71> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #83: GetComponents parallel checkout not always stable
by Einstein Toolkit 14 Jan '11

14 Jan '11

#83: GetComponents parallel checkout not always stable ---------------------------+------------------------------------------------ Reporter: eric9 | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ GetComponents parallel checkout sometimes creates extra folders in the directory it was called from. This appears to happen only when git repos (possibly darcs and hg as well) are being updated. It is likely due to changing the directory during the parallel update phase. It also only seems to occur when there are actual changes to be pulled into the repo. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/83> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #92: Output of list-simulations should be sorted alphabetically
by Einstein Toolkit 14 Jan '11

14 Jan '11

#92: Output of list-simulations should be sorted alphabetically ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/92> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #104: "cleanup" does not make stdout/stderr world-readable
by Einstein Toolkit 14 Jan '11

14 Jan '11

#104: "cleanup" does not make stdout/stderr world-readable ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/104> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #119: Have multiple dprints
by Einstein Toolkit 12 Jan '11

12 Jan '11

#119: Have multiple dprints -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- If there are multiple versions of dprint specifying the intent ("I am going to abort with an error", "this is a severe problem", "warning", "log message"), then one could probably omit the second argument that specifies whether to print the error always. This would be a higher level interface and could make it easier to use. dabort derror dwarn dlog Internally, these would just call dprint, depending on the verbosity level and environment settings. For example, dabort would always print, and dwarn would not print if it happens during a non-essential operation. dlog would only print if the verbosity is high. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/119> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #126: Simulation not deactivated during automatic cleanup
by Einstein Toolkit 07 Jan '11

07 Jan '11

#126: Simulation not deactivated during automatic cleanup ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- I had a simulation consisting of a single restart that finished, leaving the output-0000-active link present. I then submitted a second restart. While waiting in the queue, this link was still present; it was only removed when the second restart actually run. Submitting a second restart should only be possible if the simulation is inactive, which means that this link is not present any more. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/126> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2010