Trac August 2016

trac@lists.einsteintoolkit.org

1 participants
99 discussions

[Einstein Toolkit] #1955: Multipole: Add possibility to have out_dir distinct from regular IO:out_dir, but default to the old behavior
by Einstein Toolkit 02 Sep '16

02 Sep '16

#1955: Multipole: Add possibility to have out_dir distinct from regular IO:out_dir, but default to the old behavior -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-requests/2 /add-possibility-to-have-out_dir-distinct/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1955> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1954: GetComponents modifies its passed in thornlist file
by Einstein Toolkit 25 Aug '16

25 Aug '16

#1954: GetComponents modifies its passed in thornlist file ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ It seems to add {{{ # This file was automatically generated using the GetComponents script. }}} It should not do this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1954> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1953: TOVSolver's TOV_Populate_Timelevels option does not set alp_p, alp_pp or shift_p, shift_pp
by Einstein Toolkit 24 Aug '16

24 Aug '16

#1953: TOVSolver's TOV_Populate_Timelevels option does not set alp_p, alp_pp or shift_p, shift_pp -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: TOVSolver | -----------------------------------+---------------------------------------- TOVSolver offers an option to initialize past timelevels However this seems broken as it does not initialize past timelevels of the lapse and shift (but does eg of the metric). The code for this is in tov.c where alp_p does not occur at all. Most likely the option should be deprecated since Carpet's fill_3_timelevels does the same (and similar does MoL's initial_data_is_crap option). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1953> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1952: simfactory --substitute trys to modify a tuple
by Einstein Toolkit 23 Aug '16

23 Aug '16

#1952: simfactory --substitute trys to modify a tuple ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- Trying to use the {{{--substitute}}} option to simfactory I get: {{{ + simfactory/bin/sim submit --machine bluewaters --testsuite --walltime 4:0:0 --procs 8 --num-threads 4 --substitute SW_BLDDIR EinsteinToolkit/2016_05/cle5.2_gnu5.1.0/ET_2016_05 2016_05-swretest-16622-1471972677 Warning: Current Working directory does not match Cactus sourcetree, changing to /u/staff/rhaas/software /swtools-1.0/apps/linux/ET_2016_05 Traceback (most recent call last): File "simfactory/bin/../lib/sim.py", line 148, in <module> main() File "simfactory/bin/../lib/sim.py", line 144, in main CommandDispatch() File "simfactory/bin/../lib/sim.py", line 106, in CommandDispatch module.main() File "ET_2016_05/repos/simfactory2/lib/sim-manage.py", line 397, in main CommandDispatch() File "ET_2016_05/repos/simfactory2/lib/sim-manage.py", line 376, in CommandDispatch exec("command_%s()" % command) File "<string>", line 1, in <module> File "ET_2016_05/repos/simfactory2/lib/sim-manage.py", line 267, in command_submit restart.userSubmit(simulationName) File "ET_2016_05/repos/simfactory2/lib/simrestart.py", line 319, in userSubmit self.initRestart(simulationName) File "ET_2016_05/repos/simfactory2/lib/simrestart.py", line 255, in initRestart ret = self.load(simulationName) File "ET_2016_05/repos/simfactory2/lib/simrestart.py", line 88, in load self.BaseDir = simlib.GetBaseDir(machineEntry) File "ET_2016_05/repos/simfactory2/lib/simlib.py", line 250, in GetBaseDir basedir = DefineDatabase.SubAll(machineEntry.basedir) File "ET_2016_05/repos/simfactory2/lib/simsubs.py", line 230, in SubAll ss = self.PerformRegexSubstitutions(ss) File "ET_2016_05/repos/simfactory2/lib/simsubs.py", line 102, in PerformRegexSubstitutions rx_pair[1] = rx_pair[1].replace("@1@", r"\1") TypeError: 'tuple' object does not support item assignment }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1952> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1951: Cactus reports missing thorns only at end of parfile
by Einstein Toolkit 23 Aug '16

23 Aug '16

