Trac June 2013

trac@lists.einsteintoolkit.org

1 participants
163 discussions

[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] #1391: Remove old code in radiative boundary condition in Boundary
by Einstein Toolkit 27 Jun '13

27 Jun '13

#1391: Remove old code in radiative boundary condition in Boundary -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- I stumbled across code which we should remove. I don't see anything using this particular feature, and never have. It was marked as 'to be deprecated' 10 years ago. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1391> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1394: simfactory does not return "nice" error message when local rsync version cannot be determined
by Einstein Toolkit 27 Jun '13

27 Jun '13

#1394: simfactory does not return "nice" error message when local rsync version cannot be determined ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- currently, when the version of the local rsync executable cannot be determined (eg because the user has no executable privileges or because the regular expression did not match) the user is left with a python backtrace into lib/simlib.py/RsyncVersion stating that NoneType has no attribute groups. The attached patch checks if the regular expression matched and if not reports a fatal error including rsync's return text in the error message. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1394> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[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] #1386: LocalInterp contains unneeded tests in the innermost interpolation loop
by Einstein Toolkit 18 Jun '13

18 Jun '13

#1386: LocalInterp contains unneeded tests in the innermost interpolation loop -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: LocalInterp | -------------------------+-------------------------------------------------- in lines 584 ff of Interpolate.c the code tests: {{{ /* check for valid input and output array type */ if (in_types[a] < 0 || out_types[a] < 0) { #pragma omp critical CCTK_VWarn (1, __LINE__, __FILE__, CCTK_THORNSTRING, "Datatype for input and/or output array with index %d " "is invalid", a); myretval = UTIL_ERROR_BAD_INPUT; continue; } }}} for each point. However test needs only be done once for each input array so could be moved outside of the innermost loop. There are several similar tests further down in the file that could be moved outside of the loop over points. Similarly one could replace the if() on variable types by C++ tmeplates on the type (and order of interpolation) which would also only be worhtwhile for very heavy uses of the interpolator. Only really an issue for a client thorn that does very many interpolations. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1386> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1385: add 0th order interpolation to LocalInterp
by Einstein Toolkit 18 Jun '13

18 Jun '13

#1385: add 0th order interpolation to LocalInterp -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: LocalInterp | -------------------------+-------------------------------------------------- The attached patch adds 0th order (copy from nearest grid point) interpolation to LocalInterp. This can be occasionally useful when using the interpolator as a data-mover. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1385> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1383: CarpetLib's prolongate_3d_rf2 contains non thread safe self-test
by Einstein Toolkit 14 Jun '13

14 Jun '13

#1383: CarpetLib's prolongate_3d_rf2 contains non thread safe self-test ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- the prolongate_3d_rf2 template in prolongate_3d_rf2.cc line 502ff: {{{#!c++ template <typename T, int ORDER> void prolongate_3d_rf2 (T const * restrict const src, ivect3 const & restrict srcpadext, ivect3 const & restrict srcext, T * restrict const dst, ivect3 const & restrict dstpadext, ivect3 const & restrict dstext, ibbox3 const & restrict srcbbox, ibbox3 const & restrict dstbbox, ibbox3 const & restrict, ibbox3 const & restrict regbbox, void * extraargs) { assert (not extraargs); static_assert (ORDER>=0 and ORDER % 2 == 1, "ORDER must be non-negative and odd"); typedef typename typeprops<T>::real RT; coeffs1d<RT,ORDER>::test(); }}} contain a call to the self-test routine test() which is not thread safe (since it uses a static variable without protection). As far as I can tell one can simply remove the test from this location since it is already explicitly triggered in the scheduled routine CarpetLib_test_prolongate_3d_rf2 above so would not ever actually execute anyway since the static has long been set to true by the time of the first "real" call to the operator. Similar code might exist for the other operators. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1383> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac June 2013