Trac January 2011

trac@lists.einsteintoolkit.org

1 participants
147 discussions

[Einstein Toolkit] #222: Dubious code in Hydro_InitExcision.c
by Einstein Toolkit 08 Nov '11

08 Nov '11

#222: Dubious code in Hydro_InitExcision.c ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- Hydro_InitExcision.c contains the following code: if ( (hydro_initexcision_coordinate_length <= 0.0) && ( ( x_frac > 0.5 - hydro_initexcision_fraction) && ( x_frac < 0.5 + hydro_initexcision_fraction) && ( y_frac > 0.5 - hydro_initexcision_fraction) && ( y_frac < 0.5 + hydro_initexcision_fraction) && ( z_frac > 0.5 - hydro_initexcision_fraction) && ( z_frac < 0.5 + hydro_initexcision_fraction) ) || ( (hydro_initexcision_coordinate_length > 0.0) && ( fabs(x[point]-hydro_initexcision_position_x) <= hydro_initexcision_coordinate_length*0.5) && ( fabs(y[point]-hydro_initexcision_position_y) <= hydro_initexcision_coordinate_length*0.5) && ( fabs(z[point]-hydro_initexcision_position_z) <= hydro_initexcision_coordinate_length*0.5) ) ) This code has an "and" (&&) and an "or" (||) operation at top level. Is this intended? The code would be clearer with an additional set of parenthesis, or by introducing a suitable set of temporaries for sub- expressions. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/222> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #235: Improve performance of Fortran index calculations
by Einstein Toolkit 27 Oct '11

27 Oct '11

#235: Improve performance of Fortran index calculations -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- In Fortran, Cactus currently declares grid functions e.g. as (this is the expansion of DECLARE_CCTK_ARGUMENTS) REAL*8 gxx (X0metric,X1metric,X2metric) where X0metric etc. are integers passed into the routine. Each grid function group has its own, independent size. This has two disadvantages: 1. The compiler does not know that all grid functions have the same size (namely cctk_lsh), and thus has to perform array index calculations separately for each group 2. The argument list is longer than neded The enclosed patch declares grid functions via cctk_lsh. Grid arrays are still declared independently. This reduces the code size of e.g. GRHydro/GRHydro_Tmunu.F90 from 6836 to 6241 bytes on my system. I have not attempted to measure a performance difference. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/235> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #147: Write transition guide for EOS_Omni
by Einstein Toolkit 24 Oct '11

24 Oct '11

#147: Write transition guide for EOS_Omni -------------------------------------+-------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- The Einstein Toolkit pages need a wiki tutorial for switching to EOS_Omni. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/147> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #162: Document CCTK_GFINDEX3D and friends in reference manual
by Einstein Toolkit 23 Oct '11

23 Oct '11

#162: Document CCTK_GFINDEX3D and friends in reference manual ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- I believe the reference manual does not describe any of the CCTK_GFINDEX* and CCTK_VECTGFINDEX* functions. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/162> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #219: ExternalLibraries method should be documented
by Einstein Toolkit 19 Oct '11

19 Oct '11

#219: ExternalLibraries method should be documented ---------------------------+------------------------------------------------ Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: documentation | ---------------------------+------------------------------------------------ The Cactus documentation http://einsteintoolkit.org/info/documentation/UsersGuide/UsersGuidech6.html… (scroll down to Compiling with Extra Packages) currently tells people to use the "extras" method for enabling access to external libraries such as HDF5, MPI etc. As I understand it, this method is deprecated in favour of the ExternalLibraries method, and both should not be used at the same time for the same library. The documentation should be updated to describe the ExternalLibraries method, and the old method description should be moved to an appendix with a clear warning that this is deprecated. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/219> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #206: Add --xml option to GetComponents
by Einstein Toolkit 19 Oct '11

19 Oct '11

#206: Add --xml option to GetComponents ---------------------------+------------------------------------------------ Reporter: eric9 | Owner: eric9 Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ GetComponents should support machine readable output using XML. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/206> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #112: Python version of Simfactory should be made default before next ET release
by Einstein Toolkit 29 Sep '11

29 Sep '11

#112: Python version of Simfactory should be made default before next ET release ------------------------+--------------------------------------------------- Reporter: knarf | Owner: mthomas Type: task | Status: new Priority: critical | Milestone: ET_2011_06 Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/112> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #131: Cactus produces way too much output with SILENT!=no
by Einstein Toolkit 26 Sep '11

26 Sep '11

#131: Cactus produces way too much output with SILENT!=no -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I frequently find me scrolling through a lot of not necessary output from Cactus, including a lot of divider lines (___). I propose a mechanism to disable most of that output. There is currently one parameter which influences the amount of output from Cactus. If SILENT is set to 'no', Cactus provides way more output. All other values produce the usual output (including not setting it). I propose to use this existing variable to make Cactus less verbose if SILENT ist set to 'yes'. The default is 'undefined', so this would preserve the default Cactus behaviour. The attached patch attempts to do this: it suppresses divider lines, pre- and postprocessing infos if SILENT='yes'. I don't like that name though, as this is still not really silent, as you will still see one line per compiled file (ala COMPILING /home/frank.loeffler/mcrt/src/main/Banner.c), but I don't have a better idea right now and could live with it. The other option would be to introduce another variable (e.g. BRIEF), but then BRIEF and SILENT could contradict each other. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/131> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #108: LocalInterp and LocalReduce should move to CactusNumerical
by Einstein Toolkit 06 Sep '11

06 Sep '11

#108: LocalInterp and LocalReduce should move to CactusNumerical -----------------------+---------------------------------------------------- Reporter: anonymous | Type: enhancement Status: new | Priority: minor Milestone: | Component: Cactus Version: | Keywords: -----------------------+---------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/108> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #203: Add shallow clone to hg
by Einstein Toolkit 03 Sep '11

03 Sep '11

#203: Add shallow clone to hg ---------------------------+------------------------------------------------ Reporter: eric9 | Owner: eric9 Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ Git and darcs offer a shallow clone option (--depth 1 for git and --lazy for darcs). Hg can accomplish a similar thing by running hg clone -r tip URL. This should be implemented following the same rules as shallow clones for git and darcs. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/203> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac January 2011