Trac July 2014

trac@lists.einsteintoolkit.org

1 participants
127 discussions

[Einstein Toolkit] #1632: problem with compilation
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1632: problem with compilation -----------------------------------+---------------------------------------- Reporter: barmv | Owner: new user Type: defect | Status: new Priority: critical | Milestone: ET_2014_05 Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro Utils F90 | -----------------------------------+---------------------------------------- Ubuntu workstation, gcc and gfortran compilers. $./GetComponents --parallel https://svn.einsteintoolkit.org/manifest/branches/ET_2014_05/einsteintoolki… after that make the configuration $./simfactory/bin/sim setup --optionlist=ubuntu.cfg --runscript debian.sh but fail to do build of the project $./simfactory/bin/sim build ******************************************************************************** Running configuration script for thorn HWLOC: hwloc selected, but HWLOC_DIR not set. Checking some places... Found hwloc in /usr Finished running configuration script for thorn HWLOC. Checking consistency... Creating Thorn-Flesh bindings... Creating implementation bindings... Creating parameter bindings... Creating variable bindings... Creating schedule bindings... Creating function bindings... ------------------------------------------------------ There were 2 errors during execution of the CST These must be corrected before compilation can proceed ------------------------------------------------------ ------------------------------------------------------ Warnings were generated during execution of the CST ------------------------------------------------------ CST error 1: -> Configuration script for thorn FORTRAN returned exit code 1 Error message: 'Fortran thorn requires that a Fortran compiler is defined, but F77 = 'none' and F90 = 'none'. Aborting.' CST error 2: -> Configuration script for thorn LORENE returned exit code 1 (no error message) ------------------------------------------------------ make[1]: *** [/home/Cactus/configs/sim/config-data/make.thornlist] Error 1 make: *** [sim] Error 2 /////////////////////////////////////////////////////// After that $make config $make test1 $make test1 2&> test1_log.txt The compilation of the cactus report errors in file Cactus/configs/test1/build/GRHydro/Utils.f90 COMPILING arrangements/EinsteinEvolve/GRHydro/src/Utils.F90 Warning: Nonexistent include directory "/home/bmv/utils/soft/cactus/Cactus/arrangements/EinsteinEvolve/GRHydro/src/include" Warning: Nonexistent include directory "/home/bmv/utils/soft/cactus/Cactus/arrangements/EinsteinEvolve/GRHydro/src/include" /home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2879.10: pointer (pg11,g11), (pg12,g12), (pg13,g13), (pg22,g22), (pg23,g23), (pg33,g33) 1 Error: Cray pointer declaration at (1) requires -fcray-pointer flag /home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2882.8: pg11 = loc(gaa) 1 Error: Symbol 'pg11' at (1) has no IMPLICIT type /home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2883.8: pg12 = loc(gab) 1 Error: Symbol 'pg12' at (1) has no IMPLICIT type /home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2884.8: pg13 = loc(gac) 1 Error: Symbol 'pg13' at (1) has no IMPLICIT type /home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2885.8: pg22 = loc(gbb) 1 Error: Symbol 'pg22' at (1) has no IMPLICIT type /home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2886.8: pg23 = loc(gbc) 1 Error: Symbol 'pg23' at (1) has no IMPLICIT type /home/bmv/utils/soft/cactus/Cactus/configs/test1/build/GRHydro/Utils.f90:2887.8: pg33 = loc(gcc) 1 Error: Symbol 'pg33' at (1) has no IMPLICIT type make[3]: *** [Utils.F90.o] Error 1 make[2]: *** [make.checked] Error 2 make[1]: *** [/home/Cactus/configs/test1/lib/libthorn_GRHydro.a] Error 2 make: *** [test1] Error 2 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1632> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1636: check and abort if more timelevels are requested than time hierarchy supports
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1636: check and abort if more timelevels are requested than time hierarchy supports -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------+-------------------------------------------------- In order to provide a more user friendly fix for #626 we want to change Carpet (and PUGH?) such that they check at runtime, when memory is allocated that the number of requested timelevels is less or equal than what the time hierarchy (controlled by the max_timelevels) parameter supports. This check should be done early and should take the checkpoint tag as well as prolongation operator tags into account. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1636> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1639: CCTK_ATTRIBUTES
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1639: CCTK_ATTRIBUTES -----------------------+---------------------------------------------------- Reporter: anonymous | Owner: jtao Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -----------------------+---------------------------------------------------- In CommOverloadables.h #define ATTRIBUTES CCTK_ATTRIBUTE_NORETURN OVERLOADABLE(Exit) OVERLOADABLE(Abort) Exit and Abort are defined as functions returning an integer, but they are explicitly set with noreturn in CommOverloadables.h. This will also cause a warning for CCTK_VError (was set attribute as no return in the definition too), which calls CCTK_Abort that returns an integer. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1639> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1644: create defs.local.ini when it does not exist
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1644: create defs.local.ini when it does not exist -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- simfactory needs to be configured before it can be used even on a machine that is in the machine database. This can be done by copying and editing an existing defs.local.ini or by calling "sim setup". Since simfactory cannot function without this setup procedure (since not all of the machine.ini files set eg email and user keys), simfactory should detect if defs.local.ini is missing and offer to enter setup if this is the case. This would be closer to how most unix tools work, that create a functioning, default rc file when they are first started. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1644> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1647: simfactory default for <1 node jobs
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1647: simfactory default for <1 node jobs ------------------------+--------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- The following options {{{ --procs 2 --num-threads 2 }}} currently request a full node (ppn in the submitscript is higher than 2, if available). This is very surprising. By default, simfactory should not request more cores than a user asks for. I understand that on some clusters it is necessary to request full nodes, but then this should be implemented in the respective scripts for that cluster. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1647> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1648: MPI thorn should auto configure
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1648: MPI thorn should auto configure -----------------------------------+---------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Cactus_4.3.0 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The attached patch upgrades the MPI configuration thorn in a number of ways. First, and most importantly, it automatically configures mpi based on information obtained from mpicc when MPI_DIR isn't specified. Configuration is only disabled by setting MPI_DIR = NONE. In addition to MPI_INSTALL_DIR, it will look at CACTUS_EXT_INSTALL_DIR. Frank says that at one point a general external directory for applications was discussed. My feeling is that having the install land in configs is usually not what people want. This version emits an error message if you set MPI_DIR to BUILD, but don't set one of the above install dirs. If you really want MPI under configs, you can set MPI_INSTALL_DIR=CONFIGS. I anticipate pushback on my MPI_DIR=NONE, and MPI_INSTALL_DIR=CONFIGS suggestions, but I thought I'd suggest them regardless. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1648> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 21

