Trac April 2016

trac@lists.einsteintoolkit.org

1 participants
107 discussions

[Einstein Toolkit] #1816: segfaults on 64bit systems when build with c99
by Einstein Toolkit 17 Aug '16

17 Aug '16

#1816: segfaults on 64bit systems when build with c99 --------------------------------+------------------------------------------- Reporter: physik@… | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Cactus | Version: ET_2014_05 Keywords: | --------------------------------+------------------------------------------- I recently encountered a segfault in ScheduleInterface.c, more precisely in the function static int CCTKi_ScheduleCallFunction(void *function, t_attribute *attribute, t_sched_data *data) { /* find the timer for this function and this schedule bin */ t_timer *timer = attribute->timers; while (timer && strcmp(timer->schedule_bin, data->schedule_bin)) { timer = timer->next; } Running in the debugger revealed that timer->schedule_bin pointed to an invalid address. Curiously, it had the top 33 (33 not a typo) bits all set. Taking the lowest 32 bits gave a valid address which pointed to a reasonable string "CCTK_INITIAL". This suggests a 32/64 bit issue. The pointer timer->schedule_bin seems to be initialized in the same function using strdup: timer->schedule_bin = strdup (where); strdup is not part of the c99 standard, but only Posix. Compiling with gcc --std=c99 means it is not defined in <string.h>. This means the compiler treats the occurrence of strdup as an implicit function declaration, and assumes it returns int. Thus, it will do an implicit conversion of the result from int to char*. If the highest bit of the int was set, this resulted in a 64 bit pointer with all 32 high bits set (I checked with a small test code). When the address returned by the actual strdup code linked from glibc has the top 33 bits zero, the conversion yields the correct results. Therefore, the problem is hard to reproduce, it only occurred with a test case almost exhausting my workstations memory, but frustratingly not small tests. After this, I also found compiler warnings for ScheduleInterface.c of the type implicit declaration of function ‘strdup’ [-Wimplicit-function- declaration] and assignment makes pointer from integer without a cast [-Wint-conversion] Switching from --std=c99 to --std=gnu99 fixed the problem for now. However, this is a bug that might affect many users since the code compiles with --std=c99 and the compiler warnings are hidden within the thousands of other compiler warnings the ET code generates. Also, a quick grep revealed many occurrences of strdup, although some of them where redefined as Util_Strdup. The rest might lead to segfaults on 64 bit systems with std=c99. My findings concern the Wheeler release, I haven't had time to check the development version. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1816> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1791: Allow aligning the interior of grid functions in looping macros
by Einstein Toolkit 28 Jun '16

28 Jun '16

#1791: Allow aligning the interior of grid functions in looping macros -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Currently, when grid functions are aligned, Cactus expects their origin to be aligned. These changes update the looping macros to allow aligning the interior of grid functions instead. Whether and how grid functions are aligned is still determined by the driver -- this only makes it possible to still use the looping macros in this case. Implemented in <https://bitbucket.org/cactuscode/cactus/pull-request/16 /allow-aligning-the-interior-of-grid/diff> and <https://bitbucket.org/cactuscode/cactustest/pull-request/1/allow- aligning-the-interior-of-grid/diff>. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1791> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1858: CarpetLib: "balanced" recomposition fix
by Einstein Toolkit 28 Jun '16

28 Jun '16

#1858: CarpetLib: "balanced" recomposition fix ----------------------+----------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: optional | Milestone: Component: Carpet | Version: development version Keywords: | ----------------------+----------------------------------------------------- This pull request fixes some things that I believe are broken for this algorithm. I am not claiming that it now works correctly, but it works 'more correct' this way. I came across these issues while looking at some of the implemented recomposition algos, but will not use this particular one in the future. However, I think it might be useful for someone else, so here it is. https://bitbucket.org/eschnett/carpet/pull-requests/10/recompose-balance- partial-fix/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1858> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1657: ExternalThorns/pciutils ignores most option list options
by Einstein Toolkit 28 Jun '16

28 Jun '16

#1657: ExternalThorns/pciutils ignores most option list options -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: pciutils | -----------------------------------+---------------------------------------- It does not contain a configure script and its Makefile hard-codes the compiler and linker to be gcc. This is an issue if LDFLAGS (or CFLAGS possibly) contain {{{-openmp}}} like they do when using the intel compiler. Also using mkl could (should) be done with the {{{-mkl}}} switch to the intel compiler but gcc (as used in pciutils) will naturally not accept this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1657> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1697: testing system starts tests for which thorns are missing
by Einstein Toolkit 27 Jun '16

