Trac October 2015

trac@lists.einsteintoolkit.org

1 participants
109 discussions

[Einstein Toolkit] #1828: Script to collect AH shape information into one HDF5 file
by Einstein Toolkit 28 Oct '15

28 Oct '15

#1828: Script to collect AH shape information into one HDF5 file -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Attached is a python script which collects AH shape information and stores it into an HDF5 file. It also creates an xml file (xdmf), such that visit can open it without any special reader. The script itself works for python 2 and 3, and requires h5py to be present. It will search for all horizon shape files within the current directory, and consider all of them for inclusion. This could be turned into a command line option: feel free. Currently, the script requires one argument: a valid Cactus HDF5 file, intended to be from the same run and containing all time steps the horizon should be visualized in. The combined AH file(s) will contain the same time steps that are present in the input HDF5 file. If no horizons were found at a certain iteration, a dummy grid will be inserted - such that visit automatically merges time sliders even if horizons are not found at every output iteration. This script should probably go someplace within the AHFinderDirect thorn, as utility. Please suggest a better name if you don't like the current one. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1828> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #241: Thorns should be able to specify implementation versions, and other thorns should be able to depend on those
by Einstein Toolkit 26 Oct '15

26 Oct '15

#241: Thorns should be able to specify implementation versions, and other thorns should be able to depend on those -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Cactus thorns implement 'implementations', and other thorns can then depend on particular implementations being present. However, quite often those are updated, and incompatibilities occur. Usually this is resolved by the developer in both thorns - the implementing and the using thorn. However, a user might just update one of them, and Cactus would not catch this error. Thus, I suggest to think about, and implement how to: - specify implementation versions e.g. IMPLEMENTS: Cactus (4.0) The version string within () would have be sorted in an intelligent way to allow comparisons [1]. - specify dependencies on particular versions of other implementations In particular I suggest the following dependencies: depends, and conflicts, both with comparisons < <= == >= > != e.g. DEPENDS: Cactus (>= 4.0) DEPENDS: BadImplementation (!=3.14) <-- this introduces a dependency CONFLICTS: BadImplementation (==3.14) <-- this doesn't introduce a depencency [1] First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters. Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero. These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a difference is found or both strings are exhausted. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/241> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 27

[Einstein Toolkit] #1827: ML_BSSN::LapseACoeff and ML_BSSN::ShiftBCoeff Removed without Proper Deprecation
by Einstein Toolkit 26 Oct '15

26 Oct '15

#1827: ML_BSSN::LapseACoeff and ML_BSSN::ShiftBCoeff Removed without Proper Deprecation --------------------------+------------------------------------------------- Reporter: Zach Etienne | Owner: Type: defect | Status: new Priority: unset | Milestone: ET_2015_11 Component: Other | Version: development version Keywords: | --------------------------+------------------------------------------------- After pulling the latest ET, it appears that practically all of my parameter files no longer work. The reason is simple: ML_BSSN::LapseACoeff and ML_BSSN::ShiftBCoeff were removed in the McLachlan rewrite and not properly deprecated like all other renamed parameters. I found this because it broke the IllinoisGRMHD test suite. I am surprised and worried by my finding, because it appears that no other test suite parameter files set these ML_BSSN gauge parameters, so this was not caught earlier. Perhaps to prevent this from happening in the future, perhaps in some subset of our tests we should manually set *all* parameters in the test parfiles to their defaults. This way any bug in renaming parameters will be caught immediately. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1827> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1825: CCTK_ImpFromVarI sometimes returns the thorn name
by Einstein Toolkit 26 Oct '15

26 Oct '15

