Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet
by Einstein Toolkit 19 Oct '11

19 Oct '11

#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- The CarpetReduce tests nonstaggered and staggered fail with the development version of Carpet and pass with the stable version. The failure is reported as: weight.d.asc: substantial differences did not reproduce 3 NaNs from old weight.d.asc significant differences on 3 (out of 9) lines Were the NaNs wrong before, and somehow got into the test output incorrectly? Or are the NaNs supposed to be there? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/494> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #414: --parallel option not documented in GetComponents
by Einstein Toolkit 19 Oct '11

19 Oct '11

#414: --parallel option not documented in GetComponents ---------------------------+------------------------------------------------ Reporter: bmundim | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ The --parallel option is not documented in both versions of GetComponents, the released and development ones. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/414> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #219: ExternalLibraries method should be documented
by Einstein Toolkit 19 Oct '11

19 Oct '11

#219: ExternalLibraries method should be documented ---------------------------+------------------------------------------------ Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: documentation | ---------------------------+------------------------------------------------ The Cactus documentation http://einsteintoolkit.org/info/documentation/UsersGuide/UsersGuidech6.html… (scroll down to Compiling with Extra Packages) currently tells people to use the "extras" method for enabling access to external libraries such as HDF5, MPI etc. As I understand it, this method is deprecated in favour of the ExternalLibraries method, and both should not be used at the same time for the same library. The documentation should be updated to describe the ExternalLibraries method, and the old method description should be moved to an appendix with a clear warning that this is deprecated. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/219> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #206: Add --xml option to GetComponents
by Einstein Toolkit 19 Oct '11

19 Oct '11

#206: Add --xml option to GetComponents ---------------------------+------------------------------------------------ Reporter: eric9 | Owner: eric9 Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ GetComponents should support machine readable output using XML. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/206> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #615: updating git repositories fails for git version 1.6.5.3
by Einstein Toolkit 19 Oct '11

19 Oct '11

#615: updating git repositories fails for git version 1.6.5.3 ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ trying to update a git repository with GetComponents (eg. einsteintoolkit.th) I get (using : {{{ ----------------------------------------------------------------- Updating module: GetComponents from repository: git://github.com/gridaphobe/CRL.git located in: ./bin Executing: git status --porcelain --untracked-files=no In: /home/rhaas/ET_2011_10/./repos/CRL error: unknown option `porcelain' usage: git status [options] [--] <filepattern>... -q, --quiet be quiet -v, --verbose be verbose Commit message options -F, --file <FILE> read log from file --author <AUTHOR> override author for commit -m, --message <MESSAGE> specify commit message -c, --reedit-message <COMMIT> reuse and edit message from specified commit -C, --reuse-message <COMMIT> reuse message from specified commit -s, --signoff add Signed-off-by: -t, --template <FILE> use specified template file -e, --edit force edit of commit Commit contents options -a, --all commit all changed files -i, --include add specified files to index for commit --interactive interactively add files -o, --only commit only specified files -n, --no-verify bypass pre-commit hook --dry-run show what would be committed --amend amend previous commit -u, --untracked-files[=<mode>] show untracked files, optional modes: all, normal, no. (Default: all) --allow-empty ok to record an empty change --cleanup <default> how to strip spaces and #comments from message Executing: git stash In: /home/rhaas/ET_2011_10/./repos/CRL No local changes to save Executing: git remote update origin In: /home/rhaas/ET_2011_10/./repos/CRL Updating origin Executing: git branch In: /home/rhaas/ET_2011_10/./repos/CRL * master Executing: git pull --rebase origin master In: /home/rhaas/ET_2011_10/./repos/CRL && git checkout master Already on 'master' From git://github.com/gridaphobe/CRL * branch master -> FETCH_HEAD Current branch master is up to date. Executing: git checkout master In: /home/rhaas/ET_2011_10/./repos/CRL Already on 'master' Executing: git stash pop In: /home/rhaas/ET_2011_10/./repos/CRL Nothing to apply Warning: Could not update CRL. Could not pop stashed changes. }}} it seems the --porcelain option does not exisit in version 1.6.5.3. If this affects all versions of git before 1.6.5.3 as well then eg. ranger is affected. Can the same functionality be achieved without it? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/615> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #481: Tests should be converted to use new symmetry thorns
by Einstein Toolkit 19 Oct '11

