Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1972: GetComponents fails if the target path contains a space
by Einstein Toolkit 07 Nov '16

07 Nov '16

#1972: GetComponents fails if the target path contains a space ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: Type: defect | Status: new Priority: blocker | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ The following fails: {{{ mkdir "Google Drive" cd "Google Drive" GetComponents https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2016_05/einsteintoolk… }}} since the git handler (at least) does not properly quote the arguments it passes to git and git complains about too many arguments. Related to this: GetComponents does not output stderr for failed commands and it likely should (this may involve interfacing with Perl's IPC module). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1972> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1978: OpenBLAS build error on some machines
by Einstein Toolkit 07 Nov '16

07 Nov '16

#1978: OpenBLAS build error on some machines -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- Recent OpenBLAS versions don't compile on some machines when using the Intel compiler, which includes supermic and queenbee2 at LSU. A related OpenBLAS ticket is https://github.com/xianyi/OpenBLAS/issues/962 Tagging 'minor', as OpenBLAS is by default disabled within the ET thornlist. Because of this, this bug should only hit machines which specifically enable OpenBLAS. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1978> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[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] #1958: parfiles accept 1.0, 0.0, 1e3 for integer typed parameters
by Einstein Toolkit 20 Oct '16

20 Oct '16

#1958: parfiles accept 1.0, 0.0, 1e3 for integer typed parameters ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- Currently I can put {{{ Cactus::cctk_itlast = 1.0e3 }}} into a parameter file and Cactus will accept this parfile ({{{cctk_itlast = 0.5}}} fails). My feeling would that it is better only allow "[-+]?[0-9]+" for integers and not accept everything and then check afterwards if it could be converted to an integer without loss of accuracy. This probably changed when the parfile gained the ability to evaluate expressions (both using piraha and before). Mostly I am concerned that accepting floating point numbers that have integer values can mask errors in parfile generating scripts (eg I have one that apparently sets Llama's n_angular to 24.0) and which will crop up when the input to the parfile generator changes a bit. Maybe the simplest way to achieve this is, is to test like this: {{{ char valuestring[]; char *endp; long int intval = strtol(valuestring, &endptr, 10); if(*endptr && (strdod(valuestring, &endptr), !*endptr)) { CCTK_VERROR("Float given for int parameter"); } }}} which tests if the parameter cannot be converted to an integer but can be converted to a floating-point number. I believe there is already a similar test in the parfile code to check if valuestring is a constant or an expression. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1958> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 26

[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] #1964: Binary neutron star sample has poor OpenMP parallelization
by Einstein Toolkit 06 Oct '16

06 Oct '16

#1964: Binary neutron star sample has poor OpenMP parallelization -----------------------------------+---------------------------------------- Reporter: anonymous | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: NsNs | -----------------------------------+---------------------------------------- When running the sample from the ETK/gallery page the number of OpenMP threads seems to be limited to 2, showing only 200% in top, although 16 OMP threads were used. Other param files from /par go way beyond 1000%, showing that more threads are fully used. Could it be that there is a omp_set_num_threads(2) somewhere in the hydro code? http://einsteintoolkit.org/about/gallery/NsNsToHMNS/ Creating 1 MPI process per core fixes the issue, obviously, and the CPU is fully utilized -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1964> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1971: GRHydro: comment fprintf if eps<0, and explicitly instantiate templates
by Einstein Toolkit 05 Oct '16

05 Oct '16

#1971: GRHydro: comment fprintf if eps<0, and explicitly instantiate templates -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2016_11 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The output for eps<0 is done using fprintf, which is bad anyway, and can potentially lead to problems with large output files - not to mention how to deal with this in a multi-process MPI run. This only disables the crude output. It does not change the behaviour of the code itself. Instantiation of all three versions is needed in any case, and making this explicit potentially reduces copies of the same code used in different files. These two changes are implemented the pull request https://bitbucket.org/einsteintoolkit/einsteinevolve/pull- requests/8/parma/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1971> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1968: Output time stamp in verbose build log
by Einstein Toolkit 04 Oct '16

04 Oct '16

#1968: Output time stamp in verbose build log -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Timestamp includes sub-second granularity when available, and uses Perl to do so in a more portable way than 'date' likely could. At the same time, don't let 'make' output the commands necessary to generate this debug output. This is not useful, except when debugging the debug output, which likely a user will never do. Pull-request at https://bitbucket.org/cactuscode/cactus/pull-requests/32 /output-time-stamp-in-verbose-build-log/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1968> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1962: OpenBlas fails to compile on modern laptop
by Einstein Toolkit 03 Oct '16

03 Oct '16

#1962: OpenBlas fails to compile on modern laptop -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: blocker | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: OpenBLAS | -----------------------------------+---------------------------------------- It seems as if the cpuid_x86.c in OpenBlas (0.2.13) does not recognize anything newer than Haswell CPUs so fails on my skylake laptop (i7-6500U). According to the changelong http://www.openblas.net/Changelog.txt we'd need at least Version 0.2.15 from Otctober 2015 to make this work. This is a blocker for affected systems since one cannot compile. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1962> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac