Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #418: Introduce "restart" command
by Einstein Toolkit 27 Apr '11

27 Apr '11

#418: Introduce "restart" command -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Distinguish between the current "submit" ("create-submit") and "restart" commands, so that one does not accidentally restart an existing simulation. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/418> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #417: Allow SimFactory 1 to use a shared checkpoints directory
by Einstein Toolkit 23 Apr '11

23 Apr '11

#417: Allow SimFactory 1 to use a shared checkpoints directory -------------------------+-------------------------------------------------- Reporter: hinder | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- SimFactory 1 currently assumes that checkpoints are written to a subdirectory of the restart directory (output-NNNN). If you have a parameter file which uses checkpoint_dir = "../checkpoints" to have a shared checkpoint directory between different restarts, you cannot use it with simfactory 1. The attached patch fixes this in a conservative way. If there are no checkpoint files found under the restart directory, it looks for a directory called "checkpoints" in the simulation directory. If it finds checkpoint files in there, then it enables recovery but disables checkpoint file hardlinking. I don't know if we want to commit this, but it might be useful to someone if they have a simulation using a shared checkpoint directory which they need to recover. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/417> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #313: Reorder CUDA specific makefile rules
by Einstein Toolkit 22 Apr '11

22 Apr '11

#313: Reorder CUDA specific makefile rules -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The rules to build CUDA source files are very similar to those for C and C++, and different from those for the Fortrans. I suggest to reorder these makefile rules to make the code easier to understand. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/313> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #416: supporting PNG in viewport in HTTPDExtra
by Einstein Toolkit 22 Apr '11

22 Apr '11

#416: supporting PNG in viewport in HTTPDExtra -------------------------+-------------------------------------------------- Reporter: jtao | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- supporting PNG in viewport in HTTPDExtra -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/416> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #413: Curie released thornlist releases Kranc master branch
by Einstein Toolkit 21 Apr '11

21 Apr '11

#413: Curie released thornlist releases Kranc master branch -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: blocker | Milestone: ET_2011_05 Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- In the Curie released einsteintoolkit.th thornlist, Kranc release branch is commented out: #!REPO_BRANCH = $ET_RELEASE -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/413> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #411: Remove option --hostname
by Einstein Toolkit 21 Apr '11

21 Apr '11

#411: Remove option --hostname -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- The options --hostname and --machine do very similar things. I think that --hostname should be removed. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/411> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #268: The CUDA flags need to be documented
by Einstein Toolkit 19 Apr '11

19 Apr '11

#268: The CUDA flags need to be documented -------------------------+-------------------------------------------------- Reporter: knarf | Owner: jtao Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The new CUDA flags in the flesh (r4684) need to be documented. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/268> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #386: --status is very slow
by Einstein Toolkit 18 Apr '11

18 Apr '11

#386: --status is very slow ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ I find that GetComponents --status is very slow. In particular, it is much slower than --update, which is strange. In fact, I have never seen a --status command actually finish -- maybe it gets stuck? Here is output from an almost-vanilla ET checkout after about an hour of inactivity: $ ./bin/GetComponents --status --root=. manifest/einsteintoolkit.th 2>&1 | tee STATUSIn ./.:? TEST? log? exe ? STATUS ? cactus.config ? redshift__1_1.log ? RUNS ? configs ? redshift__2_1.log ? repos ? redshift__2_2.log ? README ? einsteintoolkit.th ? .crl ? cactusjar.git ? .gitignore ? doc/KrancDoc.tex ? doc/Makefile ? arrangements/CactusExternal In ./simfactory: ? simfactory/udb.pm M simfactory/cdb.pm In ./arrangements/CactusUtils/TimerReport: M arrangements/CactusUtils/TimerReport/src/Output.c In ./arrangements/EinsteinAnalysis/WeylScal4: ? arrangements/EinsteinAnalysis/WeylScal4/m/WeylScal4 ? arrangements/EinsteinAnalysis/WeylScal4/m/WeylScal4.out -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/386> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #232: GetComponents has a zero return code even when all components were not checked out
by Einstein Toolkit 18 Apr '11

18 Apr '11

#232: GetComponents has a zero return code even when all components were not checked out ---------------------------+------------------------------------------------ Reporter: hinder | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ When I run GetComponents, I frequently run into what I can only assume are transient network errors of the following form: Checking out module: CactusNumerical/Cartoon2D from repository: http://svn.cactuscode.org/arrangements/CactusNumerical/Cartoon2D/trunk into: ./arrangements svn: REPORT of '/arrangements/CactusNumerical/Cartoon2D/!svn/vcc/default': Could not read response body: connection was closed by server. (http://svn.cactuscode.org) It used to be the case that GetComponents would return a nonzero exit code in this case so that my automated script can detect this and try again. Now GetComponents says: 163 components checked out. 0 components updated. Unable to process CactusNumerical/Cartoon2D Unable to process EinsteinInitialData/Exact Unable to process EinsteinInitialData/TwoPunctures Time Elapsed: 270 minutes, 51 seconds and returns a zero exit code. This is preventing nightly build and test from running. I am using the version of GetComponents from http://svn.cactuscode.org/Utilities/trunk/Scripts/GetComponents -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/232> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #371: Repeat warnings at end
by Einstein Toolkit 18 Apr '11

18 Apr '11

#371: Repeat warnings at end ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: critical | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ When there are conflicts or other problems, the warnings are output as GetComponents proceeds. The warnings should be repeated at the end. At the very least, the fact that there were warnings should be made clear. Otherwise, conflicts or other problems remain undetected, and the next --update operation will then lead to serious problems because the repositories are in an unclean state. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/371> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac