Trac March 2017

trac@lists.einsteintoolkit.org

1 participants
100 discussions

[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] #2020: ExternalLibraries/OpenSSL does not build in parallel with the rest of Cactus
by Einstein Toolkit 13 Mar '17

13 Mar '17

#2020: ExternalLibraries/OpenSSL does not build in parallel with the rest of Cactus -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- The OpenSSL external library currently builds during the CST, unlike the other libraries, which build in parallel with the thorns. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2020> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2018: Assertion 'all(stride == other.stride)' failed
by Einstein Toolkit 13 Mar '17

13 Mar '17

#2018: Assertion 'all(stride == other.stride)' failed -----------------------------------+---------------------------------------- Reporter: allgwy001@… | Owner: eschnett Type: defect | Status: new Priority: unset | Milestone: Component: Carpet | Version: ET_2016_05 Keywords: | -----------------------------------+---------------------------------------- The attached parameter file equal-mass-bbh-wav.par aborts with: cactus_ET: /opt/exp_soft/EinsteinToolkit/Cactus/arrangements/Carpet/CarpetLib/src/bboxset2.hh:261: bboxset2::bboxset<T, D> bboxset2::bboxset<T, D>::binary_operator(const F&, const bboxset2::bboxset<T, D>&) const [with F = bboxset2::bboxset<T, D>::operator&(const bboxset2::bboxset<T, D>&) const [with T = int; int D = 3]::<lambda(const bboxset1&, const bboxset1&)>; T = int; int D = 3]: Assertion `all(stride == other.stride)' failed. The error only occurs when I try running the simulation on an HPC cluster. On my laptop, it works fine and I don't get this error. The optionlist and submission script for the cluster are attached. Commenting out the following lines in the parameter file results in a successful HPC run: {{{ Activethorns = "CarpetIOHDF5" IOHDF5::one_file_per_group = "yes" IOHDF5::out0D_every = 128 IOHDF5::out0D_vars = " WEYLSCAL4::Psi4r WEYLSCAL4::Psi4i PunctureTracker::pt_loc " }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2018> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #2016: McLachlan sets r->infty values of metric incorrectly
by Einstein Toolkit 08 Mar '17

08 Mar '17

#2016: McLachlan sets r->infty values of metric incorrectly -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: McLachlan | -----------------------------------+---------------------------------------- The (not usually used) "radiative" boundary condition uses the gt11_bound_limit etc to specify the limit of the fields at large radii. However right now the defaults for gt11, gt22, gt33 are all zero which is rather useless. I know that default values are not "sensible" values but rather "historical" values, but I question at which point in time it made sense to have the diagonal elements of the metric that we assume to become Minkowsky (since phi->0) would tend to zero. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2016> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #2017: McLachlan set the DIrichlet scalar for gt11 etc to zero
by Einstein Toolkit 07 Mar '17

07 Mar '17

#2017: McLachlan set the DIrichlet scalar for gt11 etc to zero -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: McLachlan | -----------------------------------+---------------------------------------- For the Scalar boundary condition (used currently for Llaama runs since NewRad until recently would not support curvilinear outer boundaries) ML uses the parameters gt11_scalar etc to determine the Dirichlet value. I know that default values are not "sensible" values but rather "historical" values, but I question at which point in time it made sense to have the diagonal elements of the metric that we assume to become Minkowsky (since phi->0) would be zero at large distances. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2017> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[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] #2014: simfactory.org is down
by Einstein Toolkit 06 Mar '17

06 Mar '17

#2014: simfactory.org is down -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Server Infrastructure | Version: development version Keywords: | -----------------------------------+---------------------------------------- http://simfactory.org does not work at the moment. It gives an index page with seemingly unrelated file. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2014> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac March 2017