Trac January 2015

trac@lists.einsteintoolkit.org

1 participants
123 discussions

[Einstein Toolkit] #1663: VisIT CarpetHDF5 plugin pseudocolor error
by Einstein Toolkit 20 Jan '15

20 Jan '15

#1663: VisIT CarpetHDF5 plugin pseudocolor error ---------------------------------------+------------------------------------ Reporter: bruno.giacomazzo@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: visit | ---------------------------------------+------------------------------------ This problem has been present since the CarpetHDF5 plugin for VisIt became part of the standard VisIt distribution and it is still present in the current version of VisIt (2.8). When Pseudocolor is used in log scale and Centering is set to Original or Nodal, not all the values of the plotted quantity are shown (in particular lower values are not plotted at all). This does not happen if one sets Centering to Zonal, which instead shows the correct values. I have attached a couple of images showing the problem (they show hydrobase::rho for a BNS run). I do not know what may be causing it, but it may cause serious errors when analyzing data with VisIt (since one may miss some of the information on the low value regions). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1663> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1635: hwloc requires a certain minimum version, but does not check for it
by Einstein Toolkit 20 Jan '15

20 Jan '15

#1635: hwloc requires a certain minimum version, but does not check for it --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2014_11 Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Currently, hwloc's configuration.sh searched for any hwloc library and uses it. However, it requires a pretty new version within some of its own files, which leads to build failure on, e.g. Debian stable systems. The attached patch uses pkg-config to get the version of the installed hwloc library and if that version is older than 1.6 (educated guess, but see http://lists.einsteintoolkit.org/pipermail/users/2013-February/002860.html), builds the bundled version even if another version is installed (but too old). Note that this is done (intentionally) only if no library was specified, and the script was looking for it by itself. This allows users to specify something which will not be overwritten by this mechanism. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1635> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #1704: redirect stdout and stderr of all processes if requested (also of the root process)
by Einstein Toolkit 19 Jan '15

19 Jan '15

#1704: redirect stdout and stderr of all processes if requested (also of the root process) -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently Cactus only redirects, when asked, stdout and stderr to files for processes other than the root process. The patch lets Cactus also write stdout and stderr for the root process. https://bitbucket.org/cactuscode/cactus/pull-request/2/redirect-stdout- and-stderr-of-all/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1704> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #1738: Update requirements documentation for Cactus
by Einstein Toolkit 16 Jan '15

16 Jan '15

#1738: Update requirements documentation for Cactus ---------------------------+------------------------------------------------ Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: documentation | ---------------------------+------------------------------------------------ The Cactus User Guide has a section "Required software" which lists the software needed for Cactus. I think this should list the various language versions which are needed. For example, we could say (if this is the case) that Cactus requires C99 and C++98 or later. The page probably also should be updated to replace SVN with Git. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1738> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1702: AEILocalInterp and LocalInterp should output scheduled function name in error messages
by Einstein Toolkit 15 Jan '15

15 Jan '15

#1702: AEILocalInterp and LocalInterp should output scheduled function name in error messages ----------------------------------------------------------------+----------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: AEILocalInterl LocalInterp CarpetInterp PUGHInterp | ----------------------------------------------------------------+----------- the local interpolation routines abort if an interpolation cannot be performed since the interpolation coordinates lie outside of the patch of data they are given eg. {{{ WARNING level 1 in thorn AEILocalInterp processor 0 (line 1109 of arrangements/AEIThorns/AEILocalInterp/src/Lagrange-tensor- product/../template.c): -> CCTK_InterpLocalUniform(): interpolation point is either outside the grid, or inside but too close to the grid boundary! (this may be caused by a global interpolation with driver::ghost_size too small) 0-origin interpolation point number pt=54181 of N_interp_points=54182 interpolation point (x,y,z)=(45.3992,15.5856,2.93915e-15) grid x_min(delta_x)x_max = -0.198(0.066)1.584 grid y_min(delta_y)y_max = -0.198(0.066)1.518 grid z_min(delta_z)z_max = -0.198(0.066)1.452 }}} However, if there are mutliple thorns that may call the interpolator it is no always clear which caller was active when the error occured (eg it may be the apparent horizon finder or the puncture tracker). It would be nice if the interpolators were to report the currently executing scheduled routine's name via CCTK_ScheduleQueryCurrentFunction. That routine currently takes cctkGH as an argument but does not actually use it. Thus, given the possible benefit, it would be acceptable I think to call the routine with a NULL pointer (and a comment that this is strictly not valid). An alternative, which may be nicer, would be to have the driver add an entry "cctkGH" to the table passed to {{{CCTK_InterpLocalUniform}}} in its {{{param_table_handle}}}. The local interpolator can then savely use this pointer if provided and (with an appropriate loud warning) fall back to passing NULL if it is not found (and stop the fallback once the flesh routine actually uses cctkGH). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1702> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1728: Remove CACHE_SIZE etc. from configure
by Einstein Toolkit 15 Jan '15

