Trac May 2013

trac@lists.einsteintoolkit.org

1 participants
178 discussions

[Einstein Toolkit] #229: Using a nonexistent header file should lead to an error message
by Einstein Toolkit 06 Jul '13

06 Jul '13

#229: Using a nonexistent header file should lead to an error message --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- If I have the following in my interface.ccl, USES INCLUDE: vectors.h but no thorn in my thornlist provides this header file, there is no error at compile time. Further, if I #include this file in my source file, an empty file is included, which means that again I don't get an error. The first indication that something is wrong is that the contents of the header file are not available, which makes debugging the problem with the thornlist very confusing. I propose that the CST should emit a fatal error if one of the thorns tries to use a header file which does not exist. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/229> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #1374: C++ complex implementation fails to compile
by Einstein Toolkit 05 Jul '13

05 Jul '13

#1374: C++ complex implementation fails to compile ----------------------+----------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: critical | Milestone: ET_2013_05 Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- When compiling I get: {{{ COMPILING /home/knarf/Cactus/arrangements/CactusCoastal/Funwave/src/declare.cc In file included from /usr/include/c++/4.7/complex:46:0, from /home/knarf/Cactus/src/include/cctk_Types.h:40, from /home/knarf/Cactus/src/include/cctk_Groups.h:34, from /home/knarf/Cactus/arrangements/CactusCoastal/Funwave/src/cctk_declare.h:9, from /home/knarf/Cactus/configs/sim/build/Funwave/declare.cc:1: /usr/include/c++/4.7/cmath: In function ‘constexpr float std::abs(float)’: /usr/include/c++/4.7/cmath:90:16: error: declaration of C function ‘constexpr float std::abs(float)’ conflicts with /usr/include/c++/4.7/cmath:84:3: error: previous declaration ‘constexpr double std::abs(double)’ here /usr/include/c++/4.7/cmath: In function ‘constexpr long double std::abs(long double)’: /usr/include/c++/4.7/cmath:94:22: error: declaration of C function ‘constexpr long double std::abs(long double)’ conflicts with /usr/include/c++/4.7/cmath:90:3: error: previous declaration ‘constexpr float std::abs(float)’ here /usr/include/c++/4.7/cmath:94:22: error: declaration of C function ‘constexpr long double std::abs(long double)’ conflicts with /usr/include/c++/4.7/cmath:84:3: error: previous declaration ‘constexpr double std::abs(double)’ here /usr/include/c++/4.7/cmath: At global scope: /usr/include/c++/4.7/cmath:98:3: error: template with C linkage }}} This seems to be caused by cctk_Groups.h going into "C" linkage, then including cctk_Types.h which includes <complex> when compiled with C++. The system complex implementation however (at least in CXX0X mode) uses templates, which aren't allowed with "C" linkage. I use gnu g++ version 4.7 with -std=gnu++0x. Applying the following patch to src/include/cctk_Types.h solves the problem for me: {{{ Index: cctk_Types.h =================================================================== --- cctk_Types.h (revision 5021) +++ cctk_Types.h (working copy) @@ -37,7 +37,9 @@ /* Declarations for complex types */ #ifdef __cplusplus +extern "C++" { # include <complex> +} #endif #ifdef HAVE_CCTK_REAL16 }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1374> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1238: implement buffer mask in CarpetEvolutionMask
by Einstein Toolkit 29 Jun '13

29 Jun '13

#1238: implement buffer mask in CarpetEvolutionMask ---------------------------------+------------------------------------------ Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: CarpetEvolutionMask | ---------------------------------+------------------------------------------ the attached patch implements a new integer valued grid function carpetevolutionmask::buffer_mask which is set to 1 in buffer regions and 0 otherwise. It provides a testcase. Eventually I would like to add other values such that the number correlates with the last MoL step for which this point needs to be valid before MoL_CalcRHS but for which one cannot compute a RHS in MoL_CalcRHS. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1238> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1222: Reduction weight for periodic domains.
by Einstein Toolkit 24 Jun '13

24 Jun '13

#1222: Reduction weight for periodic domains. ------------------------+--------------------------------------------------- Reporter: bentivegna | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | ------------------------+--------------------------------------------------- The reduction weight of the internal points neighboring the outer boundaries is currently set in a "trapezoidal-rule" manner (1/2 on the box faces, 1/4 on the edges, 1/8 on the vertices, in 3D), regardless of the nature of the boundaries. In the case of periodic boundaries with a Coordbase::boundary_shiftout_* parameter of zero, this leads to the assignment of a non-zero weight to some of the boundary points. This only yields the correct result if boundary conditions have been applied, which sometimes isn't possible/necessary. The attached patch introduces some logic in CarpetReduce to take care of this case. This may not be the best way to attack the problem though. One could tackle the way weight is assigned to zero-shiftout boundaries. Perhaps this issue is related to #1221. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1222> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #1362: track Fortran module dependency for modules in subdirs
by Einstein Toolkit 24 Jun '13

