Trac February 2013

trac@lists.einsteintoolkit.org

1 participants
177 discussions

[Einstein Toolkit] #1207: Einstein toolkit sites with invalid security certificates
by Einstein Toolkit 19 May '14

19 May '14

#1207: Einstein toolkit sites with invalid security certificates -------------------------------------+-------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- https://einsteintoolkit.org exists but has an invalid security certificate (http://www.sslshopper.com/ssl-checker.html#hostname=einsteintoolkit.org). I don't think we need SSL/TLS on this server. It should either be disabled or a valid certificate used. The same applies to https://cactuscode.org (http://www.sslshopper.com/ssl- checker.html#hostname=cactuscode.org). Note that Frank's page (http://www.cct.lsu.edu/~knarf/cgi-bin/monitor.cgi) reports these certificates as self-signed; they are also expired. Self- signed certificates on public websites are bad: they encourage people to click through the warnings. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1207> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #590: McLachlan should allow other thorns to set the gauge
by Einstein Toolkit 28 Apr '14

28 Apr '14

#590: McLachlan should allow other thorns to set the gauge -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The parameters lapse_evolution_method and shift_evolution_method are usually set to ML_BSSN in McLachlan. However they are never checked in the code. McLachlan indeed seems to ignore their values and overwrite whatever the values of lapse or shift set elsewhere, preventing therefore other thorns from setting them differently. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/590> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 22

[Einstein Toolkit] #1215: Source browsing not working
by Einstein Toolkit 24 Apr '14

24 Apr '14

#1215: Source browsing not working ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- The repositories in the "Browse source" TRAC interface (https://trac.einsteintoolkit.org/browser) are not being updated. The last Cactus flesh commit visible there is from 10 months ago. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1215> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #849: Drop explicit support for Fortran 77 in Cactus
by Einstein Toolkit 19 Apr '14

19 Apr '14

#849: Drop explicit support for Fortran 77 in Cactus -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I suggest to drop explicit support for Fortran 77 in Cactus. Fortran 77 is, for all practical purposes, a subset of Fortran 90, and thus Fortran 77 code can be compiled by Fortran 90 compilers. There is currently no platform that has a Fortran 77 and no Fortran 90 compiler, and there is no Fortran source code in Cactus that cannot be compiled by a Fortran 90 compiler. In a way, supporting Fortran 77 as language is similar to supporting K&R C as a language. We don't do this either. I suggest to remove/ignore all configuration options regarding Fortran 77, and to compile .f77 and .F77 files with a Fortran 90 compiler. This change will simplify the configuration stage of Cactus. I don't expect any user to notice. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/849> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #882: Create ThornGuideHTML target
by Einstein Toolkit 14 Mar '14

14 Mar '14

#882: Create ThornGuideHTML target ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- Barry Wardell suggests: The only issue is that there doesn't seem to be a HTML version of the configuration specific ThornGuide make target, so we should add this as a target at the same time as removing the patch. I'd imagine this would just be a matter of copy-and-paste from the existing ThornGuideHTML target. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/882> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1117: Wrong CarpetIOASCII headers for complex 2D output.
by Einstein Toolkit 25 Jan '14

25 Jan '14

#1117: Wrong CarpetIOASCII headers for complex 2D output. ----------------------------------------+----------------------------------- Reporter: reisswig@… | Type: defect Status: new | Priority: minor Milestone: | Component: Other Version: | Keywords: ----------------------------------------+----------------------------------- I am outputting a 2d _complex_ array (called "extracted_vars") using 2d CarpetIOASCII output. Using the standard output format, the data starts at column 13. So the first array element "extracted_vars[0]" is at column 13. Now, since I have a complex array, the second element, "extracted_vars[1]", must be at column 15 (column 14 contains the imaginary part of element [0]). In older versions of Carpet, this was reported correctly in the header. In the current version, it is incorrect. The second element, "extracted_vars[1]" is reported to be in column 14 instead of 15. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1117> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #542: Remove thorn CactusArchive/ADM from thorn list
by Einstein Toolkit 25 Jan '14

25 Jan '14

#542: Remove thorn CactusArchive/ADM from thorn list -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: task | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Remove thorn CactusArchive/ADM from thorn list. This thorn is outdated, and we should updated out test cases instead. It also takes a long time and a lot of memory to compile. If we want an ADM formulation (which is doubtful since we don't use it ourselves), we should implement one via Kranc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/542> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #114: per-variable tolerances for Cactus testsuites
by Einstein Toolkit 24 Jan '14

24 Jan '14

#114: per-variable tolerances for Cactus testsuites -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: major | Milestone: ET_2011_06 Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- It would be nice to be able to specify per-variable testsuite tolerances in Cactus (per regexp for the name in the ideal case). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/114> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 24

[Einstein Toolkit] #1266: Featue request for Parity Symmetry thorn
by Einstein Toolkit 14 Dec '13

14 Dec '13

#1266: Featue request for Parity Symmetry thorn ---------------------------------+------------------------------------------ Reporter: yosef@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | ---------------------------------+------------------------------------------ I started looking at runs with parity symmetry, that is the only symmetry is the simultaneous reflection about x, y, and z. I think I was able to "implement" this symmetry by changing just a handful of lines in Rotating180 and I'm a little less sure about my changes to carpetregrid2. I was wondering, would there be any interest in adding this symmetry to ET? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1266> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #995: used shared memory on a node to share EOS table
by Einstein Toolkit 02 Dec '13

02 Dec '13

#995: used shared memory on a node to share EOS table -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: EOS_Omni | -----------------------------------+---------------------------------------- the attached patch has processes on the same node share the memory to store the EOS table. It required a patch to the flesh to detect the shared memory support functions in the OS. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/995> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2013