Trac December 2014

trac@lists.einsteintoolkit.org

1 participants
153 discussions

[Einstein Toolkit] #1630: ML_BSSN harmonic shift is ill-posed
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1630: ML_BSSN harmonic shift is ill-posed -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The implementation of the ML_BSSN harmonic shift is ill-posed. It should use the evolved Gamma variables instead of taking metric derivatives. A robust stability test clearly shows an instability: higher resolutions have faster growing errors. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1630> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[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] #1654: All accessible Cactus flesh functions should either be documented or deprecated
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1654: All accessible Cactus flesh functions should either be documented or deprecated -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- There are some Cactus flesh functions which are not documented, and it is unclear the extent to which these are supported. The following command is one way to see the symbols provided to an executable by the Cactus flesh (there might be better or more accurate ways of doing this): {{{ find configs/sim/build/Cactus -name "*.o"|xargs nm -g | grep -v ' U '|less }}} After removing CCTKi symbols etc, this list of symbols should be cross- referenced with the documentation and a decision should be made for any undocumented functions. This is also a good way to find out about symbols which have been declared in the global namespace unintentionally. One could also imagine having a text file with a list of all the supported function symbols, and the automated test system checking that no additional functions are exported into the global namespace. This is not a high priority, but since I thought of it, I made the ticket anyway. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1654> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1662: Only ask once for auth info for bitbucket/github
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1662: Only ask once for auth info for bitbucket/github ---------------------------+------------------------------------------------ Reporter: knarf | Owner: eric9 Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ Maybe only for the special case of "big" services like bitbucket and github, only ask once for the auth info in GetComponents. While I can see that in theory somebody could use a different login for different projects, I think this would be highly unlikely in practice. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1662> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1664: CarpetIOHDF5 should not try to search for grid scalar s and DSITRIB=CONSTANT arrays in all hdf5 files
by Einstein Toolkit 09 Dec '14

09 Dec '14

#1664: CarpetIOHDF5 should not try to search for grid scalar s and DSITRIB=CONSTANT arrays in all hdf5 files --------------------------+------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: CarpetIOHDF5 | --------------------------+------------------------------------------------- Currently, if during a checkpoint recovery a grid scalar or DISTRIB=CONSTANT grid array is not found in the first file, then CarpetIOHDF5 will eventually open and parse all file looking for this dataset. This happens eg when one activates a new thorn with a checkpointed scalar or also when a new code version of a thorn that declares new checkpointed variables is used. Also, the current behaviour is that grid variables that are not found at all (as compared to grid variables for which only some but not all components are found) are silently ignored. Finally, the current checkpointing code will write a copy of grid scalars and DISTRIB=CONSTANT grid arrays in every single checkpoint file, which means that, for a valid set of checkpoint files, if the grid variable is not found in the first file it will also never be found in any of the other files. The ticket is thus an enhancement request to have CarpetIOHDF5 stop searching for the grid variable after the first file. This will not change the behaviour of any current checkpoint files but will speed up the case where a grid variable is missing. This will either speed up a final error report (if eg a thorn was using the missing data and reports poisoned data) or the restart with extra thorns significantly. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1664> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2014