Trac January 2011

trac@lists.einsteintoolkit.org

1 participants
147 discussions

[Einstein Toolkit] #143: ETK "Chandrasekhar" release: HDF5 "BUILD" option failing on MacOSX + openmpi.
by Einstein Toolkit 02 Sep '11

02 Sep '11

#143: ETK "Chandrasekhar" release: HDF5 "BUILD" option failing on MacOSX + openmpi. --------------------------------------+------------------------------------- Reporter: bernard.j.kelly@… | Type: defect Status: new | Priority: major Milestone: ET_2010_11 | Component: Other Version: ET_2010_11 | Keywords: HDF5 openmpi --------------------------------------+------------------------------------- We've recently tried compiling the latest ETK official release ("Chandrasekhar") on our Macbooks. To get a working HDF5 installation compatible with the build, we've selected "HDF5_DIR=BUILD". This fails, however. I'm attaching my user-specified Cactus config. options, as well as the Thornlist used, and the error messages. My machine is running OSX 10.5.8 (Leopard), and the compiler is openmpi [i686-apple-darwin9-g++-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)], installed via macports. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/143> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #207: Cactus should have an option to store the mpirun command needed to run test cases
by Einstein Toolkit 24 Aug '11

24 Aug '11

#207: Cactus should have an option to store the mpirun command needed to run test cases -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Cactus should be able to remember from configuration the mpirun command syntax needed to run test cases. This would simplify running test cases, which could then probably even be automated. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/207> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #63: create separate tracs on trac.cactuscode.org and trac.cfdtoolkit.org
by Einstein Toolkit 16 Aug '11

16 Aug '11

#63: create separate tracs on trac.cactuscode.org and trac.cfdtoolkit.org --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: task | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- We need separate tracs on trac.cactuscode.org and trac.cfdtoolkit.org, including ssl certificates and the complete rest of the setup. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/63> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #233: Unable to complete an ET checkout without SVN network errors
by Einstein Toolkit 16 Aug '11

16 Aug '11

#233: Unable to complete an ET checkout without SVN network errors --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- I am running an automated build and test system every night which attempts to check out the Einstein Toolkit thornlist. Every night, I get error messages from at least one thorn of the 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) Typically, three or more thorns will exhibit this problem. All the following repositories have exhibited this problem since 11th January 2011: CactusArchive/ADM CactusElliptic/EllBase CactusNumerical/Cartoon2D CactusNumerical/Dissipation CactusNumerical/InterpToArray CactusNumerical/RotatingSymmetry180 CactusNumerical/RotatingSymmetry90 EinsteinInitialData/Exact EinsteinInitialData/IDAnalyticBH EinsteinInitialData/TOVSolver EinsteinInitialData/TwoPunctures LSUThorns/QuasiLocalMeasures manifest simfactory I assume that there is some problem with the SVN server or our network connection to it that is making it so unreliable. Am I the only one? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/233> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #123: Run a syntax checker in a pre-commit hook
by Einstein Toolkit 09 Aug '11

09 Aug '11

#123: Run a syntax checker in a pre-commit hook ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- I am getting annoyed by the frequent syntax errors in SimFactory that used to be caught by Perl and are now not caught by Python. It would be ideal if syntax checking could be built into SimFactory, so that it executes automatically during startup if that isn't too slow. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/123> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #124: Implement a testing mechanism for simfactory
by Einstein Toolkit 09 Aug '11

09 Aug '11

#124: Implement a testing mechanism for simfactory -------------------------+-------------------------------------------------- Reporter: hinder | Owner: mthomas Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Currently there is no easy way to check that a change to simfactory hasn't broken critical functionality. A system could be introduced to run through each command and check that it does the right thing. It won't be possible to check every single combination of possible options, but the most commonly used options should be tested. A first attempt could involve testing that the commands work locally on the current machine. This would involve submitting jobs and testing that they have the expected behaviour. On busy machines, this means that the tests could potentially take a long time to complete. Remote submission could be tested by running these tests from a central location (e.g. the developer's workstation or laptop). We could also include a python correctness checking step in these tests (e.g. using pychecker or pylint). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/124> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #180: Reduce disk space used by checkpoints
by Einstein Toolkit 11 Jul '11

11 Jul '11

#180: Reduce disk space used by checkpoints -------------------------+-------------------------------------------------- Reporter: hinder | Owner: mthomas Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Currently simfactory stores the checkpoints for each restart in their own directory. This means that the Cactus mechanism for deleting all but the most recent N checkpoints does not see the previous checkpoints. This means that you can easily run out of quota space when doing very long simulations. One solution to this would be for SimFactory to store the checkpoints in a directory above the output-NNNN directories and make the current checkpoints directories under output-NNNN symbolic links to the common directory. This way, all restarts would see the same directory for checkpoint files, and Cactus could clean up the old checkpoints. The current hardlinking mechanism would not be required any more. This solution might be undesirable because it means that each restart is no longer independent. Another solution would be to give simfactory an option to delete old checkpoint files from previous restarts when a job starts. This would duplicate the functionality already available in Cactus. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/180> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #113: Simfactory should be able to run the Cactus testsuites
by Einstein Toolkit 05 Jul '11

05 Jul '11

#113: Simfactory should be able to run the Cactus testsuites -------------------------+-------------------------------------------------- Reporter: knarf | Owner: mthomas Type: enhancement | Status: new Priority: critical | Milestone: ET_2011_06 Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- ... in the python version, before the next ET release. The scripts at http://einsteintoolkit.org/release-info/ might help with implementing that. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/113> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #242: build fails after running out of disk space
by Einstein Toolkit 02 May '11

02 May '11

#242: build fails after running out of disk space ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- After running out of disk space (and then removing 16 GByte), building fails on numrel09: $ ./bin/sim build DEBUG: Simfactory command: ./bin/../simfactory/lib/sim.py "build" DEBUG: Version exported The Simulation Factory: Manage Cactus simulations Info: defs: /home/eschnett/EinsteinToolkit-hg- vanilla/simfactory/etc/defs.ini Info: defs.local: /home/eschnett/EinsteinToolkit-hg- vanilla/simfactory/etc/defs.local.ini Info: Executing command: build Using configuration: sim Info: Cactus Directory: /home/eschnett/EinsteinToolkit-hg-vanilla Traceback (most recent call last): File "./bin/../simfactory/lib/sim.py", line 142, in <module> main() File "./bin/../simfactory/lib/sim.py", line 139, in main CommandDispatch() File "./bin/../simfactory/lib/sim.py", line 106, in CommandDispatch module.main() File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim- build.py", line 420, in main CommandDispatch() File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim- build.py", line 347, in CommandDispatch exec("command_%s()" % command) File "<string>", line 1, in <module> File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim- build.py", line 391, in command_build PrepConfiguration(config) File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim- build.py", line 58, in PrepConfiguration prop.init(propertiesFile) File "/home/eschnett/EinsteinToolkit-hg- vanilla/simfactory/lib/restartlib.py", line 101, in init self.ImportProperties() File "/home/eschnett/EinsteinToolkit-hg- vanilla/simfactory/lib/restartlib.py", line 107, in ImportProperties for key in section.keys(): AttributeError: 'NoneType' object has no attribute 'keys' This looks as if some internal information about the build has become corrupt, maybe because of a partially written file. This may be a rare case not worth handling elegantly. However -- what should I do now? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/242> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[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
2
3
4
5
6
7
...
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac January 2011