Trac April 2011

trac@lists.einsteintoolkit.org

1 participants
139 discussions

[Einstein Toolkit] #421: Cactus make with Revision r4696 not possible
by Einstein Toolkit 29 Apr '11

29 Apr '11

#421: Cactus make with Revision r4696 not possible ----------------------------------------------+----------------------------- Reporter: alexander.beck-ratzka@… | Type: defect Status: new | Priority: blocker Milestone: | Component: Cactus Version: | Keywords: ----------------------------------------------+----------------------------- After making a configuration with: make carpet-luca-cactus-new-cactus options=sim-configs-save/datura.cfg- luca I have tried to build the executable with: make carpet-luca-cactus-new-cactus This ends up with the error: [snip] /home/alibeck/programme/Cactus-Luca/Cactus/src/include/cctk.h(163): catastrophic error: could not open source file "cctk_ScheduleFunctions.h" #include "cctk_ScheduleFunctions.h" ^ /home/alibeck/programme/Cactus-Luca/Cactus/src/include/cctk.h(163): catastrophic error: could not open source file "cctk_ScheduleFunctions.h" #include "cctk_ScheduleFunctions.h" ^ /home/alibeck/programme/Cactus-Luca/Cactus/src/include/cctk.h(163): catastrophic error: could not open source file "cctk_ScheduleFunctions.h" #include "cctk_ScheduleFunctions.h" ^ Preprocessing /home/alibeck/programme/Cactus- Luca/Cactus/arrangements/CactusBase/CoordBase/src/Domain.c Compiling /home/alibeck/programme/Cactus- Luca/Cactus/arrangements/CactusBase/CoordBase/src/Domain.c /home/alibeck/programme/Cactus-Luca/Cactus/src/include/cctk.h(163): catastrophic error: could not open source file "cctk_ScheduleFunctions.h" #include "cctk_ScheduleFunctions.h" ^ compilation aborted for /home/alibeck/programme/Cactus-Luca/Cactus/configs /carpet-luca-cactus-new-cactus/build/CoordBase/Domain.c (code 4) make[3]: *** [Domain.c.o] Error 4 make[2]: *** [make.checked] Error 2 make[1]: *** [/home/alibeck/programme/Cactus-Luca/Cactus/configs/carpet- luca-cactus-new-cactus/lib/libthorn_CoordBase.a] Error 2 make: *** [carpet-luca-cactus-new-cactus] Error 2 [snip] The file cctk_ScheduleFunctions.h cannot be found anywhere. I have just updated to revision r4696 in the Cactus/src directory. The repository after .svn/entries is: https://svn.cactuscode.org/flesh/trunk/src -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/421> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[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

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2011