Trac February 2017

trac@lists.einsteintoolkit.org

2 participants
95 discussions

[Einstein Toolkit] #2000: support radial boundary conidtion with Llama in NewRad
by Einstein Toolkit 17 Mar '17

17 Mar '17

#2000: support radial boundary conidtion with Llama in NewRad -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: NewRad | -----------------------------------+---------------------------------------- This implements the radially outgoing boundary condition on Llama's spherical grid. I (Roland) checked that the expressions agree with what CTGamma implements in its CTGRadiativeBC/src/calc_rhs.h, Ian checked that the physics makes sense. To use the this the user needs to set the parameter z_is_radial explicitly rather than in CTGamma where CTGRadiativeBC decides this on its own based on its knowledge of Llama's coordinate systems. If one really wanted to risk being clever one could likely try and auto-detect this like so: {{{ z_is_radial = (r[CCTK_GFINDEX3D(cctkGH, 0,0,1)] != r[CCTK_GFINDEX3D(cctkGH, 0,0,0)]) && (r[CCTK_GFINDEX3D(cctkGH, 0,1,0)] == r[CCTK_GFINDEX3D(cctkGH, 0,0,0)]) && (r[CCTK_GFINDEX3D(cctkGH, 1,0,0)] == r[CCTK_GFINDEX3D(cctkGH, 0,0,0)]); }}} though this is obviously not fully safe as it only tests at a single point. Pull request is here: https://bitbucket.org/einsteintoolkit/einsteinevolve /pull-requests/9/newrad-add-simple-support-for-llama-outer/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2000> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1276: Intel 2013.1.117 mis-compiles NewRad
by Einstein Toolkit 16 Mar '17

16 Mar '17

#1276: Intel 2013.1.117 mis-compiles NewRad -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: NewRad | -----------------------------------+---------------------------------------- Intels compiler fails (with -O2) to push values for bmin onto the stack in lines 316 of newrad.cc and line 126 of extrap.cc. Adding printf's for bmin perturbs the bug out of existence, but adding a printf of the address of bmax and reveals that at the time extrap_kernel is call the integer just before this address is still the initialization value of bmin[2] and not the correct value. The attached patch disables optimization for the two driver functions affected (but not the actual kernel). The patch is specific (via an #if) for this particular compiler and version. What is the best way of handling this? Target any intel version starting from the known failing one until we know of known good one? Or starting from an older known good one (that would be intel 11 in my case). Hopefully no similar bug is triggered by Carpet's use of the same idiom. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1276> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 54

[Einstein Toolkit] #1439: SSL certificate check failing
by Einstein Toolkit 16 Mar '17

16 Mar '17

#1439: SSL certificate check failing --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- The check for SSL certificates in line 535: {{{#perl # check for svn SSL problems if ( $rec{"TYPE"} eq "svn" && defined $rec{"AUTH_URL"} ) { my $base = $rec{"AUTH_URL"}; $base =~ s/(https\:\/\/[\w\.]+)\/(.*)$/$1/i; unless ( defined $svn_servers{$base} ) { my $ret = `$svn --non-interactive info $rec{AUTH_URL} 2>&1`; if ( $ret =~ /Server certificate verification failed/ ) { $svn_servers{$base} = 0; } else { $svn_servers{$base} = 1; } } } }}} is incorrect since eg for the ET manifest where {{{ AUTH_URL=https://svn.einsteintoolkit.org/$1/trunk }}} the executed svn command is: {{{ svn --non-interactive info https://svn.einsteintoolkit.org/$1/trunk 2>&1 }}} which actually returns and error: {{{ svn: E175002: Unable to connect to a repository at URL 'https://svn.einsteintoolkit.org/trunk' svn: E175002: The OPTIONS request returned invalid XML in the response: XML parse error at line 1: Extra content at the end of the document (https://svn.einsteintoolkit.org/trunk) }}} but the code does not test for svn failures at all at this point. The simplest fix would be to move the check further down where {{{$1}}} has been replaced by an actual value, eg into the loop: {{{ # we are splitting each group of components into individuals # to check for existence. they will now be passed individually to # the checkout/update subroutines. this will take up more memory, # but it should make it easier if the user decides to add another # component from the same repository later my @checkouts = split( /\s+/m, $rec{"CHECKOUT"} ); foreach my $checkout (@checkouts) { }}} in line 565 which however causes the test to run for every single CHECKOUT item. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1439> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1985: GetCOmponents does not follow HTTP redirection when downloading via curl
by Einstein Toolkit 15 Mar '17

15 Mar '17

#1985: GetCOmponents does not follow HTTP redirection when downloading via curl ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: development version Keywords: | ---------------------------+------------------------------------------------ The pull request: https://github.com/gridaphobe/CRL/pull/3 adds {{{--location}}} to curl calls to make curl follow redirects. wget follows the redirect without further options. The branch also contains two cleanup commits that remove unused code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1985> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1983: Multipole: ouput all hdf5 modes at once
by Einstein Toolkit 15 Mar '17

15 Mar '17

#1983: Multipole: ouput all hdf5 modes at once -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: Multipole | -----------------------------------+---------------------------------------- This change reduces the number of times the same file is opened and closed from once per mode and radius to once per output iteration. This is very beneficial on clusters with slow metadata performance (which currently means all "big" clusters that run lustre). Pull request is: https://bitbucket.org/einsteintoolkit/einsteinanalysis/pull-requests/5 /multipole-ouput-all-hdf5-modes-at-once/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1983> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #2010: links to thorn guides non functional
by Einstein Toolkit 07 Mar '17

