Trac January 2015

trac@lists.einsteintoolkit.org

1 participants
123 discussions

[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] #1729: Switch Carpet to new bboxset class implementation
by Einstein Toolkit 26 Jan '15

26 Jan '15

#1729: Switch Carpet to new bboxset class implementation -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------+-------------------------------------------------- Carpet has a new bboxset class implementation that scales to much larger number of MPI processes. I suggest to make the new implementation the default. This is currently disabled, and can be enabled by adding the two flags "-DCARPET_ENABLE_BBOXSET2 -DCARPET_USE_BBOXSET2" to CPPFLAGS. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1729> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[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] #1727: Support CCTK_INT16
by Einstein Toolkit 26 Jan '15

26 Jan '15

#1727: Support CCTK_INT16 -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- I suggest to add support for 16-byte integers to Cactus. I have created the respective patches and put them into "eschnett/int16" branches of the flesh and various arrangements, including CactusBase, CactusPUGH, and Carpet. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1727> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1739: Cactus and Einstein Toolkit bitbucket repositories should not allow rewrites of master
by Einstein Toolkit 26 Jan '15

26 Jan '15

#1739: Cactus and Einstein Toolkit bitbucket repositories should not allow rewrites of master -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Server Infrastructure | Version: development version Keywords: | -----------------------------------+---------------------------------------- Cactus and Einstein Toolkit bitbucket repositories should not allow rewrites of master. This can be changed in the bitbucket settings, but it is tedious to do this for all repos. A script should be written to control this setting. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1739> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1733: Certificate on jenkins web server has expired
by Einstein Toolkit 26 Jan '15

26 Jan '15

#1733: Certificate on jenkins web server has expired -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Server Infrastructure | Version: development version Keywords: | -----------------------------------+---------------------------------------- The certificate on https://build.barrywardell.net has expired. There were problems with the renewal process at StartSSL. We are aware of the issue and are looking into a solution. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1733> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[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] #1741: PAPI defines global functions and variables without PAPI_ prefix
by Einstein Toolkit 22 Jan '15

22 Jan '15

#1741: PAPI defines global functions and variables without PAPI_ prefix -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: PAPI | -----------------------------------+---------------------------------------- In its stats.c source file (which gets compiled into the thorn), PAPI defines several globally visible symbols, eg: {{{ void outinfo(const char *const function) ... int num_threads; }}} which are not prefixed with the thorn name so possibly conflict with other thorns. According to the Cactus user guide http://einsteintoolkit.org/documentation/UsersGuide/UsersGuidech9.html#x13-… users are suggested to prefix them by the thorn name (or put into a C++ namespace) to avoid conflicts. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1741> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1740: GRHydro ReconstructPolytype.F90 passes wrong arguments to SimplePPM(M)_1d
by Einstein Toolkit 21 Jan '15

21 Jan '15

#1740: GRHydro ReconstructPolytype.F90 passes wrong arguments to SimplePPM(M)_1d -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: knarf Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro | -----------------------------------+---------------------------------------- Zach Etienne found (last year on August already) that > In GRHydro_ReconstructPoly.F90, notice that after gzz in the SimplePPM_1d() > and SimplePPM_1dM() function calls, psi4 is passed. However, if you look at > the SimplePPM_1d() and SimplePPM_1dM() routines (within GRHydro_PPM.F90), > you will find that psi4 is not a variable in the function call list, and > beta^i should come after gzz, for flux_direction i. Pull request https://bitbucket.org/einsteintoolkit/einsteinevolve/pull- request/6/fix-usage-of-psi4-in-polytype/diff fixes this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1740> 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