Trac March 2013

trac@lists.einsteintoolkit.org

1 participants
161 discussions

[Einstein Toolkit] #1221: Reduction weight anomaly when using zero CoordBase::boundary_shiftout_*
by Einstein Toolkit 17 May '13

17 May '13

#1221: Reduction weight anomaly when using zero CoordBase::boundary_shiftout_* ------------------------+--------------------------------------------------- Reporter: bentivegna | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | ------------------------+--------------------------------------------------- When using a refinement level that covers the entire grid, and setting the CoordBase::boundary_shiftout_* parameters to zero, the following warning appears: INFO (CarpetReduce): Simulation domain volume: 8000 INFO (CarpetReduce): Additional excised volume: 0 INFO (CarpetReduce): Reduction weight sum: 9141 WARNING level 1 in thorn CarpetReduce processor 0 host socket.local (line 137 of /Users/bennie/CactusTrees/TrueAMR/arrangements/Carpet/CarpetReduce/src/mask_test.c): -> Simulation domain volume and reduction weight sum differ This can be reproduced using the attached parameter file. The problem seems to arise at the boundaries of the restricted region: I would expect the coarse grid to carry zero reduction weight everywhere (as it does if the shiftout is one), but the boundaries have a non-zero weight instead, which leads to double counting, and hence the difference between domain volume and weight sum. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1221> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #1171: WeylScal4 schedule order is incorrect
by Einstein Toolkit 17 May '13

17 May '13

#1171: WeylScal4 schedule order is incorrect -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: WeylScal4 testsuite | -----------------------------------+---------------------------------------- WeylScal4 contains a calculation for computing the I and J invariants from the Psis. This calculation is not scheduled explicitly after the Psis. Therefore, Cactus will probably schedule the routines alphabetically, which should be wrong. This should be corrected either with an After or Schedule element in the calculation. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1171> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual
by Einstein Toolkit 10 May '13

10 May '13

#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Currently, simfactory knows about TerminationTrigger but not TriggerTerminationManual and sets the corresponding max_walltime parameter correctly for the first but not the second. This small patch does so also for the second thorn (found in Zelmani). This should be independent of the question why there are two of these thorns (which would be a good one to answer), or whether one of them could be retired or both of them merged. They are currently both used in production and simfactory should know about both. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1275> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #283: Update and make CoreDoc.pdf available in the EinsteinToolkit website
by Einstein Toolkit 10 May '13

10 May '13

#283: Update and make CoreDoc.pdf available in the EinsteinToolkit website -------------------------------------+-------------------------------------- Reporter: bmundim | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- The advanced concepts document: http://cactuscode.org/documentation/CoreDoc.pdf should be updated and made available in the ET website, both in pdf and html. Does anyone know where its .tex file version is located? Thanks, Bruno. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/283> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #931: CartGrid3D's dependency on Boundary
by Einstein Toolkit 10 May '13

10 May '13

#931: CartGrid3D's dependency on Boundary --------------------+------------------------------------------------------- Reporter: jtao | Owner: Type: defect | Status: new Priority: minor | Milestone: Cactus_4.1.0 Component: Cactus | Version: Cactus_4.0.0 Keywords: | --------------------+------------------------------------------------------- CartGrid3D_ApplyBC in CartGrid3D is scheduled in BoundaryConditions, which is defined in the Boundary thorn. I can see that this is related with the symmetric boundary conditions but could we handle it in boundary ? It seems to me that it is not a good idea to have the grid thorn depend on the boundary thorn. While making boundary depending on grid is more reasonable if we have to introduce the dependency between these two thorns. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/931> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #808: testsuites in HDF5
by Einstein Toolkit 10 May '13

10 May '13

#808: testsuites in HDF5 -------------------------+-------------------------------------------------- Reporter: jtao | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Cactus_4.1.0 Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Instead of constructing tools to compare Carpet ascii output from multiple processes, how about building tools to diff files HDF5 ? Compared to ASCII: HDF5 testsuites may have several advantages: small, fast, portable, independent of number of process. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/808> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #1111: Missing fortran compiler prevents CCTK_REAL8 from being defined.
by Einstein Toolkit 09 May '13

09 May '13

#1111: Missing fortran compiler prevents CCTK_REAL8 from being defined. ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: major | Milestone: Cactus_4.1.0 Component: Cactus | Version: Cactus_4.0.0 Keywords: | ---------------------+------------------------------------------------------ If the fortran compiler is missing or invalid, Cactus does not create the definition for CCTK_REAL8, CCTK_REAL4, etc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1111> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1290: parameter file parser fails to parse parameter name
by Einstein Toolkit 09 May '13

09 May '13