07 Mar '17

#2010: links to thorn guides non functional -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: | -------------------------------------+-------------------------------------- The links to thorn guides on http://einsteintoolkit.org/guides/thorn- guide.html are non-functional, eg leading to http://einsteintoolkit.org/guides/CactusUtil/Nice/ for the Nice thorn. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2010> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1771: Improve performance of CarpetInterp2 interpolation
by Einstein Toolkit 06 Mar '17

06 Mar '17

#1771: Improve performance of CarpetInterp2 interpolation -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | -------------------------+-------------------------------------------------- The branch https://bitbucket.org/eschnett/carpet/branch/ianhinder/fasterp_opt#diff contains an optimisation to the CarpetInterp2 interpolation routine which improved the performance of Llama interpatch interpolation in my test by a factor of 5. I did this a while ago, and haven't looked at it recently. Before merging, the following should be done: 1. Check that is applies cleanly to the current version of Carpet 2. Decide whether the vectorisation pragmas need to be protected by Cactus preprocessor guards Or any other changes which people think might be necessary. This should wait until after the upcoming (May 2015) release of the ET. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1771> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #2012: ET wiki is not mobile friendly
by Einstein Toolkit 23 Feb '17

23 Feb '17

#2012: ET wiki is not mobile friendly -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: development version Keywords: wiki | -------------------------------------+-------------------------------------- The current ET wiki does not support mobile devices in any way as far as I can tell. There are MediaWiki extensions available that fix this. One of them being developed, maintained and used by wikipedia: https://www.mediawiki.org/wiki/Manual:Mobiles,_tablets_and_responsive_design I would like to suggest that we install the extension in our wiki. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2012> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2011: provide fortran MPI bindings
by Einstein Toolkit 22 Feb '17

22 Feb '17

#2011: provide fortran MPI bindings -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: MPI | -----------------------------------+---------------------------------------- The MPI external library currently does not provide Fortran bindings for MPI. I observe this on a Linux box with OpenMPI installed and mpicxx in the path and with no MPI_XXX set in my option list. ExternalLibraries/MPI parses the output of mpicxx -showme:link which I verified to happen by inspecting its output and bindings/Configuration/Capabilities/make.MPI.defn. For the autodetection we'd have to also consider the output of mpif90 -showme:link and likely also mpif77 showme:link in case the F90 interfaces are somewhere other than the (typeless) f77 interfaces. This can be impossible for the case where we build OpenMPI with the toolkit since OpenMPI will provide either F2008 or F90 bindings depending on the compiler and the libraries for the two have different names. This however is something that is only decided in OpenMPI's own configure script. We also need to make sure mpi.mod and mpif.h are found by Fortran's "USE" and "INCLUDE" statements respectively. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2011> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2009: track website error
by Einstein Toolkit 20 Feb '17

20 Feb '17

#2009: track website error -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Server Infrastructure | Version: development version Keywords: | -----------------------------------+---------------------------------------- Hello all, two times in the last couple days I have received the following error when trying to login to the trac website: {{{ Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/trac/web/api.py", line 436, in send_error data, 'text/html') File "/usr/lib/python2.4/site-packages/trac/web/chrome.py", line 803, in render_template message = req.session.pop('chrome.%s.%d' % (type_, i)) File "/usr/lib/python2.4/site-packages/trac/web/api.py", line 212, in __getattr__ value = self.callbacks[name](self) File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 298, in _get_session return Session(self.env, req) File "/usr/lib/python2.4/site-packages/trac/web/session.py", line 156, in __init__ if req.authname == 'anonymous': File "/usr/lib/python2.4/site-packages/trac/web/api.py", line 212, in __getattr__ value = self.callbacks[name](self) File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 157, in authenticate authname = authenticator.authenticate(req) File "/usr/lib/python2.4/site- packages/TracAccountManager-0.2.1dev_r4679-py2.4.egg/acct_mgr/web_ui.py", line 429, in wrap File "/usr/lib/python2.4/site- packages/TracAccountManager-0.2.1dev_r4679-py2.4.egg/acct_mgr/web_ui.py", line 439, in authenticate File "/usr/lib/python2.4/site- packages/TracAccountManager-0.2.1dev_r4679-py2.4.egg/acct_mgr/web_ui.py", line 466, in _remote_user File "/usr/lib/python2.4/site- packages/TracAccountManager-0.2.1dev_r4679-py2.4.egg/acct_mgr/api.py", line 140, in check_password File "build/bdist.linux-x86_64/egg/tautua/trac_plugins/security/ldapauth.py", line 35, in check_password File "/usr/lib64/python2.4/site-packages/ldap/ldapobject.py", line 175, in simple_bind_s msgid = self.simple_bind(who,cred,serverctrls,clientctrls) File "/usr/lib64/python2.4/site-packages/ldap/ldapobject.py", line 169, in simple_bind return self._ldap_call(self._l.simple_bind,who,cred,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls)) File "/usr/lib64/python2.4/site-packages/ldap/ldapobject.py", line 94, in _ldap_call result = func(*args,**kwargs) UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-13: ordinal not in range(128) }}} Typically the error goes away when I try again (sometimes multiple times). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2009> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

← 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 2017