#1951: Cactus reports missing thorns only at end of parfile --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The current implementation of the the parfile parser reports thorns not present in the executable as originating from the last ActiveThorns line seens rather than from the one that actually mentions the thorn. Example: {{{ ActiveThorns = ThornThatDoesNotExist ActiveThorns = IOUtil ActiveThorns = AnotherThornThatDoesNotExist }}} {{{ $ cactus_sim parfile.par Activating thorn Cactus...Success -> active implementation Cactus Activation requested for --->ThornThatDoesNotExist IOUtil AnotherThornThatDoesNotExist <--- Error: Thorn AnotherThornThatDoesNotExist not found Error: Thorn ThornThatDoesNotExist not found Activation failed - 2 errors in activation sequence WARNING level 0 from host 8992d193.ncsa.illinois.edu process 0 while executing schedule bin (none), routine (no thorn)::(no routine) in thorn Cactus, file /home/rhaas/postdoc/gr/cactus/Zelmani/configs/bns_all/build/Cactus/main/SetParams.c:93: -> CCTKi_SetParameter: Error at line 3 in parameter file parfile.par while activating thorns WARNING level 0 from host 8992d193.ncsa.illinois.edu process 0 while executing schedule bin (none), routine (no thorn)::(no routine) in thorn Cactus, file /home/rhaas/postdoc/gr/cactus/Zelmani/configs/bns_all/build/Cactus/main/SetParams.c:93: -> CCTKi_SetParameter: Error at line 3 in parameter file parfile.par while activating thorns -------------------------------------------------------------------------- MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD with errorcode 1. }}} Mostly this confusing if one wants to jump to the right location in the file based on the supplied line number. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1951> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1950: no version tags past 2015_05 on trac
by Einstein Toolkit 18 Aug '16

18 Aug '16

#1950: no version tags past 2015_05 on trac -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: trac | -------------------------------------+-------------------------------------- The trac version dropdown box does not offer any versions beyond 2015_05 it seems. They are also not sorted in any obvious way. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1950> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[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] #1948: Formaline does not store configs directory properly
by Einstein Toolkit 16 Aug '16

16 Aug '16

#1948: Formaline does not store configs directory properly -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: Formaline | -----------------------------------+---------------------------------------- Since 8d244fc Formaline does not store the contents of eg configs/sim as configs/sim in the configs-Cactus tarball but as just "sim". This was done in an attempt to support "CACTUS_CONFIGS_DIR". However I think it would be better if Formaline continued to store configs/sim as configs/sim if CACTUS_CONFIGS_DIR is not set and to store CACTUS_CONFIGS_DIR/sim as configs/sim if CACTUS_CONFIGS_DIR is set. This would mean that the Formaline tarballs can in fact be simple uncompressed and compiled to get back the original executable as used to be the case in the past. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1948> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1947: Formaline does not archive Makefile CONTRIBUTERS and COPYRIGHT files correctly
by Einstein Toolkit 16 Aug '16

16 Aug '16

#1947: Formaline does not archive Makefile CONTRIBUTERS and COPYRIGHT files correctly -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: Formaline | -----------------------------------+---------------------------------------- Formaline's tarball for the Cactus flesh contains dangling links for Makefile CONTRIBUTERS and COPYRIGHT (most likely since the switch to a git based flesh repo). There is not real simple way to fix this (unless we can expect gnu tar in which case there is using the {{{--transform}}} option) using tar options only. It is part of the bigger issue of how to handle symbolic links in Formaline. A reasonable simple fix may be to create a temporary work dir for tar **copying** the content of Makefile CONTRIBUTERS and COPYRIGHT and making **symbolic links** for src and lib (no dereferencing is needed if they already **are** symbolic links). An alternative is to use git its update-index command to add files under a different name and then to export the archive using git archive. This would rely on git which may be less commonly available than tar though. This is a major bug since it means that Makefile is missing from the Formaline archive meaning one cannot compile the code using Formaline data alone. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1947> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2016