#1290: parameter file parser fails to parse parameter name --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- the attached parameter file (the rotor test from the ET MHD paper) fails with the current parameter parser: {{{ Activating thorn Cactus...Success -> active implementation Cactus ERROR IN PARAMETER FILE: In rule 'file::set::skipeol' Line=35 SpaceMask::use_mask="yes" EOS_Omni::gl_gamma=5./3. # try to mimic the core fluid EOS_Omni::poly_k = grhydro_initdata::rotor_pressin/grhydro_initdata::rotor_rhoin**EOS_Omni::gl_gamma ^ Expected one of the following characters: @a-zA-Z0-9_[*/%+\-<>!=&| \t\r#\n WARNING level 0 in thorn Cactus processor 0 host horizon.tapir.caltech.edu (line 167 of /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/ProcessParameterDatabase.c): -> CCTKi_SetParameterSetMask: 1 parsing errors in parameter file WARNING level 0 in thorn Cactus processor 0 host horizon.tapir.caltech.edu (line 167 of /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/ProcessParameterDatabase.c): -> CCTKi_SetParameterSetMask: 1 parsing errors in parameter file -------------------------------------------------------------------------- MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD with errorcode 0. }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1290> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1261: Suspicious logic in NewRad thorn
by Einstein Toolkit 09 May '13

09 May '13

#1261: Suspicious logic in NewRad thorn -----------------------------------------+---------------------------------- Reporter: wolfgang.kastaun@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: newrad boundary | -----------------------------------------+---------------------------------- In NewRad boundary conditions, there is some logic to determine for which faces/edges/corners BC should be applied. This logic is duplicated in two files, extrap.cc and newrad.cc. In the latter, there is the line (324 in the Oersted release) all_physbnd_or_ghostbnd = all_physbnd_or_ghostbnd and (is_physbnd[2*d+0] or not is_ipbnd[2*d+0]); for the left boundary, while the same thing for the right boundary reads all_physbnd_or_ghostbnd = all_physbnd_or_ghostbnd and (is_physbnd[2*d+1] or not is_ipbnd[2*d+1]); in line 337. In extrap.cc, the right boundary is treated the same, for the left one however we have in line 136 all_physbnd_or_ghostbnd = all_physbnd_or_ghostbnd and (is_physbnd[2*d+0] or is_ipbnd[2*d+0]); Note the "or" instead of "or not". I have no idea what this conditions are supposed to do, but it looks inconsistent. If it is correct, can someone enlighten me ? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1261> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #1173: ExternalLibraries build environment problems
by Einstein Toolkit 08 May '13

08 May '13

#1173: ExternalLibraries build environment problems -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: zlib hwloc | -----------------------------------+---------------------------------------- After updating to the latest hwloc in ExternalLibraries, I am running into trouble building it. The error is {{{ ../libtool: line 6000: cd: NO_BUILD/lib: No such file or directory libtool: link: cannot determine absolute directory name of `NO_BUILD/lib' }}} and I believe that this is caused by my having {{{ ZLIB_DIR = NO_BUILD }}} in my optionlist. This causes the following variables to be set: {{{ ZLIB_INC_DIRS=NO_BUILD/include ZLIB_LIB_DIRS=NO_BUILD/lib ZLIB_DIR=NO_BUILD }}} and hwloc now has the following references to these variables in its configure.sh script: {{{ export HWLOC_PCI_CFLAGS="$(echo $(for dir in ${PCIUTILS_INC_DIRS} ${ZLIB_INC_DIRS}; do echo $dir; done | sed -e 's/^/-I/'))" export HWLOC_PCI_LIBS="$(echo $(for dir in ${PCIUTILS_LIB_DIRS} ${ZLIB_LIB_DIRS}; do echo $dir; done | sed -e 's/^/-L/') $(for dir in ${PCIUTILS_LIBS} ${ZLIB_LIBS}; do echo $dir; done | sed -e 's/^/-l/'))" }}} The zlib configure.sh script has: {{{ # Set options if [ "${ZLIB_DIR}" = '/usr' -o "${ZLIB_DIR}" = '/usr/local' ]; then ZLIB_INC_DIRS='' ZLIB_LIB_DIRS='' else ZLIB_INC_DIRS="${ZLIB_DIR}/include" ZLIB_LIB_DIRS="${ZLIB_DIR}/lib" fi }}} I am setting ZLIB_DIR to NO_BUILD and I am not setting ZLIB_INC_DIRS or ZLIB_LIB_DIRS because the linker can find the zlib library without any additional options, but it is not installed in /usr or /usr/local. It is in fact in: {{{ /usr/lib/x86_64-linux-gnu/libz.a /usr/lib/x86_64-linux-gnu/libz.so }}} I think eventually the correct solution, as Erik has suggested in the past, is to attempt to build a small program which uses the library to find out whether any extra options are needed. In this case, this would succeed, and no variables would need to be set. As a simpler short-term solution, would it be correct to change the conditional to {{{ if [ "${ZLIB_DIR}" = '/usr' -o "${ZLIB_DIR}" = '/usr/local' -o "${ZLIB_DIR}" = 'NO_BUILD' ]; then }}} ? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1173> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 24

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2013