Trac April 2013

trac@lists.einsteintoolkit.org

1 participants
178 discussions

[Einstein Toolkit] #1254: Simplify SimFactory's get-output-dir command
by Einstein Toolkit 19 Aug '13

19 Aug '13

#1254: Simplify SimFactory's get-output-dir command -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Currently, sim get-output-dir returns: {{{ Simulation name: <simname> Output directory: <basedir>/<simname>/output-NNNN/<parbasename> }}} I think most uses of this command would be in shell scripts, where it would be easier to use if it only output the actual output directory. The first line is redundant, as the user has already specified the simulation name. Also, simfactory is appending the <parbasename>, and assuming that such a directory exists and contains some useful data. Without parsing the parameter file and duplicating cactus logic, it cannot know where the actual data is. I think simfactory should just give the output-0000 directory, and leave it up to the user to figure out where to find the data in there. The attached patch implements this change. OK to apply? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1254> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #605: Simfactory does not find the right 'path' for symlinked cactus directories
by Einstein Toolkit 13 Aug '13

13 Aug '13

#605: Simfactory does not find the right 'path' for symlinked cactus directories ------------------------+--------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: ET_2011_10 Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- Simfactory currently does not detect the 'right' path to a Cactus sourcetree if this is from within a symlink, e.g. Cactus -> /mnt/data/Cactus. This is because while `pwd` returns '/home/user/Cactus', simfactory uses a wrapper to the C-library getcwd(), which dereferences symlinks. Simfactory then gets '/mnt/data/Cactus' and tries to use this path on remote machines when syncing - which of course does not work. The attached patch fixes this by using os.environ.get("PWD") and, if this is not defined, using os.getcwd() as workaround. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/605> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 27

[Einstein Toolkit] #117: Error while building multiple configurations
by Einstein Toolkit 12 Aug '13

12 Aug '13

#117: Error while building multiple configurations ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- I wanted to build multiple configurations at once with the command ./simfactory/sim build sim-debug sim sim-debug is a debug configuration, sim is optimised. SimFactory built sim-debug, then aborted with the error: optionlist is: /Users/eschnett/EinsteinToolkit-hg/configs/sim/OptionList Error: pattern '^\s*DEBUG\s*=.*$' exists already It assumes that SimFactory doesn't properly distinguish between the different build options of the different configurations. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/117> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1303: document syntax of new parameter file parser
by Einstein Toolkit 12 Aug '13

12 Aug '13

#1303: document syntax of new parameter file parser --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- currently we have no documentation as to what format the new parser accepts. As a matter of fact the documentation in the UsersGuide (see http://einsteintoolkit.org/documentation/UsersGuide/UsersGuidech7.html#x10-…) is in contradiction with what the parser will allow: {{{ * The parameter file is read sequentially from top to bottom, this means that if you set the value of a parameter twice in the parameter file, the second value will be used. * String parameter values can be specified either as unquoted tokens (not containing any whitespace), or as quoted values. If a quoted string parameter value spans multiple lines, all whitespaces, including newline characters, are preserved. }}} which will fail. Actually the first one is already incorrect with the current implementation which does not allow a parameter to be set twice (since this is often a sign of a user error). While this is "just" documentation, I'll still flag it as major since the parser is so fundamental. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1303> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #1306: problem with creating a new project with an existing cactus directory
by Einstein Toolkit 12 Aug '13

12 Aug '13

#1306: problem with creating a new project with an existing cactus directory ----------------------------------------+----------------------------------- Reporter: srichers@… | Owner: sbrandt Type: defect | Status: new Priority: minor | Milestone: Component: Mojave | Version: Keywords: | ----------------------------------------+----------------------------------- When a new project is created and fed the location of a local Cactus directory, the Mojave 'build' command does not work right away because it tries to execute simfactory from the workspace directory. It would be nice if the commands were executed in the existing directory rather than the workspace one so the .mojave.xml file doesn't have to be changed. (or a basedir variable in the mojave.xml file could be added and prepended to each filename) Also, the indexer does not work properly for new projects with an existing cactus directory. It does not recognize anything (cactus types, functions from other files, etc). It works somewhat better, though not completely, if the Cactus directory is put into the appropriate folder in workspace/ before creating the project. (recognizes Cactus internals, but not e.g. functions defined in other thorns) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1306> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1270: Formaline doesn't understand CACTUS_CONFIGS_DIR
by Einstein Toolkit 12 Aug '13

12 Aug '13

#1270: Formaline doesn't understand CACTUS_CONFIGS_DIR -----------------------+---------------------------------------------------- Reporter: sbrandt | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2013_05 Component: Other | Version: development version Keywords: Formaline | -----------------------+---------------------------------------------------- When building with Formaline and CACTUS_CONFIGS_DIR one sees error messages of the form seen below. It is easily fixed though. See patch. COMPILING /home/sbrandt/workspace/funwave2/Cactus/src/main/Parameters.c Updating /home/sbrandt/.mojaveconfig/funwave2/Cfg1/lib/libthorn_Cactus.a Checking status of thorn CactusBindings find: `configs/Cfg1/ThornList': No such file or directory find: `configs/Cfg1/config-data': No such file or directory find: `configs/Cfg1/config-info': No such file or directory -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1270> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 23

[Einstein Toolkit] #874: Reduce warnings during an ET build
by Einstein Toolkit 12 Aug '13

12 Aug '13

