Trac

trac@lists.einsteintoolkit.org

8708 discussions

[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] #1328: parameter file parser does not use correct value for parameters in equations
by Einstein Toolkit 09 May '13

09 May '13

#1328: parameter file parser does not use correct value for parameters in equations ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- The attached (three line) parfile fails with: {{{ WARNING level 0 in thorn Cactus processor 0 host horizon.tapir.caltech.edu (line 201 of /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/ProcessParameterDatabase.c): -> CCTKi_SetParameterSetMask: 1 major error in parameter file }}} ie it does not properly use the just set value "2" of carpet::ghost_zone and instead uses the default of "-1". I attach parfile and test output. This is very unfortunate since it means that the code silently (if the default ghost_size had been valid input for boundary_x_size_lower) uses wrong parameter values. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1328> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[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] #1311: SetMask_SphericalSurface sets mask incorrectly for multiple spheres
by Einstein Toolkit 09 May '13

09 May '13

#1311: SetMask_SphericalSurface sets mask incorrectly for multiple spheres ----------------------------------------+----------------------------------- Reporter: reisswig@… | Owner: Type: defect | Status: new Priority: blocker | Milestone: ET_2013_05 Component: EinsteinToolkit thorn | Version: development version Keywords: SetMask_SphericalSurface | ----------------------------------------+----------------------------------- SetMask_SphericalSurface loops over all spheres and sets points to "excised" within the sphere radius, and to "not excised" outside. Unfortunately, it clears the mask for each sphere individually, thus overwriting "excised" points from a previous sphere! The attached patch fixes this by first clearing the mask everywhere before looping over spheres, and then setting points to "excised" if inside a given sphere. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1311> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[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

[Einstein Toolkit] #1346: Upgrade zlib to 1.2.8
by Einstein Toolkit 07 May '13

07 May '13

#1346: Upgrade zlib to 1.2.8 -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2013_05 Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- "Version 1.2.8 fixes a very rare bug in decompression. All users are encouraged to upgrade immediately. " -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1346> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1349: rev 65 of breaks after recovery from checkpoint
by Einstein Toolkit 06 May '13

06 May '13

#1349: rev 65 of breaks after recovery from checkpoint -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Refluxing | -----------------------------------+---------------------------------------- it seems as is saved_regrid_epochs is not properly resized after checkpoint recovery (since it is only resized in basegrid and after refluxing happened). The attached patch resizes it in post_recover_variables to pick up changes in the grid structure picked up from the checkpoint file. Conceivably fixing the issue in http://cactuscode.org/pipermail/users/2013-February/003317.html is fixed this one goes aways as well. However until then we'd need a workaround. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1349> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1324: sefgfault caused by parameter file parsing
by Einstein Toolkit 06 May '13

06 May '13

#1324: sefgfault caused by parameter file parsing --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- the attached parfile (2 lines) fails with a segfault: {{{ Program received signal SIGSEGV, Segmentation fault. 0x00000000005ec9c4 in piraha::Value::doubleValue (this=0x0) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/piraha/Call.cc:143 143 if(type == PIR_REAL) (gdb) bt #0 0x00000000005ec9c4 in piraha::Value::doubleValue (this=0x0) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/piraha/Call.cc:143 #1 0x00000000005e7652 in piraha::meval (gr=...) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/piraha/Call.cc:495 #2 0x00000000005e8b0d in piraha::meval (gr=...) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/piraha/Call.cc:603 #3 0x00000000005e817b in piraha::meval (gr=...) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/piraha/Call.cc:552 #4 0x00000000005e7cee in piraha::meval (gr=...) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/piraha/Call.cc:524 #5 0x00000000005e794f in piraha::meval (gr=...) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/piraha/Call.cc:507 #6 0x00000000005e7763 in piraha::meval (gr=...) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/piraha/Call.cc:498 #7 0x00000000005e7371 in piraha::meval (gr=...) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/piraha/Call.cc:482 #8 0x00000000005eb154 in piraha::cctk_PirahaParser ( buffer=0x116c4f0 "ActiveThorns = \"ioutil Carpet CarpetLib LoopControl InitBase CarpetIOHDF5 HDF5\"\n\nCarpet::max_refinement_levels = 8\nIOHDF5::out_every = 2**(Carpet::max_refinement_levels-1)\n", buffersize=172, set_function=0x5c0b19 <CCTKi_SetParameter>) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/piraha/Call.cc:813 #9 0x00000000005c847c in ParseFile (ifp=0x116c2b0, set_function=0x5c0b19 <CCTKi_SetParameter>, ConfigData=0x7fffffffd680) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/util/ParseFile.c:140 #10 0x00000000005bcb12 in CCTKi_ProcessParameterDatabase (ConfigData=0x7fffffffd680) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/ProcessParameterDatabase.c:158 #11 0x00000000005b81e2 in CCTKi_InitialiseCactus (argc=0x7fffffffd67c, argv=0x7fffffffd670, config=0x7fffffffd680) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/InitialiseCactus.c:101 #12 0x00000000005b80df in main (argc=2, argv=0x7fffffffd788) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/flesh.cc:64 }}} I attach parfile and thornlist toreproduce. This uses rev 4997 of the flesh. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1324> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1344: Cactus doesn't export some environment variables after changing them
by Einstein Toolkit 02 May '13

02 May '13

#1344: Cactus doesn't export some environment variables after changing them --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2013_11 Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- Cactus doesn't export some environment variables after changing them. The attached patch fixes this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1344> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac