Trac February 2016

trac@lists.einsteintoolkit.org

1 participants
95 discussions

[Einstein Toolkit] #1819: CarpetMask: add option to exclude boxes
by Einstein Toolkit 16 Jan '17

16 Jan '17

#1819: CarpetMask: add option to exclude boxes -------------------------------------+-------------------------------------- Reporter: bmundim | Owner: eschnett Type: enhancement | Status: new Priority: unset | Milestone: Component: Carpet | Version: development version Keywords: CarpetMask CarpetReduce | -------------------------------------+-------------------------------------- I would like to be able to exclude boxes in addition to spherical surfaces when setting the CarpetMask::weight (which is used by CarpetReduce to exclude regions when performing reductions). The following pull request implements this functionality: {{{ https://bitbucket.org/eschnett/carpet/pull-requests/5/bcm-carpetmask/diff }}} I have some parameter files I used to test my implementation. I can turn them into testsuites after the revision of this ticket. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1819> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #394: Testsuite log file should contain more information
by Einstein Toolkit 12 Dec '16

12 Dec '16

#394: Testsuite log file should contain more information -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: testsuites | -------------------------+-------------------------------------------------- It is useful to look at the testsuite log file for information about how the tests were run. For example, which compiler was used, and with what compiler options. We need to balance this against providing information which will always change, making diffs hard to read. The most extreme case would be to output all make variables. Maybe better would be to output CC, CFLAGS, CXX, etc. Another option would be to parse these and say "intel compiler", "gcc", "pgi" etc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/394> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1717: hwloc: lnuma & lltdl *really* required?
by Einstein Toolkit 06 Dec '16

06 Dec '16

#1717: hwloc: lnuma & lltdl *really* required? -----------------------------------+---------------------------------------- Reporter: zachetie@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- I downloaded the ET devel version (ca. Nov 26) on my (ubuntu) laptop and compiled it, using gcc. I compiled to the linker stage, and the linker complained: ld: cannot find -lnuma ld: cannot find -lltdl I found references to these libraries in: configs/[buildname]/bindings/Configuration/Capabilities/make.HWLOC.defn After removing these references, the code compiled and seemed (on the surface) to run okay. Are these libraries really necessary? I ask because every time I need to install ET on a new machine, it would be more convenient if the step "apt-get install libnuma-dev libltdl-dev" were left out, particularly since reliable Internet access may not exist at that time. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1717> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 35

[Einstein Toolkit] #1835: simfactory website contains incorrect download location
by Einstein Toolkit 06 Dec '16

06 Dec '16

#1835: simfactory website contains incorrect download location ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- The simfactory website at http://simfactory.org/simfactory/download/ contains incorrect download instructions for simfactory2 since it still refers to the svn repository instead of the bitbucket one. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1835> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[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] #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

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2016