#874: Reduce warnings during an ET build --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- A new user of the ET might be disconcerted to see warnings during compilation such as: {{{ /home/ianhin/Cactus/EinsteinToolkit/arrangements/Carpet/CarpetLib/src/bboxset.hh(206): warning #1224: #warning directive: "TODO: this is incorrect" #warning "TODO: this is incorrect" ^ }}} I propose that such directives are replaced with a comment and a link to a TRAC ticket concerning the problem. Further, we should aim to eliminate as many warnings as possible from the build, similarly to avoid eroding confidence. Warnings can also make it hard to find the real error messages, when a build fails with errors. Other warnings I see are similar to: {{{ In file included from /home/ianhin/Cactus/GBSC12/arrangements/CactusUtils/Formaline/src/thornlist.cc:13: /home/ianhin/Cactus/GBSC12/configs/bbh/bindings/include/thornlist.h:61: warning: deprecated conversion from string constant to ‘char*’ }}} {{{ /home/ianhin/Cactus/GBSC12/arrangements/EinsteinInitialData/TwoPunctures/src/Newton.c: In function ‘TestRelax’: /home/ianhin/Cactus/GBSC12/arrangements/EinsteinInitialData/TwoPunctures/src/Newton.c:287: warning: passing argument 6 of ‘resid’ from incompatible pointer type /home/ianhin/Cactus/GBSC12/arrangements/EinsteinInitialData/TwoPunctures/src/Newton.c:75: note: expected ‘const int * const restrict* const restrict’ but argument is of type ‘int **’ }}} {{{ /home/ianhin/Cactus/GBSC12/configs/bbh/bindings/Variables/ADMBase.c: In function ‘CCTKi_BindingsFortranWrapperADMBase’: /home/ianhin/Cactus/GBSC12/configs/bbh/bindings/Variables/ADMBase.c:34: warning: passing argument 22 of ‘function’ from incompatible pointer type /home/ianhin/Cactus/GBSC12/configs/bbh/bindings/Variables/ADMBase.c:34: note: expected ‘const struct cGH * const*’ but argument is of type ‘struct cGH **’ }}} This last warning appears very many times during a build (though I believe it may be triggered only by GCC and not by the Intel compiler). {{{ /home/ianhin/Cactus/GBSC12/src/main/Parameters.c: In function ‘ParameterSetBoolean’: /home/ianhin/Cactus/GBSC12/src/main/Parameters.c:2394: warning: passing argument 4 of ‘Util_ExpressionEvaluate’ discards qualifiers from pointer target type /home/ianhin/Cactus/GBSC12/src/include/util_Expression.h:38: note: expected ‘void *’ but argument is of type ‘const int *’ }}} There are probably more as well. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/874> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #780: missing small packages
by Einstein Toolkit 29 Jul '13

29 Jul '13

#780: missing small packages ----------------------------------------------+----------------------------- Reporter: knarf | Owner: dcastl2 Type: enhancement | Status: new Priority: major | Milestone: Component: Einstein Toolkit Virtual Machine | Version: Keywords: | ----------------------------------------------+----------------------------- Some tools to be installed: mmv screen tmux texlive (probably quite large, but also probably necessary) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/780> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1231: "How did I get here" error in test suite mechanism
by Einstein Toolkit 08 Jul '13

08 Jul '13

#1231: "How did I get here" error in test suite mechanism ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- I see several error such as the one below reported by Cactus. The error is the line that begins with "ERROR". Test Hydro_InitExcision: x_flip_pugh_eno "1D shocktube, RK2, Marquina, ENO, Ideal Gas, x-Excision" Issuing ln -fns . output-0000-active && mkdir -p SIMFACTORY && TESTSUITE_PARFILE=/scratch/jenkins/jobs/EinsteinToolkit/simulations/EinsteinToolkit_69189d49fa86945d70ba137f840efe1301b13c71_2/output-0000/arrangements/EinsteinInitialData/Hydro_InitExcision/test/x_flip_pugh_eno.par /scratch/jenkins/jobs/EinsteinToolkit/simulations/EinsteinToolkit_69189d49fa86945d70ba137f840efe1301b13c71_2/output-0000/SIMFACTORY/RunScript ERROR: How did I get here, maximum difference is 9.99999388850981e-12 and maximum value is 0 for h.t0.ah2.gp BH_diagnostics.ah1.gp: differences below tolerance on 1 lines BH_diagnostics.ah2.gp: differences below tolerance on 1 lines h.t0.ah1.gp: differences below tolerance on 704 lines h.t0.ah2.gp: differences below tolerance on 731 lines sf_area[0].xg: differences below tolerance on 1 lines sf_min_radius[0].xg: differences below tolerance on 1 lines sf_radius[0]_2D.asc: differences below tolerance on 308 lines sf_radius[1]_2D.asc: differences below tolerance on 23 lines Success: 55 files compared, 8 differ in the last digits -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1231> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1192: Speed up Hydro_InitExcision test cases
by Einstein Toolkit 08 Jul '13

08 Jul '13

#1192: Speed up Hydro_InitExcision test cases -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Hydro_InitExcision sets up an excision mask for hydrodynamics evolution. It is active at initial and poststep (and postregrid), and its logic depends only on parameters, not on the simulation state. Its test cases take a very long time to run: (1) Running this for 100 iterations with PUGH is overkill. 1 iteration suffices, testing both initial and poststep. (2) The excision mask is not even output! Instead, only the indirect results on the hydro variables are tested. (3) All test cases use PUGH, so Carpet's postregrid bin is not tested. (4) Each test exists three times, for different reconstruction methods. The reconstruction methods do not enter into this thorn's logic. I conclude: The existing tests confirm that this thorn has the right functionality. They are therefore important. However, they should not be in the Cactus test suite. We want regression tests in the Cactus test cases, and this could be achieved about 100x faster (fewer iterations, fewer test cases). Additionally, there should be Carpet tests, and the excision mask should be output. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1192> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2013