24 Jun '13

#1362: track Fortran module dependency for modules in subdirs -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Cactus' module dependency and autogeneration feature (ie adding proper dependencies when a "use module" is found) currently fails for modules defined in SUBDIRS of src (even when the SUBDIRS are properly declared in make.code.defn). It would be nice if Cactus kept track of those as well. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1362> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1236: ReflectionSYmmetry does not handle vector groups of vectors correctly
by Einstein Toolkit 14 Jun '13

14 Jun '13

#1236: ReflectionSYmmetry does not handle vector groups of vectors correctly -----------------------------------------------------------------------+---- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: RelfectionSymmetry RotatingSymmetry180 RotatingSymmetry90 | -----------------------------------------------------------------------+---- Currently we use two different way to define vectors in Cactus: {{{ CCTK_REAL vel[3] "some vector variable" }}} and {{{ CCTK_REAL vel { velx, vely, velz } "some other vector variable" }}} both of which work with ReflectionSymmetry since it only looks at the ordering of variables in a group (ie does vi=CCTK_FirstVarInGroup() then assumes vi is the x component vi+1 the y component and vi+2 the z component). For a group of related vectors we'd like to use {{{ CCTK_REAL nvel[42] { velx, vely, velz } "bunch of vector" }}} which almost works in the indeed CCTK_VarIndex("velx[0]") + 1 == CCTK_VarIndex("vely[0]"). Unfortunately the symmetry thorns assume that vector groups contain precisely three members. A simple fix seems to instead assert() that the number of members is divisible by 3 and then loop over them in chunks of three. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1236> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 17

[Einstein Toolkit] #1309: implement UIUC's speed-up in "evaluation" of spectral solution
by Einstein Toolkit 11 Jun '13

11 Jun '13

#1309: implement UIUC's speed-up in "evaluation" of spectral solution --------------------------------------+------------------------------------- Reporter: bernard.j.kelly@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: ET_2012_11 Keywords: twopunctures evaluation | --------------------------------------+------------------------------------- The accompanying svn patch applies the recently released refinement of TwoPunctures by Vasileios Paschalidis and Zach Etienne at UIUC, greatly reducing the time taken to properly apply the solution of the spectral solve to all grid points. The patch is relative to the ET_2012_11 release (though I suspect it would apply to the upcoming 2013_05 release without modification). It passes the TwoPunctures/test/bhns_eval test suite. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1309> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #905: NaNs in ADMBase::gxx using Development Version of ET
by Einstein Toolkit 06 Jun '13

06 Jun '13

#905: NaNs in ADMBase::gxx using Development Version of ET ---------------------------------+------------------------------------------ Reporter: yosef@… | Type: defect Status: new | Priority: major Milestone: | Component: Other Version: | Keywords: ---------------------------------+------------------------------------------ While testing the CCE in the ET, I stumbled across an issue interpolating the admbase::metric at CCTK_POSTSTEP in GLOBAL mode at particular spatial points. The "bug" (or parfile/scheduling error) seems to be sensitive to the exact grid setup. Basically, when I use the qc0-mclachlan-CCE_Cauchy.par parfile, I get nans for gxx. I made a small test thorn that only interpolates gxx at a particular point. Nans show up at iteration 1. attached is the parfile I used and the test thorn. Here is the output from the above test thorn: gxx(3.966899,0.000000,-17.630662) = 1.1160523626974641 at iter 0 on proc 1 gxx(3.966899,0.000000,-17.630662) = 1.1160523626974641 at iter 0 on proc 0 gxx(3.966899,0.000000,-17.630662) = -nan at iter 8 on proc 1 gxx(3.966899,0.000000,-17.630662) = -nan at iter 8 on proc 0 gxx(3.966899,0.000000,-17.630662) = -nan at iter 16 on proc 1 gxx(3.966899,0.000000,-17.630662) = -nan at iter 16 on proc 0 etc.... -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/905> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1353: GRHydro updates
by Einstein Toolkit 29 May '13

29 May '13

#1353: GRHydro updates -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- this set of patches is need (or at least the MHD ones are) to be able to actually run the runs of the ET MHD paper. So even this late in the game, I'd like to get them into the release if at all possible. There are also a number of bugfixes mostly for the hot eos code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1353> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1347: simfactory doesn't support --runscript and --submitscript for setup-silent.
by Einstein Toolkit 26 May '13

26 May '13

#1347: simfactory doesn't support --runscript and --submitscript for setup-silent. -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- simfactory doesn't support --runscript and --submitscript for setup- silent. However, it does support --optionlist. The attached patch enables the aforementioned two options, making setup really convenient for a VM. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1347> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

← Newer
1
...
11
12
13
14
15
16
17
18
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2013