Trac February 2017

trac@lists.einsteintoolkit.org

2 participants
95 discussions

[Einstein Toolkit] #1801: Certificate for svn.cct.lsu.edu not trusted
by Einstein Toolkit 15 Feb '17

15 Feb '17

#1801: Certificate for svn.cct.lsu.edu not trusted --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- I just tried to check out the ET Hilbert release on my OSX laptop (OSX 10.10.4, subversion version 1.7.19) and get for the LSUThorns: --8<-- Could not checkout module LSUThorns/SummationByParts svn: E175002: Unable to connect to a repository at URL 'https://svn.cct.lsu.edu/repos/numrel/LSUThorns/SummationByParts/branches/ET…' svn: E175002: OPTIONS of 'https://svn.cct.lsu.edu/repos/numrel/LSUThorns/SummationByParts/branches/ET…': Server certificate verification failed: issuer is not trusted (https://svn.cct.lsu.edu) --8<-- https://www.sslshopper.com/ssl- checker.html#hostname=https://svn.cct.lsu.edu reports the certificate to be ok though (with the exception of it using SHA1 as a hash). Doing a manual svn checkout https://svn.cct.lsu.edu/repos/numrel/LSUThorns/QuasiLocalMeasures/branches/… asks me whether I would want to trust the certificate. 1. I thought the LSU certificates were trusted by common OS by default by now (and OSX is certainly common) 2. I thought we had special code in GetComponents to make it automatically not try and verify signatures because of this 3. this is really becoming a nuisance (if indeed caused by an uncommon certificate issuer and not by something odd on my laptop) :-) {{{ openssl ssl_client -connect svn.cct.lsu.edu:443 </dev/null >ssl.out }}} reports a self-signed certficate though this may well be the untrusted certificate. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1801> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 40

[Einstein Toolkit] #2006: Cannot run CST on Blue Waters
by Einstein Toolkit 08 Feb '17

08 Feb '17

#2006: Cannot run CST on Blue Waters ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- After upgrading to the Piraha parser, building on Blue Waters fails with this error: {{{ child error: tags at /mnt/a/u/sciteam/eschnett/Cvanilla/lib/sbin/ScheduleParser.pl line 281 main::parse_schedule_statement('Group=HASH(0x3ce23e0)', 'HASH(0xd1efd0)', 'SCALAR(0xd1c478)', 'SCALAR(0xd1c2f8)', 'SCALAR(0xd1c778)', 'ML_BSSN_CL') called at /mnt/a/u/sciteam/eschnett/Cvanilla/lib/sbin/ScheduleParser.pl line 334 main::parse_schedule_statement('Group=HASH(0x7921800)', 'HASH(0xd1efd0)', 'SCALAR(0xd1c478)', 'SCALAR(0xd1c2f8)', 'SCALAR(0xd1c778)', 'ML_BSSN_CL') called at /mnt/a/u/sciteam/eschnett/Cvanilla/lib/sbin/ScheduleParser.pl line 304 main::parse_schedule_statement('Group=HASH(0x3a41e58)', 'HASH(0xd1efd0)', 'SCALAR(0xd1c478)', 'SCALAR(0xd1c2f8)', 'SCALAR(0xd1c778)', 'ML_BSSN_CL') called at /mnt/a/u/sciteam/eschnett/Cvanilla/lib/sbin/ScheduleParser.pl line 382 main::parse_schedule_ccl('ML_BSSN_CL', 'Group=HASH(0x3a41e58)', 'STORAGE: ML_log_confac[timelevels]', 'STORAGE: ML_metric[timelevels]', 'STORAGE: ML_Gamma[timelevels]', 'STORAGE: ML_trace_curv[timelevels]', 'STORAGE: ML_curv[timelevels]', 'STORAGE: ML_Theta[timelevels]', 'STORAGE: ML_lapse[timelevels]', ...) called at /mnt/a/u/sciteam/eschnett/Cvanilla/lib/sbin/ScheduleParser.pl line 111 main::create_schedule_database('TestStrings', '/mnt/a/u/sciteam/eschnett/Cvanilla/arrangements/CactusTest/Te...', 'CartesianCoordinates', '/mnt/a/u/sciteam/eschnett/Cvanilla/arrangements/CTGamma/Carte...', 'WaveToyC', '/mnt/a/u/sciteam/eschnett/Cvanilla/arrangements/CactusWave/Wa...', 'ML_BSSN_DG3', '/mnt/a/u/sciteam/eschnett/Cvanilla/arrangements/McLachlan_dgt...', 'ML_Test_FD4', ...) called at /mnt/a/u/sciteam/eschnett/Cvanilla/lib/sbin/CST line 144 }}} Things work fine on other systems. A first guess would be some kind of Perl incompatibility? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2006> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1939: Cactus: Add CCTK_VINFO, CCTK_VERROR, CCTK_VWARN
by Einstein Toolkit 08 Feb '17

08 Feb '17

#1939: Cactus: Add CCTK_VINFO, CCTK_VERROR, CCTK_VWARN -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: unset | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- See <https://bitbucket.org/cactuscode/cactus/pull-requests/30/cactus-add- cctk_vinfo-cctk_verror/diff>. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1939> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #2005: MoL does not link
by Einstein Toolkit 08 Feb '17

08 Feb '17

#2005: MoL does not link ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: unset | Milestone: Component: Other | Version: development version Keywords: | ---------------------+------------------------------------------------------ At some point, the function CCTK_VError got changed to CCTK_VERROR in CactusNumerical. The flesh still seems to only have CCTK_VError. As a result, MoL creates an implicit function and refuses to link. The problem seems to start here: {{{ commit 4d9d67975edd313f210b7f1c7e31ff00cd7bdba6 Author: Erik Schnetter <schnetter(a)gmail.com> Date: Thu Feb 2 16:19:03 2017 -0500 Dissipation: Use CCTK_ERROR and friends to simplify code }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2005> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #2002: include jacobi cluster at UWM
by Einstein Toolkit 02 Feb '17

02 Feb '17

#2002: include jacobi cluster at UWM -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- Jacobi is a private cluster (10 nodes, 80 cores) at the physics department at UWM. It is currently being used to debug and run some simulations. Pull request is at https://bitbucket.org/simfactory/simfactory2/pull- requests/15/jacobi-uwm-add-new-machine-at-uwm/diff -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/2002> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2017