Trac February 2014

trac@lists.einsteintoolkit.org

1 participants
141 discussions

[Einstein Toolkit] #719: Mailing lists could have a link to the archived version of the message
by Einstein Toolkit 21 May '18

21 May '18

#719: Mailing lists could have a link to the archived version of the message -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- It would be useful for the footer of a mailing list posting to contain a URL to the archived version of the message so that it is easy to point people to the message in an email. This would apply to both the Cactus and the ET lists. It appears that this is not straightforward in MailMan 2, but is expected in version 3: http://mail.python.org/pipermail/mailman- users/2011-October/072378.html. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/719> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 18

[Einstein Toolkit] #1368: add env option for commands in .mojave.xml
by Einstein Toolkit 07 May '18

07 May '18

#1368: add env option for commands in .mojave.xml -------------------------+-------------------------------------------------- Reporter: sbrandt | Owner: sbrandt Type: enhancement | Status: new Priority: major | Milestone: Cactus_4.3.0 Component: Mojave | Version: Keywords: | -------------------------+-------------------------------------------------- add env option for commands in .mojave.xml -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1368> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1471: Cactus should auto-detect newer versions of GCC from MacPorts
by Einstein Toolkit 30 Apr '18

30 Apr '18

#1471: Cactus should auto-detect newer versions of GCC from MacPorts -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently, during Cactus configuration without an optionlist on Mac OS, I get {{{ checking for gcc-mp-4.4... no checking for gcc-mp-4.3... no checking for gcc-mp-4.2... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes }}} I have gcc-mp-4.6, and 4.7 and 4.8 are also available in macports. The configure script should be updated to detect these versions. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1471> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

2 11

[Einstein Toolkit] #1170: ExtrenalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS incosistently
by Einstein Toolkit 20 Mar '18

20 Mar '18

#1170: ExtrenalLibraries handle XXX_DIR XXX_INC_DIRS and XXX_LIB_DIRS incosistently -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: ExternalLibraries | -----------------------------------+---------------------------------------- This is a companion ticket to #1006. Different thorns (eg. MPI and HDF5 and LAPACK) handle XXX_DIR and XXX_INC_DIRS etc differently. MPI for example sets the include path to $MPI_DIR/include if MPI_INC_DIRS is not explicitly set and to MPI_INC_DIRS if it is set. HDF5 has no HDF5_INC_DIRS option and always sets the include path to HDF5_DIR/include. LAPACK has not INC_DIRS option and sets the linker path to LAPACK_DIR while the other two thorns set it to XXX_DIR/lib (unless overridden by MPI_LIB_DIRS in the case of MPI). I would be good to present a uniform set of option for all these thorns. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1170> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1474: compile ExternalLibraries with other thorns rather than when CST runs
by Einstein Toolkit 20 Mar '18

20 Mar '18

#1474: compile ExternalLibraries with other thorns rather than when CST runs -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Compiling external libraries takes a long time by now. Currently this happens very early in the compilation phase, before the other thorns are compiled. It would be better if the compilation happened at the same time as that of other thorns. This will entail splitting the configuration ie. detecting whether to build the included source or use a system wide copy from the compilation, most likely either using Cactus makefile variables or temporary files to transfer the decisions from the configuration stage to the build stage. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1474> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1458: intel 13 2013.1.117 miss-compiles asserts in TwoPunctures tp_utils.c
by Einstein Toolkit 22 Jan '18

22 Jan '18

#1458: intel 13 2013.1.117 miss-compiles asserts in TwoPunctures tp_utils.c -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: TwoPunctures | -----------------------------------+---------------------------------------- this continues the thread in #1429 in particular https://trac.einsteintoolkit.org/ticket/1429#comment:14. Currently we need to determine which versions are affected. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1458> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1396: Display prompts of executed commands
by Einstein Toolkit 19 Nov '17

19 Nov '17

#1396: Display prompts of executed commands ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: eric9 Type: enhancement | Status: new Priority: optional | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ the attached patch goes to some lengths to capture both stdout and stderr when executing commands and displays each line of output as it is generated by the command. This is useful for programs that output prompts to stdout and wait for user input afterwards. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1396> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #68: GetComponents hang due to certificate issues.
by Einstein Toolkit 19 Nov '17

19 Nov '17

#68: GetComponents hang due to certificate issues. --------------------------------+------------------------------------------- Reporter: diener@… | Owner: eric9 Type: defect | Status: new Priority: major | Milestone: Component: GetComponents | Version: ET_2010_06 Keywords: | --------------------------------+------------------------------------------- I did a complete new checkout of the EinsteinToolkit on numrel06 using the version of GetComponents available on the EinsteinToolkit web pages and had GetComponents hang with no errors or warnings when checking out AEIThorns/AEILocalInterp. Trying the checkout manually I got: Error validating server certificate for 'https://svn.aei.mpg.de:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: svn.aei.mpg.de - Valid: from Tue, 23 Feb 2010 16:02:12 GMT until Sun, 22 Feb 2015 16:02:12 GMT - Issuer: Max-Planck-Gesellschaft, DE - Fingerprint: 03:b4:e8:6e:d9:09:e9:93:72:e9:ff:fa:df:e4:2c:6d:1d:2a:e4:66 (R)eject, accept (t)emporarily or accept (p)ermanently? p After accepting the certificate and restarting the checkout proceeded without problems. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/68> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 29

[Einstein Toolkit] #181: AEILocalInterp should not off-centre the interpolation stencil by default
by Einstein Toolkit 19 Nov '17

19 Nov '17

#181: AEILocalInterp should not off-centre the interpolation stencil by default ----------------------------+----------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: AEILocalInterp | ----------------------------+----------------------------------------------- AEILocalInterp by default will off-centre the interpolation stencil if there are insufficient points to perform the interpolation. In a parallel setting, this could happen due to there being insufficient ghost points for the interpolator chosen. The off-centering leads to an interpolation error which is of the correct order but larger than for a centered stencil. More importantly, it leads to different results on different numbers of processes. This violates a basic design principle of Cactus, and the expectation of users, that changing the number of processors should not change the results of a simulation. I propose that instead of silently off-centering the stencil, AEILocalInterp should abort with an error indicating that there are insufficient ghost-zones. The interpolator options corresponding to this are: boundary_off_centering_tolerance={0.0 0.0 0.0 0.0 0.0 0.0} boundary_extrapolation_tolerance={0.0 0.0 0.0 0.0 0.0 0.0} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/181> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #778: Compiling PittNullCode is slow
by Einstein Toolkit 24 Oct '17

24 Oct '17

#778: Compiling PittNullCode is slow -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Compiling PittNullCode is very slow on some systems (e.g. with gcc). I believe this is because files such as NullConstr_R00.F90 contain many whole-array operations that the compiler has to analyse. I suggest to rewrite these routines, using e.g. forall or do loops. If we want to keep the elegant, index-free notation, then I suggest to add an elemental subroutine for the actual calculations and calling it with whole arrays. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/778> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2014