#1825: CCTK_ImpFromVarI sometimes returns the thorn name ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | ---------------------+------------------------------------------------------ I added the following debug code to one of my routines {{{ int n = CCTK_NumVars(); for(int v=0; v < n; ++v) { void *data = CCTK_VarDataPtrI(cctkGH,0,v); if(data == 0) continue; std::string imp = CCTK_ImpFromVarI(v); std::cout << "DEBUG: " << imp << "::" << CCTK_VarName(v) << std::endl; } }}} I get the following correct output from CartGrid3D DEBUG: GRID::x DEBUG: GRID::y DEBUG: GRID::z DEBUG: GRID::r However, I see this output from CarpetReduce DEBUG: CARPETREDUCE::weight DEBUG: CARPETREDUCE::excised_cells And I expected to see "REDUCE::weight" -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1825> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1831: Enable MPI in FFTW3
by Einstein Toolkit 25 Oct '15

25 Oct '15

#1831: Enable MPI in FFTW3 -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- If Cactus is built with MPI, enable the MPI bindings in FFTW3. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1831> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1824: shellcheck corrections for bash_utils.sh
by Einstein Toolkit 23 Oct '15

23 Oct '15

#1824: shellcheck corrections for bash_utils.sh -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- shellcheck (http://www.shellcheck.net/about.html; thanks Ian) provides a way to check for some common mistakes. I've run it on bash_utils.sh and corrected what it found. This mostly fixed hypothetical problems with spaces in paths and such (I doubt the rest of the infrastructure would be up for that, but that's no reason not to fix it). The attached path contains the changes. Thanks for reviewing. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1824> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1820: CarpetIOHDF5: Add option to compress data by hdf5_slicer utility
by Einstein Toolkit 22 Oct '15

22 Oct '15

#1820: CarpetIOHDF5: Add option to compress data by hdf5_slicer utility --------------------------------------+------------------------------------- Reporter: bmundim | Owner: eschnett Type: enhancement | Status: new Priority: unset | Milestone: Component: Carpet | Version: development version Keywords: CarpetIOHDF5 hdf5_slicer | --------------------------------------+------------------------------------- I would like to compress the data that I have just sliced with the hdf5_slicer utility in the CarpetIOHDF5 thorn. I added this option. Please take a look at this pull request: {{{ https://bitbucket.org/eschnett/carpet/pull-requests/6/carpetiohdf5-add- option-to-the-hdf5_slicer/diff }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1820> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1829: ExternalLibraries/MPI: increase verbosity when 'export VERBOSE=yes' is set
by Einstein Toolkit 21 Oct '15

21 Oct '15

#1829: ExternalLibraries/MPI: increase verbosity when 'export VERBOSE=yes' is set -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: ExternalLibraries MPI | -----------------------------------+---------------------------------------- Ticket #1667 touched on this issue a bit, but since I would like to see a solution just for the verbosity level and not a rewriting of how a external library should be reconfigured I think it is worth a ticket on its on. Currently if I set 'export VERBOSE=yes', the only message output I get from the MPI thorn is: {{{ Running configuration script for thorn MPI: Found MPI compiler wrapper at /usr/bin/mpic++! Successfully configured MPI. Finished running configuration script for thorn MPI. }}} while for other external library detect bash scripts I have a verbose output as requested: {{{ Running configuration script for thorn HDF5: + set -e + . /home/bruno/tmp/ET_test/Cactus/lib/make/bash_utils.sh + '[' -n '' ']' + HDF5_DIR_INPUT= ++ echo '' ++ tr '[a-z]' '[A-Z]' + '[' '' = BUILD ']' + HDF5_BUILD= + HDF5_C_LIBS='hdf5_hl hdf5' + '[' no = yes ']' + '[' yes = yes ']' + '[' gfortran '!=' none ']' + HDF5_FORTRAN_LIBS='hdf5hl_fortran hdf5_fortran' ... + echo 'INCLUDE_DIRECTORY $(HDF5_INC_DIRS)' + echo 'LIBRARY_DIRECTORY $(HDF5_LIB_DIRS)' + echo 'LIBRARY $(HDF5_LIBS)' Additional requested language support: Fortran HDF5 selected, but HDF5_DIR not set. Checking pkg-config ... HDF5 not found. Checking standard paths ... HDF5 not found. Using bundled HDF5... }}} One way of doing something similar in perl is using the module Devel::ebug* and write an utility in the lines of the one presented here: {{{ http://www.nntp.perl.org/group/perl.beginners/2008/03/msg99151.html }}} Would someone be interested in pursuing this path for debugging perl scripts in Cactus and then increasing its verbosity? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1829> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1823: HDF5 broken on Queen Bee
by Einstein Toolkit 21 Oct '15