[Einstein Toolkit] #1039: Web-based documentation should be automatically updated
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1039: Web-based documentation should be automatically updated -------------------------------------+-------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Keywords: Documentation | -------------------------------------+-------------------------------------- We have documentation for Cactus and the ET on their respective websites. This should be updated automatically when the source is changed, so it is never out of date. There should be documentation for the current release as well as the current development version. There is one technical problem standing in the way of this. The system should be automated, and it needs to have commit rights to a specific directory in the SVN repository hosting the files. SVN accounts for CCT machines tend to be the same as CCT login accounts, so we don't want to store the username and password. I think the best solution is to create an SVN account specifically for the documentation build system which is not tied to a CCT login account. This account would be given commit access to just the directories necessary. The "checkout, build doc, commit" script should be kept in version control somewhere, and a machine should be chosen on which to run it. It could be run regularly, or just in response to commits. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1039> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1487: Documentation build should be tested as part of the automated build and test
by Einstein Toolkit 08 Dec '14

08 Dec '14

#1487: Documentation build should be tested as part of the automated build and test --------------------+------------------------------------------------------- Reporter: hinder | Owner: hinder Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- The build of the ET documentation should be tested as part of the automated build and test. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1487> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #791: Output timer tree as XML
by Einstein Toolkit 08 Dec '14

08 Dec '14

#791: Output timer tree as XML -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- The attached patch to Carpet adds a parameter (off by default) which outputs the timer tree from each process to an XML file in the output directory at the end of the run. The output looks like this: {{{ <timer name = "main"> 7.7702 <timer name = "CallFunction"> 0.000241 <timer name = "thorns"> 0.000233 <timer name = "CaKernel_FreeDevMem"> 0.000221 <timer name = "PostCall"> 2e-06 </timer> <timer name = "PreCall"> 1e-06 </timer> </timer> </timer> </timer> <timer name = "CarpetStartup"> 0.00982 <timer name = "AllocateGridHierarchy"> 5e-06 </timer> }}} An alternative schema would be to have the name and timer value as subelements; i.e. {{{ <timer> <name>main</name> <value>7.7702</value> <children> <timer> <name>CallFunction</name> <value<0.000241</name> ... </timer> }}} The <children> tag might not be necessary, but might make it easier to parse. Having one file per process is not ideal; we would like to add reductions across processes to give min, max, average, standard deviation etc, also for the standard output display. OK to commit as a work-in-progress? We can change the schema later if it turns out to be easier to deal with. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/791> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

[Einstein Toolkit] #727: Test output changes every time some tests are run
by Einstein Toolkit 08 Dec '14

08 Dec '14

#727: Test output changes every time some tests are run -----------------------------------------------------------+---------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: testsuites QuasiLocalMeasures IDAxiOddBrillBH | -----------------------------------------------------------+---------------- Each time a new run of the test suites is performed, the test output of IDAxiOddBrillBH and QuasiLocalMeasures changes a little. These changes are below the tolerances set in the test.ccl files, so the tests pass, but there should be no change at all when the tests are run on the same machine. An example of the difference from one test run to the next is shown at http://git.barrywardell.net/EinsteinToolkitTestResults.git/blobdiff/95fe088…. Another example, from QuasiLocalMeasures, is at http://git.barrywardell.net/EinsteinToolkitTestResults.git/blobdiff/95fe088… /qlm-ks-shifted/admbase::metric.average.asc. The only thorns to exhibit this behaviour are IDAxiOddBrillBH and QuasiLocalMeasures. All other test data remains unchanged from one test run to the next. Note that the two test runs will be performed with different executables, since a new configuration is created for each run. I think I remember testing that simply re-running the same executable resulted in the same test output. Is it possible that there are a small number of points which access uninitialised memory which changes on each run for these thorns? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/727> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2014