Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #474: Citations on ET web site don't show up properly
by Einstein Toolkit 17 Aug '11

17 Aug '11

#474: Citations on ET web site don't show up properly -------------------------------------+-------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- The citations on the page <http://einsteintoolkit.org/documentation/licenses/> don't show up properly. for example, the web site for Cactus does not show up at all, and the paper for Cactus is listed under a Carpet entry. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/474> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #449: Check for periodicity of initial data with Periodic thorn
by Einstein Toolkit 17 Aug '11

17 Aug '11

#449: Check for periodicity of initial data with Periodic thorn -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: Periodic | -------------------------+-------------------------------------------------- When applying periodic boundary conditions with the Periodic thorn, the thorn could check that the initial data it was given was actually periodic. This might help to track down errors in setting up parameter files. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/449> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #509: Cannot cleanup multiple simulations
by Einstein Toolkit 17 Aug '11

17 Aug '11

#509: Cannot cleanup multiple simulations ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- The code to clean up multiple simulations given on the cleanup command line was wrong. The attached patch fixes it. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/509> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #507: Allow non-simulation directories in simulations directory
by Einstein Toolkit 17 Aug '11

17 Aug '11

#507: Allow non-simulation directories in simulations directory -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- SimFactory considers all subdirectories of the simulations directory as simulations and emits warnings and spurious messages when running list- simulations. Additional subdirectories might be used to categorise simulations by project or might correspond to simulations run by a previous version of simfactory. The attached patch makes simfactory consider only directories containing a SIMFACTORY/properties.ini file as valid simulations. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/507> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #477: Carpet commit f33caf3aba96 (hg) breaks timer output in CCTK_Terminate
by Einstein Toolkit 17 Aug '11

17 Aug '11

#477: Carpet commit f33caf3aba96 (hg) breaks timer output in CCTK_Terminate --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- the commit to make Cactus timers hierarchical breaks eg. the Multipole testsuites with an error: {{{ cactus_devel: /localdata/rhaas3/Cactus_devel/configs/devel/build/Carpet/TimerNode.cc:95: void Carpet::TimerNode::stop(): Assertion `this==d_current' failed. }}} From the comments around the assert (thank you for those, Ian). It seems as if the patch tries to enforce that timer calls are properly nested ie. start_timer_A start_time_B stop_timer_B stop_timer_A When I played with timers myself (to write a thorn that traces how the code proceeds through functions and thus wanted to produce a call and timing graph) I found a small number of basic Cactus timers that are not nested like that (Initialization and/or Evolution I think). If this is still the case it would explain the behaviour. I attach the log file of testsuite (Multipole/test_22.par). Backing out of f33caf3aba96 (by applying in inverse patch, hg backout actually gave me conflicts...) makes the testsuite work again. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/477> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #448: CartGrid3D symmetries don't work with Carpet-hg
by Einstein Toolkit 17 Aug '11

17 Aug '11

#448: CartGrid3D symmetries don't work with Carpet-hg ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- The symmetries implemented in CartGrid3D (bitant, quadrant, and octant mode) do not work with Carpet-HG. They register a symmetry width equal to the number of ghost zones, but do so at a time when the number of ghost zones is not defined. They should instead query CoordBase for the number of boundary points. However, this may break many old parameter files that e.g. use PUGH. Another alternative would be to always use ReflectionSymmetry with Carpet- HG instead of CartGrid3D's symmetries. This affects currently e.g. the test case EinsteinAnalysis/AHFinderDirect/test/Kerr-Cartoon. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/448> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #484: CCTK_CHECK_C_INLINE can define away the inline keyword
by Einstein Toolkit 17 Aug '11

17 Aug '11

#484: CCTK_CHECK_C_INLINE can define away the inline keyword --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- CCTK_CHECK_C_INLINE tests for an inline keyword that satifies the old pre C99 inline semantics of gcc (gcc pre 4.3 and in particular pre 4.6). If it does not find an inline that behaves like that (which happens eg. with the pgi compiler which does not try to emulate gcc) then configure actually puts a #define inline into cctk_Config.h. This removes the keyword from the language turning eg. things like "static inline" into just "static" and the only inlining that happens will be due to the optimizer deciding so. The reason given for this in aclocal.m4 is the standard conforming behaviour is "incompatible with many libraries, leading to linker errors about duplicate symbols." This does no longer seem to be the case, at least I can compile the ET thornlist fine without this redefinition. I fix might be to do something like (in aclocal.m4 instead of #defining inline): AC_DEFINE(CCTK_GNU_C_INLINE, ) and AC_DEFINE_UNQUOTED(CCTK_GNU_C_INLINE, $cctk_cv_c_inline) the way that CCTK_CHECK_C_STATIC_INLINE does, instead of redefining a reserved language keyword. This would also affect the "#ifndef inline" part in cctk.h line 180, which currently seems to behave strangely in any case unless the keyword detected by configure is '''exactly''' {{{inline}}} and not e.g. {{{__inline__}}} or {{{__inline}}} or {{{__inline__ __attribute__((__gnu_inline__))}}} that configure also tests for. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/484> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #63: create separate tracs on trac.cactuscode.org and trac.cfdtoolkit.org
by Einstein Toolkit 16 Aug '11

16 Aug '11

#63: create separate tracs on trac.cactuscode.org and trac.cfdtoolkit.org --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: task | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- We need separate tracs on trac.cactuscode.org and trac.cfdtoolkit.org, including ssl certificates and the complete rest of the setup. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/63> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #233: Unable to complete an ET checkout without SVN network errors
by Einstein Toolkit 16 Aug '11

16 Aug '11

#233: Unable to complete an ET checkout without SVN network errors --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- I am running an automated build and test system every night which attempts to check out the Einstein Toolkit thornlist. Every night, I get error messages from at least one thorn of the form: Checking out module: CactusNumerical/Cartoon2D from repository: http://svn.cactuscode.org/arrangements/CactusNumerical/Cartoon2D/trunk into: ./arrangements svn: REPORT of '/arrangements/CactusNumerical/Cartoon2D/!svn/vcc/default': Could not read response body: connection was closed by server. (http://svn.cactuscode.org) Typically, three or more thorns will exhibit this problem. All the following repositories have exhibited this problem since 11th January 2011: CactusArchive/ADM CactusElliptic/EllBase CactusNumerical/Cartoon2D CactusNumerical/Dissipation CactusNumerical/InterpToArray CactusNumerical/RotatingSymmetry180 CactusNumerical/RotatingSymmetry90 EinsteinInitialData/Exact EinsteinInitialData/IDAnalyticBH EinsteinInitialData/TOVSolver EinsteinInitialData/TwoPunctures LSUThorns/QuasiLocalMeasures manifest simfactory I assume that there is some problem with the SVN server or our network connection to it that is making it so unreliable. Am I the only one? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/233> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #506: Support Dropbox to synchronise source trees
by Einstein Toolkit 15 Aug '11

15 Aug '11

#506: Support Dropbox to synchronise source trees -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- For small changes, Dropbox is much faster than rsync. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/506> 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