21 Oct '15

#1823: HDF5 broken on Queen Bee ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | ----------------------+----------------------------------------------------- I see this output when building on Queen Bee with Simfactory's options: {{{ CST error 1: -> Configuration script for thorn HDF5 returned exit code 1 Error message: 'ERROR in HDF5 configuration: H5pubconf.h not found in /work/eschnett/Cvanilla/configs/sim- debug/scratch/external/HDF5/lib /work/eschnett/Cvanilla/configs/sim- debug/scratch/externa\ l/HDF5/include /work/eschnett/Cvanilla/configs/sim- debug/scratch/external/HDF5/lib' Additional requested language support: Fortran HDF5 selected, but HDF5_DIR not set. Checking pkg-config ... HDF5 not found. Checking standard paths ... HDF5 not found. Using bundled HDF5... ERROR: ERROR in HDF5 configuration: ERROR: H5pubconf.h not found in /work/eschnett/Cvanilla/configs/sim- debug/scratch/external/HDF5/lib /work/eschnett/Cvanilla/configs/sim- debug/scratch/\ external/HDF5/include /work/eschnett/Cvanilla/configs/sim- debug/scratch/external/HDF5/lib Finished running configuration script for thorn HDF5. }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1823> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #1796: Include IllinoisGRMHD into the Toolkit, as an Arrangement
by Einstein Toolkit 20 Oct '15

20 Oct '15

#1796: Include IllinoisGRMHD into the Toolkit, as an Arrangement -----------------------------------+---------------------------------------- Reporter: zachetie@… | Owner: Zachariah Etienne Type: enhancement | Status: new Priority: major | Milestone: ET_2015_11 Component: EinsteinToolkit thorn | Version: development version Keywords: GRMHD IllinoisGRMHD | -----------------------------------+---------------------------------------- IllinoisGRMHD, an open-source, compact rewrite of the Illinois NR group's GRMHD code, has been graciously hosted by the ET community in its BitBucket repo for more than a year, under the EinsteinEvolve arrangement. This ticket requests official inclusion of an updated IllinoisGRMHD and closely-related thorns into the ET, as an arrangement. IllinoisGRMHD brings a number of key new features to the Toolkit, including: 1) a staggered, vector-potential-based, AMR-compatible GRMHD scheme that automatically preserves divergenceless B-fields without the need for specialized interpolation schemes or divergence cleaning. 2) excision-less, robust modeling of GRMHD flows into black hole interiors 3) a highly-robust conservative-to-primitive solver, which checks the physicality of the conservative variables *prior* to inversion, and modifies them minimally to restore physicality. The proposed arrangement will include: 1) IllinoisGRMHD: Core GRMHD evolution routines, some significant bugfixes since the original version currently in the ET's bitbucket repo; about 3,400 lines of code (cloc) 2) ID_converter_ILGRMHD: Converts HydroBase variables into variables IllinoisGRMHD can read (e.g., IllinoisGRMHD uses a velocity definition consistent with the magnetic induction equation, not the Valencia formulation); about 209 lines of code (cloc) 3) convert_to_HydroBase: Does the reverse of ID_converter_ILGRMHD, needed for compatibility with HydroBase-based analysis thorns; 126 lines of code. All codes are written in C99 and are fully OpenMP-ified. You can read more about IllinoisGRMHD in its code announcement paper (CQG in press): http://arxiv.org/abs/1501.07276 Additionally, a Guide to Getting Started with IllinoisGRMHD has also been written and is available at the IllinoisGRMHD webpage: http://math.wvu.edu/~zetienne/ILGRMHD/ You may now download all three of these thorns (licensed GNU GPL v2 or higher) from: math.wvu.edu/~zetienne/IllinoisGRMHD_arrangement_July_20_2015.tar.gz -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1796> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 22

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac October 2015