27 Jun '16

#1697: testing system starts tests for which thorns are missing --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- We apparently have a bug in the perl script that drives the testsuite. On hydra (a machine at RZG that Ian and I are testing) it tries to run the test_ah test of Dissipation even though that test parfile uses NoExcision which is commented out. A quick test indicates that the script only looks at the first ActiveThorns line in the parfile when it determines if a parfile is runnable. Movin NoExcision into the first ActiveThorns line correctly ignores the test on hydra. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1697> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1623: using ENV in parfiles is not documented
by Einstein Toolkit 25 Jun '16

25 Jun '16

#1623: using ENV in parfiles is not documented ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: documentation | ---------------------------+------------------------------------------------ the user guide does not explain how to use ENV in parfiles (at least grep ENV doc/UsersGuide/*.tex does not find anything) nor do the peg files in src/piraha/peg contain. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1623> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1862: Patch: make Refluxing infrastructure independent of GRHydro
by Einstein Toolkit 24 Jun '16

24 Jun '16

#1862: Patch: make Refluxing infrastructure independent of GRHydro -----------------------------------+---------------------------------------- Reporter: dradice@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- GRHydro can optionally run with conservative AMR using the "Refluxing" thorn. The infrastructure for refluxing is very generic, but the "Refluxing" thorn currently contains GRHydro-specific code that makes it incompatible with any other solver. To overcome this limitation, I prepared: 1. A patched version of the Refluxing thorn, with a generic MoL-like registration mechanism for the fluxes 2. A new thorn containing all of the old GRHydro-specific code from Refluxing. The new code passes all existing tests and allow other (M)HD thorns to register variables for refluxing in a very simple way. The code is in two git repositories on bitbucket: https://bitbucket.org/dradice/refluxing https://bitbucket.org/dradice/grhydro_refluxing Notes: 1. GRHydro parfiles that use conservative AMR should be modified to include GRHydro_Refluxing 2. The new Refluxing thorn no longer supports delayed refluxing, which was never used for any production run, and/or special GRHydro-specific atmosphere hacks. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1862> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1868: automatically resubmit if terminated due to walltime
by Einstein Toolkit 14 Jun '16

14 Jun '16

#1868: automatically resubmit if terminated due to walltime -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- This patch adds code to datura's run script that detect if the run was terminated due to walltime running out. In that case it will resubmit the job automatically. This is an alternative over presubmission which is often more convenient for the user in case simulations fail. Presubmission itself would benefit by Cactus returning a failure code (that simfactory would need to forward) when termination is triggered by an error. The pull request is here: https://bitbucket.org/simfactory/simfactory2 /pull-requests/9/datura-automatically-resubmit-if/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1868> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1759: need tensorparity=-1 for WeylScal4::curvIi_group and curvJi_group
by Einstein Toolkit 13 Jun '16

13 Jun '16

#1759: need tensorparity=-1 for WeylScal4::curvIi_group and curvJi_group ------------------------------------+--------------------------------------- Reporter: physicsbeany@… | Owner: Bernard Kelly Type: defect | Status: new Priority: minor | Milestone: ET_2014_11 Component: EinsteinToolkit thorn | Version: development version Keywords: weylscal4, parity | ------------------------------------+--------------------------------------- The WeylScal4 gridfunctions curvIi and curvJi are pesudoscalars with the same parity properties as Psi2r and Psi2i. However, they're currently assigned no tensorparity attribute, so they're treated as scalars. As a result, for a z-aligned Kerr BH (EinsteinInitialData/IDAnalyticBH) evolved with reflection symmetry across the x-y plane, an interpolation of curvIi to a coordinate sphere will yield different values for the z<0 points than the same data on a full grid. Can we set "tensorparity=-1" for both these groups, to fix this issue? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1759> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1853: diagonal output in CarpetIOHDF5 disabled
by Einstein Toolkit 13 Jun '16

13 Jun '16

#1853: diagonal output in CarpetIOHDF5 disabled --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- Commit 37f5f2e "CarpetIOHDF5: Optimize lower-dimensional output -- only transfer necessary data to the I/O process" disables diagonal output, yet the parameters for it are still present. Lack of diagonal output in hdf5 files is most likely acceptable, but the fact should be at least documented. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1853> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

← Newer
1
...
5
6
7
8
9
10
11
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2016