Trac February 2013

trac@lists.einsteintoolkit.org

1 participants
177 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] #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] #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] #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] #1256: scheduling MoL_PostStep in Post_Recover_Variables
by Einstein Toolkit 25 May '13

25 May '13

#1256: scheduling MoL_PostStep in Post_Recover_Variables --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: task | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: MoL | --------------------+------------------------------------------------------- this is not ideal since some routines in MoL_PostStep will always change results (eg. Con2Prim). We already removed MoL_PostStep from the past timelevels since the prolongation cannot be handled properly. Originally (MoL rev 137, https://trac.einsteintoolkit.org/changeset/137/CactusNumerical/MoL) was introduced to enforce boundary conditions and recompute the ADM variables. Since then the policy has changed and the ADM variables are supposed to be checkpointed (rule of thumb is that anything with more than one timelevels should be checkpointed). When recovering from a checkpoint the boundary conditions are currently satisfied since CarpetIOHDF5 reads in everything that it can, incl. data in ghost and boundary zones. This method ensures that bit identical data is read in. Unfortunately running MoL_PostStep then changes values. It seems as if MoL_PostStep is never required so should not be run. The attached trivial patch adds a parameter to MoL to disable running in Post_Recover_Variables. Note that this is not yet are request for review but a work item since more testing is required to decide if anything breaks when MoL_PostStep is not run. Tests done with GRHydro (and changes so that eg. the atmosphere mask is identical in ghost zones [currently it is not valid in ghost zones but also never checked in ghost zones]) gives bit identical results even when changing the number of processors while recovering. This is a very simple test though. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1256> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

[Einstein Toolkit] #705: Activation Order in Parameter Files
by Einstein Toolkit 24 May '13

24 May '13

#705: Activation Order in Parameter Files -------------------------+-------------------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Cactus_4.1.0 Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- At the moment the ActiveThorns list is sensitive to the order in which thorns are activated if the ActiveThorns parameter is updated multiple times. However, it is not sensitive to the order in which thorns are activated if all thorns are specified in a single line. This inconsistency should be removed, and the order should not matter in either case. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/705> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #526: Reorder ticket states
by Einstein Toolkit 23 May '13

23 May '13

#526: Reorder ticket states ----------------------------------+----------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- The order in which the ticket states is displayed (in the form where one modifies the ticket state) should be the natural order in which a ticket progresses. The current order is somewhat random. I suggest this order: new confirmed accept reassign review resolve -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/526> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #519: Add all ET repositories to TRAC
by Einstein Toolkit 23 May '13

23 May '13

#519: Add all ET repositories to TRAC ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- TRAC provides integration with version control systems. It has a list of repositories, and specific changesets and files can be referred to in ticket comments and wiki pages using a convenient syntax. Several ET repositories have been added already. I think this feature is useful, and that the remaining repositories should be added. It would be nice if the links were easier to type. I propose omitting the arrangement name from the repositories, as all thorn names are probably unique, and avoiding spaces which require extra quoting. We have several repositories in Git and Mercurial. It would be nice to include those as well. I believe that there are TRAC plugins to accomplish this in the same way as for SVN. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/519> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1232: Improve output format of Carpet timer trees
by Einstein Toolkit 23 May '13

23 May '13

#1232: Improve output format of Carpet timer trees -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- Marek Blazewicz reports: I was using the timer tree in Carpet. Because it was not too nicely outputted, and I had to format it manually each time, I've fixed it ;). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1232> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1184: Update ubuntu.cfg
by Einstein Toolkit 23 May '13

23 May '13