15 Jan '15

#1728: Remove CACHE_SIZE etc. from configure -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Configure cannot reliably detect CACHE_SIZE since this may be different on build nodes and compute nodes. Thorn hwloc provides a reliable, portable run-time solution. CACHE_SIZE is not currently used either. I suggest to remove it from configure. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1728> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1736: avoid using Fotran compiler to link Riemann1d utility
by Einstein Toolkit 15 Jan '15

15 Jan '15

#1736: avoid using Fotran compiler to link Riemann1d utility -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro | -----------------------------------+---------------------------------------- GRHydro contains a Riemann1d utility which contains a Fotran90 main program. Unfortunately some of the libraries we link against use C++ code and the F90 compiler fails to link the executable (missing vtables, constructors etc). Since the C++ compiler cannot link the main executable either (since it does not know how to start the main Fotran program), the attached patch adds a stub main() function that calls the previous F90 code as a subroutine. Most of the changes are to the build files to make a utility that needs preprocessed C code (for CCTK_FNAME) and contains multiple object files. Pull request is: https://bitbucket.org/einsteintoolkit/einsteinevolve /pull-request/5/grhydro-add-c-main-function-for-riemann1d/diff though given that this is a single commit I'd much rather have it be applied than to get a merge for a single commit. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1736> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1735: support FFTW3_LIBS FFTW3_INC_DIRS FFTW3_LIB_DIRS in FFTW3 ExternalLibrary
by Einstein Toolkit 14 Jan '15

14 Jan '15

#1735: support FFTW3_LIBS FFTW3_INC_DIRS FFTW3_LIB_DIRS in FFTW3 ExternalLibrary -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: FFTW3 | -----------------------------------+---------------------------------------- Right now FFTW3 claims to support FFTW3_LIBS (in configuration.ccl) but ignores the user provided value and always uses fftw3, it does not allow FFTW3_INC_DIRS or LLTW3_LIB_DIRS to be set at all. The attached patch changes this such that if those variables are specified in the option list, they override whatever detect.sh may want to use. This can be used to make use of the fftw implementation inside of MKL which stores its include files inside $MKL_ROOT/include/fftw and which should be used by sepcifying jsut {{{-mkl}} to the compiler rather than an actual library file. This is a bug since FFTW3_LIBS is documented but does not behave as documented. It is major since this should be fixed before the next release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1735> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1734: New Carpet thorns CarpetTest, TestBBoxSet2, TestTimers2
by Einstein Toolkit 13 Jan '15

13 Jan '15

#1734: New Carpet thorns CarpetTest, TestBBoxSet2, TestTimers2 -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- I suggest to add the three existing thorns CarpetTest, TestBBoxSet2, TestTimers2 to the Einstein Toolkit. They contain tests for Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1734> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1724: Don't require configuration name in 'make CONFIG' if only one configuration is present
by Einstein Toolkit 12 Jan '15

12 Jan '15

#1724: Don't require configuration name in 'make CONFIG' if only one configuration is present -------------------------+-------------------------------------------------- Reporter: knarf | Owner: knarf Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- For example 'make' after this pull request works if only one configuration is present. Otherwise a message would be output to tell the user to use 'make sim' (for example) - which is kind of pointless because at that point make "knew" already what was meant. It could, and should, just do it. https://bitbucket.org/cactuscode/cactus/pull-request/6/dont-require- configuration-name-when-only/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1724> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac January 2015