Trac December 2010

trac@lists.einsteintoolkit.org

1 participants
102 discussions

[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] #132: TRAC home page does not give a link for ET tickets
by Einstein Toolkit 21 Mar '11

21 Mar '11

#132: TRAC home page does not give a link for ET tickets ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: trivial | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- The "TRAC home" page in the ET TRAC does not give a hyperlink for Einstein Toolkit tickets. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/132> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #154: docs.einsteintoolkit.org certificate is invalid due to hostname mismatch
by Einstein Toolkit 21 Mar '11

21 Mar '11

#154: docs.einsteintoolkit.org certificate is invalid due to hostname mismatch -------------------------------------+-------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- If I go to https://docs.einsteintoolkit.org I get a certificate warning from my browser because the certificate is for wiki.cct.lsu.edu, not docs.einsteintoolkit.org. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/154> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #122: Code documentation
by Einstein Toolkit 12 Mar '11

12 Mar '11

#122: Code documentation -------------------------+-------------------------------------------------- Reporter: hinder | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- In order to help new developers understand the code, the following would be useful: * Provide some sort of high-level overview of the internal components of simfactory. This could be in the form of a class diagram with annotations indicating what each class does, and its relationship to the other classes (inheritence/object membership etc). There must be tools for doing this for python and generating doxygen-type output. * Within the source code, provide at least a one-line comment for each function indicating what it does. * Ensure that the readmes etc in the repository are up-to-date, or at least remove any out-of-date information. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/122> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #172: CCL error message has no file name
by Einstein Toolkit 08 Mar '11

08 Mar '11

#172: CCL error message has no file name ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- I just received the following fatal error message from Cactus: Processing CCL files CST error 1: -> Error parsing optional block line '' Missing { at start of block. This error message does not tell me which thorn or file causes this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/172> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #164: Support user directories for configuration files
by Einstein Toolkit 08 Mar '11

08 Mar '11

#164: Support user directories for configuration files -------------------------+-------------------------------------------------- Reporter: hinder | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- It would be nice to have a separate simfactory directory for all user customisations rather than mixing them in with the code. This way, one can update simfactory (or delete/recheckout) without having to extract all changes. Here is one possible solution: Allow the user to specify a "sf-config" directory (maybe there is a better name) in the defs.local.ini. Any configuration files, for example mdb entries, scriptfiles etc, should be searched for under sf-config first before looking in the standard location. One could then set sf-config = simfactory.user and put local machine definitions and scriptfiles and modifications to the standard ones which are never going to be committed. One could keep the same directory structure under simfactory.user as is in simfactory, or it might be better to just search for files in that directory, since all the files should have different names, and an extra hierarchy is just annoying. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/164> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #129: Warnings during syncing
by Einstein Toolkit 08 Mar '11

08 Mar '11

#129: Warnings during syncing ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- When I synchronise with the Python SimFactory, I receive many warnings such as: cannot delete non-empty directory: simfactory/branches/PYSIM_2010/lib/modules cannot delete non-empty directory: simfactory/branches/PYSIM_2010/lib/modules cannot delete non-empty directory: simfactory/branches/PYSIM_2010/lib/archive cannot delete non-empty directory: simfactory/branches/PYSIM_2010/lib/archive cannot delete non-empty directory: simfactory/branches/PYSIM_2010/lib cannot delete non-empty directory: simfactory/branches/PYSIM_2010/lib cannot delete non-empty directory: simfactory/branches/PYSIM_2010 cannot delete non-empty directory: simfactory/branches/PYSIM_2010 cannot delete non-empty directory: simfactory/branches I know where they come from; however, they are nevertheless annoying. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/129> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #127: Restarts should have hard link to executable
by Einstein Toolkit 08 Mar '11

08 Mar '11

#127: Restarts should have hard link to executable ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- Restarts should contain a copy of the executable, so that they are self- contained. This "copy" should be implemented via a hard link if possible (to save space). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/127> 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 December 2010