Trac May 2013

trac@lists.einsteintoolkit.org

1 participants
178 discussions

[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] #1371: handle vector groups of vectors correctly in Periodic, RotatingSymmetry90, RotatingSymmetry180, etc.
by Einstein Toolkit 05 Aug '13

05 Aug '13

#1371: handle vector groups of vectors correctly in Periodic, RotatingSymmetry90, RotatingSymmetry180, etc. ---------------------------------------------------+------------------------ Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: RotatingSymmetry180RotatingSymmetry90 | ---------------------------------------------------+------------------------ I think only the RotatingSymmetry ones need work since Peridic does not need to know what type of object it acts on. See #1236 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1371> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[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] #1345: Cactus shouldn't mess with some flags after they have been setup.
by Einstein Toolkit 09 Jul '13

09 Jul '13

#1345: Cactus shouldn't mess with some flags after they have been setup. --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2013_11 Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- Currently Cactus sets up flags like CPPFLAGS or CFLAGS by adding e.g. CPP_OPENMP_FLAGS. However, later it overwrites these again by their original value in sbin/ProcessConfiguration.pl (search for FIXME). The attached patch implements what the 'FIXME' suggests - accepting the drawbacks that are mentioned there: that configuration settings not originating from a thorn might not be forwarded from e.g., a .cactus/config file. MPI was one of these, but this is now handled differently anyway. With this patch, we would need to be aware of these and might need to add them to @allowed_opts in the future. Without the patch however, compilation might fail for perfectly valid setups. One of these is when using openmp, setting all the corresponding *_OPENMP_FLAGS, but not setting CPPFLAGS (only CPP_OPENMP_FLAGS). In this case ProcessConfiguration.pl will set CFLAGS to the version in the config file (*without* the -openmp), but it will leave CPPFLAGS to the version *with* -openmp. This later leads to a linker error in external libraries, since compilation there uses CPPFLAGS (with openmp), but the linker doesn't (It correctly uses CFLAGS, but this doesn't have openmp flags here). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1345> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[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

[Einstein Toolkit] #456: Ensure functions are not defined twice
by Einstein Toolkit 08 Jul '13

08 Jul '13

#456: Ensure functions are not defined twice -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- When multiple source files define non-static functions with the same name, these are all compiled together into the resulting executable. Which one gets called is not predictable by the user. This can happen if a user copies a thorn, modifies it slightly, and compiles both thorns into the same configuration. This can lead to *very* difficult-to-find bugs, and it would be helpful if Cactus was able to prevent this, or at least to mitigate the problem. At the CST level, Cactus should be able to tell that there are two thorns which schedule functions with the same name. At the moment, this is not caught. I propose that this should be a fatal error, as there is no way to predict which function will be called eventually. This will solve the problem in some cases, but not in the case where there are instances of duplicate function names which are not scheduled. It should be possible to scan the object/library files using standard tools (nm etc) to determine if there are multiple globally visible symbols with the same name. There might even be standard tools for this purpose. Doing this in a portable way might not be straightforward, but having an implementation for Linux, for example, would catch the majority of cases. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/456> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1348: simfactory doesn't support multi-core setup using setup-silent
by Einstein Toolkit 07 Jul '13

07 Jul '13

#1348: simfactory doesn't support multi-core setup using setup-silent -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- It is easy to see why a complete multi-core setup using setup-silent isn't the best way to go. Editing the resulting file is usually so much more convenient. However, the attached patch adds the possibility to have the options --ppn and --num-threads being taken into account for setup-silent. --ppn sets 'ppn', 'max-num-threads' to it's value, and 'make' to 'nice make -j'+value. --num-threads sets 'num-threads'. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1348> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1195: Modify bisection algorithm in EOS_Omni's nuc_eos
by Einstein Toolkit 07 Jul '13

07 Jul '13

#1195: Modify bisection algorithm in EOS_Omni's nuc_eos -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- EOS_Omni's nuc_eos routines use a bisection method to find the temperature for a given internal energy. This bisects on the temperature T. I suggest to bisect on log T instead, which is a more natural operation. For example, if the temperature range is [1...1000] in some units, then bisecting in T will examine the sequence 500, 250, 125, ..., and will thus perform many table lookups until (say) T=10 is reached. Bisecting in log T will find this result much faster. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1195> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2013