Trac March 2011

trac@lists.einsteintoolkit.org

1 participants
136 discussions

[Einstein Toolkit] #66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices
by Einstein Toolkit 20 Dec '11

20 Dec '11

#66: IOHDF5::out3D_ghosts and friends doesn't work and corrupts 2D data slices ----------------------------------+----------------------------------------- Reporter: bcmsma@… | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | ----------------------------------+----------------------------------------- While the assigned values for the parameters IOASCII::output_symmetry_points = "no" IOASCII::out3D_ghosts = "no" IOASCII::out3D_outer_ghosts = "no" work as intended when CarpetIOASCII is active, it doesn't work for CarpetIOHDF5: IOHDF5::out3D_ghosts = "no" IOHDF5::out3D_outer_ghosts = "no" IOHDF5::output_symmetry_points = "no" It doesn't do anything to the 3D data but it corrupts the 2D data slices while chopping out those regions. It would be nice to have them working for IOHDF5 method, specially when visualising Pi symmetric data. Note also that this report is for git version of Carpet. These parameters seem to become deprecated for the hg version. Does anyone use them regularly? Any substitute in mind? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/66> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #223: Make declaration of CCTK_ARGUMENTS safer
by Einstein Toolkit 01 Dec '11

01 Dec '11

#223: Make declaration of CCTK_ARGUMENTS safer -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I suggest to change the declaration of CCTK_ARGUMENTS in C from cGH * cctkGH to cGH const * CCTK_RESTRICT const cctkGH which should lead to safer code and may even enable some optimisations. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/223> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #234: Carpet mailing list is not functioning
by Einstein Toolkit 21 Nov '11

21 Nov '11

#234: Carpet mailing list is not functioning --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- The Carpet mailing list has been unavailable since 22-Mar-2010. This list provides a forum for discussion of Carpet features and issues, and would be the first port-of-call for new users. As such I think it would be good to resurrect the mailing list. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/234> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead?
by Einstein Toolkit 13 Nov '11

13 Nov '11

#145: EOS_Omni requires HDF5 library. What about if it only uses HDF5 instead? ---------------------------+------------------------------------------------ Reporter: bmundim | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: EOS_Omni HDF5 | ---------------------------+------------------------------------------------ At the moment EOS_Omni requires the HDF5 library to read the nuclear EOS values from a table. Since not all distros have fortran support for the HDF5 library as a default, I propose to change this requirement and provide a fall back in case this support is not present. Perhaps not using the nuclear EOS, or reading from an ASCII file instead. This could be just a temporary solution until the HDF5 library build script becomes more robust. Opinions? Thanks, Bruno. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/145> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #365: ADMBase: evolving with evolution_method="static" does not apply boundary conditions
by Einstein Toolkit 10 Nov '11

10 Nov '11

#365: ADMBase: evolving with evolution_method="static" does not apply boundary conditions ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- When one uses the evolution method ADMBASE::evolution_method = "static" (which is very tempting e.g. for Cowling), then no boundary conditions are applied. This means that the ADMBase variables remain unset on the boundaries after regridding, leading to all sorts of (rather unexpected) problems. The easy solution is to use thorn Exact instead, which applies an exact solution at each time step, including on the boundary. I suggest to remove the ADMBase functionality to provide a "static" evolution method, since this evolution method does not know which boundary condition to apply, and hence is bound to fail in non-trivial situations. Alternatively, ADMBase needs to synchronise in postregrid (and probably a few other bins as well). ADMBase should then also offer to apply an outer boundary condition, in this case probably a Minkowski Dirichlet boundary condition or a von Neumann condition. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/365> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #136: Don't rebuild external libraries so often
by Einstein Toolkit 08 Nov '11

08 Nov '11

#136: Don't rebuild external libraries so often -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- One way to keep the external libraries that have been built would be the following. Create a dummy configuration "ext" where all external libraries are built. When another configuration is built, it should be easy to specify to look there for the external libraries, or maybe this should even be the default. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/136> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 27

[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] #329: SimFactory/ranger-intel11.cfg: Are BLAS and LAPACK compilations on Ranger optimized?
by Einstein Toolkit 27 Oct '11

27 Oct '11

#329: SimFactory/ranger-intel11.cfg: Are BLAS and LAPACK compilations on Ranger optimized? -------------------------+-------------------------------------------------- Reporter: bmundim | Owner: mthomas Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- ranger-intel11.cfg now sets BLAS and LAPACK to be built along with the Cactus and other external libraries. Usually the host system BLAS and LAPACK are fine tuned to take advantage of the particular memory hierarchy of the host machine. I was wondering if this fine tuning is performed when we set BLAS = BUILD or LAPACK = BUILD, and, in case it is not, if it would be interesting to define Cactus env variables to set the size of the several cache memories for example and use it for this necessary fine tuning. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/329> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #271: python simfactory submit creates only the SubmitScript
by Einstein Toolkit 27 Oct '11

27 Oct '11

#271: python simfactory submit creates only the SubmitScript ----------------------------------------------+----------------------------- Reporter: alexander.beck-ratzka@… | Type: defect Status: new | Priority: major Milestone: | Component: Other Version: | Keywords: simfactory submit ----------------------------------------------+----------------------------- The python version of simfactory submit creates only the submitScript called PreparedSubmitScript. The RunScript is created at the moment of the simfactory run call at the end of the SubmitScript. So a user has no possibilty to check whether his settings e.g. for mpirun have been correct or not for all the time where the job is only queued. I feel this is not a user friendly solution. The RunScript should be created together with the SubmitScript. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/271> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

← Newer
1
2
3
4
5
6
7
...
14
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2011