Trac August 2011

trac@lists.einsteintoolkit.org

1 participants
182 discussions

[Einstein Toolkit] #120: Improve built-in help system
by Einstein Toolkit 08 Feb '12

08 Feb '12

#120: Improve built-in help system -------------------------+-------------------------------------------------- Reporter: hinder | Owner: mthomas Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- SimFactory currently provides a single help screen when you type "sim help". I would like to be able to do "sim help <command>" and get help which is relevant for that command. This help should say briefly what the command does, and give a comprehensive list of the options specific to that command. The top-level "sim help" command should then give a list of the commands, and a list of the simfactory options which apply to all commands. This first help page should be kept as brief as possible so that it is easy to see at a glance what commands are available. The most common commands should be listed first, and maybe separated from the less common commands. I think this is important as it is the first port-of-call when someone wants to know how to use a particular feature, especially when the syntax is similar but not quite the same as in SimFactory 1. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/120> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #543: Change diff format in GetDomponents
by Einstein Toolkit 05 Feb '12

05 Feb '12

#543: Change diff format in GetDomponents ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: enhancement | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ It would be convenient to change the format of GetComponent's --diff command to output diffs that can be directly applied via "patch -p0" from the main Cactus directory. That is, file names such as "a/Tools/CodeGen/Schedule.m" should be changed to "repos/Kranc/Tools/CodeGen/Schedule.m". -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/543> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #523: schedule MoL_DecrementCounter and friends BEFORE MoL_PostStepModify
by Einstein Toolkit 20 Dec '11

20 Dec '11

#523: schedule MoL_DecrementCounter and friends BEFORE MoL_PostStepModify --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- right now MoL_DecrementCounter (and MoL_ResetTime and MoL_ResetDeltaTime) is/are scheduled BEFORE MoL_PostStep which caused MoL_PostStepModify to run before MoL_DecrementCounter for me. The means that routines that are moved from MoL_PostStep to MoL_PostStepModify see a different MoL_IntermediateStep possibly confusing users. Also MoL_Add should be explicitly schedules before MoL_PostStepModify (again right now it says MoL_PostStep). It still ends up before due to the alphabetic sorting it seems. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/523> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices
by Einstein Toolkit 20 Dec '11

20 Dec '11

#66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices ----------------------------------+----------------------------------------- Reporter: bcmsma@… | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | ----------------------------------+----------------------------------------- While the assigned values for the parameters IOASCII::output_symmetry_points = "no" IOASCII::out3D_ghosts = "no" IOASCII::out3D_outer_ghosts = "no" work as intended when CarpetIOASCII is active, it doesn't work for CarpetIOHDF5: IOHDF5::out3D_ghosts = "no" IOHDF5::out3D_outer_ghosts = "no" IOHDF5::output_symmetry_points = "no" It doesn't do anything to the 3D data but it corrupts the 2D data slices while chopping out those regions. It would be nice to have them working for IOHDF5 method, specially when visualising Pi symmetric data. Note also that this report is for git version of Carpet. These parameters seem to become deprecated for the hg version. Does anyone use them regularly? Any substitute in mind? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/66> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #527: Thorn Dissipation should have 9th order dissipation added
by Einstein Toolkit 16 Dec '11

16 Dec '11

#527: Thorn Dissipation should have 9th order dissipation added -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Dissipation | -----------------------------------+---------------------------------------- The current standard in BBH evolutions is to use 8th order accurate finite differencing with 9th order accurate dissipation. Thorn Dissipation currently only supports up to 7th order accurate dissipation, and should be extended to support 9th order. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/527> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #223: Make declaration of CCTK_ARGUMENTS safer
by Einstein Toolkit 01 Dec '11

01 Dec '11

#223: Make declaration of CCTK_ARGUMENTS safer -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I suggest to change the declaration of CCTK_ARGUMENTS in C from cGH * cctkGH to cGH const * CCTK_RESTRICT const cctkGH which should lead to safer code and may even enable some optimisations. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/223> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #425: Case sensitivity GSL_DIR=BUILD
by Einstein Toolkit 24 Nov '11

24 Nov '11

#425: Case sensitivity GSL_DIR=BUILD ----------------------------------------+----------------------------------- Reporter: reisswig@… | Type: enhancement Status: new | Priority: minor Milestone: | Component: Cactus Version: | Keywords: GSL_DIR BUILD ----------------------------------------+----------------------------------- The thorn GSL would not compile if "GSL_DIR=build" in the option list. In order to work, it requires "GSL_DIR=BUILD", i.e. it is really case sensitive although I think, this is not required and should be case insensitive. Possibly, HDF5_DIR=build may also not work for the same reason (have not checked; should be checked as well). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/425> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #234: Carpet mailing list is not functioning
by Einstein Toolkit 21 Nov '11

21 Nov '11

#234: Carpet mailing list is not functioning --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- The Carpet mailing list has been unavailable since 22-Mar-2010. This list provides a forum for discussion of Carpet features and issues, and would be the first port-of-call for new users. As such I think it would be good to resurrect the mailing list. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/234> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #495: MPI error from Carpet with QuasiLocalMeasures: "MPI_SUM is not defined for non-intrinsic datatypes"
by Einstein Toolkit 14 Nov '11

14 Nov '11

#495: MPI error from Carpet with QuasiLocalMeasures: "MPI_SUM is not defined for non-intrinsic datatypes" --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- In the development (Mercurial) version of Carpet, but not the stable (Git) version, QuasiLocalMeasures fails with the following error message: ... INFO (QuasiLocalMeasures): Landau-Lifshitz angular momentum x: 0.00000 INFO (QuasiLocalMeasures): Landau-Lifshitz angular momentum y: 0.00000 INFO (QuasiLocalMeasures): Landau-Lifshitz angular momentum z: 0.00000 [sl-18:26396] *** An error occurred in MPI_Reduce: the reduction operation MPI_SUM is not defined for non-intrinsic datatypes [sl-18:26396] *** on communicator MPI COMMUNICATOR 3 SPLIT FROM 0 [sl-18:26396] *** MPI_ERR_OP: invalid reduce operation [sl-18:26396] *** MPI_ERRORS_ARE_FATAL (your MPI job will now abort) This affects the QuasiLocalMeasures test suite, but was also reported and discussed on the ET mailing list: http://lists.einsteintoolkit.org/pipermail/users/2011-May/001107.html Additional debugging was suggested to try to locate the reason for the error. (Reporting against Carpet even though it might be a problem in QuasiLocalMeasures because it works in the stable Carpet and this will be a possible blocker for promoting the development Carpet to stable). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/495> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead?
by Einstein Toolkit 13 Nov '11

13 Nov '11

#145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead? ---------------------------+------------------------------------------------ Reporter: bmundim | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: EOS_Omni HDF5 | ---------------------------+------------------------------------------------ At the moment EOS_Omni requires the HDF5 library to read the nuclear EOS values from a table. Since not all distros have fortran support for the HDF5 library as a default, I propose to change this requirement and provide a fall back in case this support is not present. Perhaps not using the nuclear EOS, or reading from an ASCII file instead. This could be just a temporary solution until the HDF5 library build script becomes more robust. Opinions? Thanks, Bruno. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/145> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

← Newer
1
...
4
5
6
7
8
9
10
...
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2011