#1184: Update ubuntu.cfg -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- I suggest to update ubuntu.cfg: - remove some outdated comments - consolidate Fortran line length options - add -ffast-math - correct Fortran OpenMP flag - move -rdynamic to LDFLAGS - add -Wall {{{ $ svn diff ubuntu.cfg Index: ubuntu.cfg =================================================================== --- ubuntu.cfg (revision 1854) +++ ubuntu.cfg (working copy) @@ -19,38 +19,32 @@ CPPFLAGS = -DMPICH_IGNORE_CXX_SEEK FPPFLAGS = -traditional -# no -msse3 -CFLAGS = -g3 -march=native -std=gnu99 -rdynamic -CXXFLAGS = -g3 -march=native -std=gnu++0x -rdynamic +CFLAGS = -g3 -march=native -std=gnu99 +CXXFLAGS = -g3 -march=native -std=gnu++0x F77FLAGS = -g3 -march=native -fcray-pointer -ffixed-line-length-none -F90FLAGS = -g3 -march=native -fcray-pointer -ffixed-line-length-none -LDFLAGS = +F90FLAGS = -g3 -march=native -fcray-pointer -ffixed-line-length-none -ffree-line-length-none +LDFLAGS = -rdynamic -LIBDIRS = +LIBDIRS = C_LINE_DIRECTIVES = yes F_LINE_DIRECTIVES = yes -# -check-uninit fails for asm output operands DEBUG = no CPP_DEBUG_FLAGS = -DCARPET_DEBUG FPP_DEBUG_FLAGS = -DCARPET_DEBUG C_DEBUG_FLAGS = -O0 CXX_DEBUG_FLAGS = -O0 -F77_DEBUG_FLAGS = -O0 -ffixed-line-length-none -F90_DEBUG_FLAGS = -O0 -ffree-line-length-none +F77_DEBUG_FLAGS = -O0 +F90_DEBUG_FLAGS = -O0 -# On Abe, the options -O3, -xT, and -ip lead to segmentation faults -# near MPI calls -# With Intel 9, using -ip prevents debug information for local variables -# With Intel 9, using -O3 leads to very long compile times (> 45 minutes) OPTIMISE = yes CPP_OPTIMISE_FLAGS = -DKRANC_VECTORS # -DCARPET_OPTIMISE -DNDEBUG FPP_OPTIMISE_FLAGS = # -DCARPET_OPTIMISE -DNDEBUG -C_OPTIMISE_FLAGS = -O2 -CXX_OPTIMISE_FLAGS = -O2 -F77_OPTIMISE_FLAGS = -O2 -F90_OPTIMISE_FLAGS = -O2 +C_OPTIMISE_FLAGS = -O2 -ffast-math +CXX_OPTIMISE_FLAGS = -O2 -ffast-math +F77_OPTIMISE_FLAGS = -O2 -ffast-math +F90_OPTIMISE_FLAGS = -O2 -ffast-math PROFILE = no CPP_PROFILE_FLAGS = @@ -62,21 +56,23 @@ OPENMP = no CPP_OPENMP_FLAGS = -fopenmp -FPP_OPENMP_FLAGS = -D_OPENMP +FPP_OPENMP_FLAGS = -fopenmp C_OPENMP_FLAGS = -fopenmp CXX_OPENMP_FLAGS = -fopenmp F77_OPENMP_FLAGS = -fopenmp F90_OPENMP_FLAGS = -fopenmp WARN = yes -CPP_WARN_FLAGS = -FPP_WARN_FLAGS = -C_WARN_FLAGS = -CXX_WARN_FLAGS = -F77_WARN_FLAGS = -F90_WARN_FLAGS = +CPP_WARN_FLAGS = -Wall +FPP_WARN_FLAGS = -Wall +C_WARN_FLAGS = -Wall +CXX_WARN_FLAGS = -Wall +F77_WARN_FLAGS = -Wall +F90_WARN_FLAGS = -Wall -MPI_DIR = /usr + + +MPI_DIR = /usr MPI_INC_DIRS = /usr/include/mpich2 MPI_LIB_DIRS = /usr/lib MPI_LIBS = mpich fmpich mpl }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1184> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

← Newer
1
...
8
9
10
11
12
13
14
...
18
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2013