Trac November 2014

trac@lists.einsteintoolkit.org

1 participants
159 discussions

[Einstein Toolkit] #1204: carpet bug
by Einstein Toolkit 22 Mar '15

22 Mar '15

#1204: carpet bug -------------------------------------+-------------------------------------- Reporter: abdik@… | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | -------------------------------------+-------------------------------------- The latest version of carpet seems to contain a bug that affects AMR+multipatch runs. My stderr and stdout and par file are attached. Found by Roland and Ernazar. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1204> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #997: problem in appending output after recovery
by Einstein Toolkit 22 Mar '15

22 Mar '15

#997: problem in appending output after recovery ----------------------------------------+----------------------------------- Reporter: corvino.giovanni@… | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | ----------------------------------------+----------------------------------- I have a problem in appending output files from Carpet. I used to produce 3d HDF5 output of grid variables and write the output in the same directory also after recovery from checkpoint. The new output was automatically appended to the existing one. Now I am producing h5 output also on 2D slices but in this case the output is overwritten so I lost the data for all but the last recovery. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/997> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1624: remove MOLDOESCOMPLEX from MoL
by Einstein Toolkit 02 Feb '15

02 Feb '15

#1624: remove MOLDOESCOMPLEX from MoL -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- MOLDOESCOMPLEX is an old #define in MoL, and seems to be unused for quite some time now. It also comes with the comment "even using it probably doesn't work" in the commit. I suggest to remove it (removing the code within). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1624> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1518: Parameter parser and CCTK_ParameterSet interpret leading zeros in numbers differently
by Einstein Toolkit 28 Jan '15

28 Jan '15

#1518: Parameter parser and CCTK_ParameterSet interpret leading zeros in numbers differently --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- the parameter parser allows things like: {{{ thorn::param1 = 011 thorn::param2 = 012.34 }}} in parameter files. For floating point values this is a bit unexpected but otherwise mostly harmless. For integers the situation is a bit more complex since in C a leading zero is used to indicate a octal number. And (worse) while the parameter file parser converts the string "011" to the number 11 the Cactus call CCTK_ParameterSet will convert it to 9. The difference is ultimately the difference between calling atof (Parser) and strtol (CCTK_ParameterSet). To avoid confusion it would likely be good to change CCTK_ParameterSet to behave the way the Parameter parser does. This is a change in behaviour compared to the pre-Piraha parser, however I suspect the number of users that actually used octal (or hexedecimal) notation in their parameter files is small. The change is to change {{{inval = strtol (value, &endptr, 0);}}} to {{{inval = strtol (value, &endptr, 10);}}} in line 2209 of src/main/Parameters.c and similar in line 2270. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1518> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 27

[Einstein Toolkit] #1700: Use 64-bit integers when building PETSc
by Einstein Toolkit 26 Jan '15

26 Jan '15

#1700: Use 64-bit integers when building PETSc -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- PETSc needs to be able to count up to the total (global) number of points it uses, not just process-local points. 32-bit integers are not sufficient for large runs. Note that e.g. Carpet already uses 64-bits integers for the same reason. I suggest to enable the respective option when building PETSc by default. TATPETSc supports this, other thorns may need to be updated. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1700> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1694: try using fast fowards when accepting pull requests
by Einstein Toolkit 26 Jan '15

26 Jan '15

#1694: try using fast fowards when accepting pull requests -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- For small single change pull requests have a full git merge in the history can be annoying since it clutter the history view (it uses up two lines, it may show connecting both branches existing at the same time even if there are no commits on master during that time). We could try and instead find out if bitbucket can be made to allow fast forwards in the pull request merge (https://bitbucket.org/site/master/issue/6106/forced-non-fast-forward- merge-of-pull). Currently apparently bitbucket uses --no-ff ie it disallows fast forwards. We could even think about forcing fast forwards only (https://bitbucket.org/site/master/issue/9589/force-fast-forward-only- merges-on-pull). This does however not work so well for big "feature" branches that are brought back into master and where a fast forward may fail and/or require extensive rebasing of the feature branch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1694> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[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] #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

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2014