Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1507: Repository tags for the ET_2013_10 release have not been created
by Einstein Toolkit 27 Dec '13

27 Dec '13

#1507: Repository tags for the ET_2013_10 release have not been created --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- Each release of the ET should have tags in the repositories identifying the release, as well as any minor version increments due to backports. We have tags for ET_2013_05_v0 but not for ET_2013_11_v0. It would also be good to create new tags based on the branch every so often after fixes have been backported, so that it is possible to easily identify a specific version of the toolkit, e.g. ET_2013_11_v1. Frank is going to create ET_2013_10_v0 tags. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1507> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1510: OpenSSL fails to build on fedora core 20
by Einstein Toolkit 25 Dec '13

25 Dec '13

#1510: OpenSSL fails to build on fedora core 20 -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: OpenSSL | -----------------------------------+---------------------------------------- we get an error: {{{ cms.pod around line 457: Expected text after =item, not a number cms.pod around line 461: Expected text after =item, not a number cms.pod around line 465: Expected text after =item, not a number cms.pod around line 470: Expected text after =item, not a number cms.pod around line 474: Expected text after =item, not a number }}} which seems to be identical to the error observed by the Arch Linux maintainers: https://bugs.archlinux.org/task/35868 their fix (see comments below) is here https://bugs.archlinux.org/task/35868?getfile=10648 Ok to include in OpenSSL or should we require Fedora users to install OpenSSL from the distro packages? It builds fine eg on Ubuntu 13.04 even without the patch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1510> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1508: abort if boundary widht is very wide (>100 points)
by Einstein Toolkit 22 Dec '13

22 Dec '13

#1508: abort if boundary widht is very wide (>100 points) -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: Boundary | -------------------------+-------------------------------------------------- Currently if a user schedules the routine calling Boundary_RegisterGroupForBC in LEVEL mode (which is the correct mode), cctk_nghostzones is undefined and Carpet fills it with the deadbeef value (666). Passing 666 to Boundary_RegisterGroupForBC leads to silently incorrect results as it often prevents the BC from being applied at all (there is a check in many boundary routines that returns if the domain is too small, presumably to support 1 point wide 1d domains). The attached patch checks the boundary width requested and aborts if the width is larger than 100. This is the same threshold that the symmetry thorns already use to abort a run. This prevents a user error (seen it twice so far) and should not as far as I can tell affect any correct code (unless we ever actually encounter a boundary wider than 100 points in which case we are in trouble anyway). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1508> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1367: Mojave commands don't work with symlinks
by Einstein Toolkit 20 Dec '13

20 Dec '13

#1367: Mojave commands don't work with symlinks ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: sbrandt Type: defect | Status: new Priority: major | Milestone: Cactus_4.3.0 Component: Mojave | Version: Keywords: | ---------------------+------------------------------------------------------ Mojave commands don't work with symlinks -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1367> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1504: MoL RK87 non-functional
by Einstein Toolkit 20 Dec '13

20 Dec '13

#1504: MoL RK87 non-functional -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: MoL | -----------------------------------+---------------------------------------- currently (Noether release and trunk, since rev 190) MoL's RK87.c file contains a line (line 234): {{{ CCTK_WARN(0, "Peter has been too lazy to write the RK87 routine " "out for array variables. Better send him an email..."); }}} which unconditionally aborts the run whenever RK87 is used, even when used for grid functions and not grid arrays. The fix is obviously to check MoLNumEvolvedArrayVariables before aborting: {{{ if (MoLNumEvolvedArrayVariables > 0 || MoLNumEvolvedComplexArrayVariables > 0) { CCTK_WARN(0, "Peter has been too lazy to write the RK87 routine " "out for array variables. Better send him an email..."); } }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1504> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1492: missing parameter in CactusExamples/WaveMoL ?
by Einstein Toolkit 14 Dec '13

14 Dec '13

#1492: missing parameter in CactusExamples/WaveMoL ? --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2014_05 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- The testsuites CarpetInterp/waveinterp* set a parameter WaveMoL::num_timelevels that does not exist in CactusExamples/WaveMoL. Since CactusExamples was only just recently added to the ET, this testsuite now tries to run and fails. This is not really a failure of the newly added thorn, but that of the long existing, but never run testsuite. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1492> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[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] #1384: simplify using Refluxing with MoL
by Einstein Toolkit 11 Dec '13

11 Dec '13

#1384: simplify using Refluxing with MoL -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Other | Version: development version Keywords: Refluxing | -------------------------+-------------------------------------------------- currently one needs to set two parameters when using Refluxing with GRHydro only: nvars and nvars_evolved which are set to the same value. The two different parameters allow refluxing to be used with thorns that implement their own timestepping indedpendent of MoL. To simplify usage in situations where only MoL is used I proposed to introduce a new parameter nvars_not_evolved_with_MoL which defaults to zero and to retire nvars_evolved in favor of the new parameter. This would make MoL based simulations with only a single parameter choice possible. Alternatively we could have a second string non_MoL_refluxing_variables that lists the variables which have refluxing applied to them but are not evolved with MoL. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1384> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1503: Support XFAIL for test cases
by Einstein Toolkit 09 Dec '13

09 Dec '13

#1503: Support XFAIL for test cases -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- There should be a mechanism to mark test cases as "XFAIL" if they are expected to fail. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1503> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1502: provide equivalent of CCTK_PASS_CTOC and CCTK_PASS_FTOF between languages
by Einstein Toolkit 09 Dec '13

09 Dec '13

#1502: provide equivalent of CCTK_PASS_CTOC and CCTK_PASS_FTOF between languages -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- It is occasionally (such as when interfacing with legacy code) code useful to use the equivalent of {{{CCTK_PASS_CTOF}}} and {{{CCTK_PASS_FTOC}}}. This seems to be impossible to directly. Workarounds are declare the C function to take {{{cGH ** p_cctkGH}}} as an argument then set up a local {{{cGH *cctkGH = *p_cctkGH}}} before {{{DECLARE_CCTK_ARGUMENTS}}} for {{{CCTK_PASS_FTOC}}} while for {{{CCTK_PASS_CTOF}}} one seems to have to resort to {{{CCTK_FortranWrapper}}} and call the returned wrapper with cctkGH and the (Fortran) function pointer. Note: this of course suffers from combinatorial explosion of options when Cactus starts to support Lua/Python/Tcl/Java/Forth. It might be useful to instead provide a set of functions that allow this to be done "officially". Something like: {{{ call CCTK_PASSFTOC(Cfunc) }}} and {{{ CCTK_PASSCTOF(CCTK_FNAME(Ffunc)); }}} where the later is essentially {{{ #define CCTK_PASSCTOF(fun) (CCTK_FortranWrapper(CCTK_THORNSTRING))(fun, cctkGH) }}} and the former {{{ #define CCTK_PASSFTOC(fun) CCTK_PassFtoC(fun, cctkGH) void CCTK_FNAME(CCTK_PassFtoC)(void (*f)(cGH *cctkGH), cGH **p_cctkGH) { f(*p_cctkGH); } }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1502> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac