Trac May 2016

trac@lists.einsteintoolkit.org

1 participants
117 discussions

[Einstein Toolkit] #1656: CarpetInterp and MoL do not work properly together
by Einstein Toolkit 02 Nov '16

02 Nov '16

#1656: CarpetInterp and MoL do not work properly together --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- I am trying to integrate interpolated quantities using MoL. I call the interpolator in MoL_CalcRHS, and want it to perform only a spatial interpolation of the current content of timelevel 0. This current content is what has been set by MoL; it is not the final value that will be at t_{n+1} or was at t_N, but is the intermediate value that should be used when computing the RHS at a given MoL substep. Since MoL does not set the Carpet time hierarchy values, CarpetInterp seems to get confused about how to do the interpolation. I need to tell CarpetInterp not to interpolate in time at all, but to use timelevel 0 only. Unfortunately, setting the interpolator option to use only one timelevel does not work. There is commented-out code to "use cctk_time to decide whether to interpolate", which essentially guarantees that no time interpolation will happen (since the interpolation is requested for cctk_time, and the current time is cctk_time, so they are always equal). Re-enabling this code allowed me to achieve 4th order convergence for integrated interpolated quantities, though I am not sure I understand everything that is going on in CarpetInterp. I have added a parameter which controls this, and with this parameter set to the default, nothing changes (i.e. it is not going to change anyone's results unless they set the parameter). I would like to commit this, so that collaborators can work off the same version. Since the patch is very small, I hope this will not add too much unneeded complexity. Is it OK to commit? Patch is attached. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1656> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1622: Cannot log in to Blue Waters
by Einstein Toolkit 06 Oct '16

06 Oct '16

#1622: Cannot log in to Blue Waters ------------------------+--------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- With the new gsissh mechanism in Simfactory, I receive the error below when I try to log in. {{{ $ ./bin/sim --verbose login bluewaters Info: Simfactory command: ./bin/../simfactory/lib/sim.py "--verbose" "login" "bluewaters" Info: Version 2356M Info: The Simulation Factory: Manage Cactus simulations Info: defs: /Users/eschnett/Cvanilla/simfactory/etc/defs.ini Info: defs.local: /Users/eschnett/Cvanilla/simfactory/etc/defs.local.ini Info: Executing command: login Info: Logging into remote machine bluewaters Info: executing command: /bin/bash -c '{ :; } && { { mkdir -p /Users/eschnett/Cvanilla/.globus && : >> /Users/eschnett/Cvanilla/.globus/proxy-tfca-ncsa && chmod go-rwx /Users/eschnett/Cvanilla/.globus/proxy-tfca-ncsa && export X509_USER_PROXY=/Users/eschnett/Cvanilla/.globus/proxy-tfca-ncsa && : mkdir -p /Users/eschnett/Cvanilla/.globus/certificates-tfca-ncsa && : export X509_CERT_DIR=/Users/eschnett/Cvanilla/.globus/certificates-tfca- ncsa && { { grid-proxy-info -issuer -file /Users/eschnett/Cvanilla/.globus/proxy-tfca- ncsa 2>/dev/null | grep "^/C=US/O=National Center for Supercomputing Applications/" >/dev/null 2>&1 && test $(grid-proxy-info -timeleft -file /Users/eschnett/Cvanilla/.globus /proxy-tfca-ncsa 2>/dev/null) -gt 0 2>/dev/null } || { { grid-proxy-destroy 2>/dev/null || true; } && myproxy-logon -p 7512 -s tfca.ncsa.illinois.edu -T -l eschnett -o /Users/eschnett/Cvanilla/.globus/proxy-tfca-ncsa } } && { globus-update-certificate-dir >/dev/null 2>&1 || true; }; } && gsissh -o UserKnownHostsFile=/Users/eschnett/Cvanilla/simfactory/etc/ssh_known_hosts -t eschnett(a)h2ologin.ncsa.illinois.edu '\''cd /u/sciteam/eschnett/Cvanilla || echo "Could not change to directory /u/sciteam/eschnett/Cvanilla"; $SHELL -l'\''; }' Enter MyProxy pass phrase: Failed to receive credentials. Failed writing buffer to BIO Failed unpacking proxy certificate from buffer Error accepting delegated credentials: Failed writing buffer to BIO Failed unpacking proxy certificate from buffer Error while executing command "/bin/bash -c '{ :; } && { { mkdir -p /Users/eschnett/Cvanilla/.globus && : >> /Users/eschnett/Cvanilla/.globus/proxy-tfca-ncsa && chmod go-rwx /Users/eschnett/Cvanilla/.globus/proxy-tfca-ncsa && export X509_USER_PROXY=/Users/eschnett/Cvanilla/.globus/proxy-tfca-ncsa && : mkdir -p /Users/eschnett/Cvanilla/.globus/certificates-tfca-ncsa && : export X509_CERT_DIR=/Users/eschnett/Cvanilla/.globus/certificates-tfca- ncsa && { { grid-proxy-info -issuer -file /Users/eschnett/Cvanilla/.globus/proxy-tfca- ncsa 2>/dev/null | grep "^/C=US/O=National Center for Supercomputing Applications/" >/dev/null 2>&1 && test $(grid-proxy-info -timeleft -file /Users/eschnett/Cvanilla/.globus /proxy-tfca-ncsa 2>/dev/null) -gt 0 2>/dev/null } || { { grid-proxy-destroy 2>/dev/null || true; } && myproxy-logon -p 7512 -s tfca.ncsa.illinois.edu -T -l eschnett -o /Users/eschnett/Cvanilla/.globus/proxy-tfca-ncsa } } && { globus-update-certificate-dir >/dev/null 2>&1 || true; }; } && gsissh -o UserKnownHostsFile=/Users/eschnett/Cvanilla/simfactory/etc/ssh_known_hosts -t eschnett(a)h2ologin.ncsa.illinois.edu '\''cd /u/sciteam/eschnett/Cvanilla || echo "Could not change to directory /u/sciteam/eschnett/Cvanilla"; $SHELL -l'\''; }'": Command returned exit status 1 eschnett@Redshift:~/Cvanilla (16:40:03) $ ./bin/sim login bluewaters Enter MyProxy pass phrase: Failed to receive credentials. Failed writing buffer to BIO Failed unpacking proxy certificate from buffer Error accepting delegated credentials: Failed writing buffer to BIO Failed unpacking proxy certificate from buffer }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1622> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1865: Automatically start SystemTopology
by Einstein Toolkit 03 Oct '16

03 Oct '16

#1865: Automatically start SystemTopology ---------------------------------+------------------------------------------ Reporter: dradice@… | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: | ---------------------------------+------------------------------------------ Carpet used to load hwloc automatically and that would set thread affinities. Now this functionality is in the SystemTopology thorn, which is not automatically activated. This change could result in a significant performance regression on some systems (see discussion in #1850). Would it make sense to activate SystemTopology automatically? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1865> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #1873: Parameter file parser cannot handle empty files
by Einstein Toolkit 25 Sep '16

25 Sep '16

#1873: Parameter file parser cannot handle empty files ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- I used a parameter file that was empty except for comments: {{{ # ActiveThorns = "PUGH" # ActiveThorns = "MultiThreading" # ActiveThorns = "FunHPC" }}} Cactus complais about this: {{{ Activating thorn Cactus...Success -> active implementation Cactus WARNING level 0 from host process 0 while executing schedule bin (none), routine (no thorn)::(no routine) in thorn cactus, file multithreading.par:1: -> ERROR IN PARAMETER FILE:In rule 'file::skipper' Line=3, Column=84 # ActiveThorns = "PUGH" # ActiveThorns = "MultiThreading" # ActiveThorns = "FunHPC" }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1873> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[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] #1881: Unclear error message for parameter file error
by Einstein Toolkit 27 Jun '16

27 Jun '16

#1881: Unclear error message for parameter file error ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- I had this line in a parameter file {{{ ML_BSSN_FH_Helper::ML_BSSN_FH_CalculateRHSInMoLPostStep }}} which is missing the {{{= yes}}} at the end. This is a syntax error. I receive the following error message: {{{ ^[[1mWARNING level 0 from host zwicky002 process 0 while executing schedule bin (none), routine (no thorn)::(no routine) in thorn cactus, file mk-mclachlan-funhpc.par:1: ->^[[0m ERROR IN PARAMETER FILE:In rule 'file::set' Line=100, Column=95 # ML_BSSN_FH::block_size_i = 4 # ML_BSSN_FH::block_size_j = 4 # ML_BSSN_FH::block_size_k = 4 ML_BSSN_FH::ML_log_confac_bound = "none" ^ Expected one of the following characters: [\[ \t\r\n#=] }}} This error message is unclear because - it doesn't show the line that has the error; instead, it show only the lines that follow (and that are correct) - the set of "following characters" is correct, but I got confused by all the white space characters that are allowed; a description "expected [ or =" might have been more clear - the actual error is that there is a parameter, but this parameter is not followed by a value; this is not described, since the error message has a rather low level ("next character") instead of a high level ("value missing") -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1881> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[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

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2016