19 Oct '11

#481: Tests should be converted to use new symmetry thorns -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- It was decided (http://cactuscode.org/pipermail/developers/2010-September/006087.html) that the built-in CartGrid3D symmetries are deprecated and will not work with the Mercurial version of Carpet. Any test cases that use Grid::domain != "full" should be modified to use ReflectionSymmetry instead. In general, this should be possible without regenerating the test output. However, for the case of AHFinderDirect, the horizon finder actually uses a different internal multipatch grid structure if it detects that a CartGrid3D symmetry is being used. This means that the horizon shapes and quantities are different at the level of numerical error with ReflectionSymmetry. I propose to convert the tests to use ReflectionSymmetry and regenerate the test data (the grid function phi is the same with the new symmetry thorn, it's only the horizons which are different). The failing tests are related to checkpoint and recovery, and are not designed to test the symmetry mechanism. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/481> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #395: Thorns providing interpolator routines should provide testcases for them
by Einstein Toolkit 18 Oct '11

18 Oct '11

#395: Thorns providing interpolator routines should provide testcases for them -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2011_11 Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- Errors in the interpolator often show up in the output of other thorns, depending on those interpolating routines. Figuring out that this is caused by problem while interpolating can take quite a bit of time, which could be saved if the interpolating thorns would include testsuites themselves. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/395> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #369: Add command to update thorn list
by Einstein Toolkit 18 Oct '11

18 Oct '11

#369: Add command to update thorn list ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ When the thorn list changes, then I have to run GetComponents --update twice: first to update the thorn list, and then to actually check out these thorns. Currently, I have to update all thorns twice, which is a waste of time. Ideally, GetComponents would first update the thorn list, then update itself, then update everything else, and thus perform three passes over the thorn list, but not perform the work three times. Can we achieve this somehow? For example, we could mark the CRL script and the thorn lists with special tags, and GetComponents would then perform the work in three stages, restarting in between. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/369> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #629: Allow parameters to be marked as deprecated in param.ccl files
by Einstein Toolkit 18 Oct '11

18 Oct '11

#629: Allow parameters to be marked as deprecated in param.ccl files -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Parameters often need to be deprecated. For backwards compatibility, the best thing to do in this situation is to accept the old parameter and print a warning that the parameter is deprecated, and what other parameter should be used instead. Writing code to handle this in each case is redundant. I propose that there should be some way of indicating in the param.ccl file that a given parameter is deprecated. One possibility would be: {{{ BOOLEAN out3D_ghosts "Output ghost zones" STEERABLE = ALWAYS DEPRECATED = yes DEPRECATIONMESSAGE = "This parameter will be removed in a future release. Please use XXXX instead." { } "yes" }}} Cactus would then detect if the user had explicitly set that parameter and, if so, it would print a warning in paramcheck along the lines of Parameter CarpetIOHDF5::out3D_ghosts is deprecated. Please use XXXX instead. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/629> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #616: Carpet breaks backwards-compatibility with parameter files
by Einstein Toolkit 18 Oct '11

18 Oct '11

#616: Carpet breaks backwards-compatibility with parameter files --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2011_10 Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- In the mercurial version of Carpet, the parameter Carpet::poison_value has been removed. This breaks any existing parameter files which use this (I have a large number). To avoid unnecessary pain, I propose that the parameter be reinstated. It can print a deprecation warning, and doesn't have to do anything. I think we should aim to achieve backwards-compatibility with code and parameter files as much as possible, especially when it is trivial to do so. The parameter can be removed for good in a later release, if it is felt that it clutters up the code too much. I think there was a CarpetLib poison parameter which also changed, but I don't remember what it was. This should apply to that one as well. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/616> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac