[Paraview] [Non-DoD Source] Re: 5.0.1/Exodus Reader (UNCLASSIFIED)

[Angelini, Richard C (Rick) CIV USARMY RDECOM ARL (US)]

I used the same job launching scripts that I use for all of the previous
versions, including the broken attempts at 5.0.1 OSMesa builds  which were
able to connect and launch (and eventually fail).
________________________________
Rick Angelini
USArmy Research Laboratory
CISD/HPC Architectures Team
Phone:  410-278-6266




-----Original Message-----
From: Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
Date: Tuesday, June 7, 2016 at 11:30 AM
To: Rick Angelini <Richard.C.Angelini.CIV at mail.mil>
Cc: "Hennessey, Joseph G CTR USARMY RDECOM ARL (US)"
<joseph.g.hennessey2.ctr at mail.mil>, Simon Su <simon.m.su.CIV at mail.mil>,
ParaView <paraview at paraview.org>
Subject: Re: [Paraview] [Non-DoD Source] Re: 5.0.1/Exodus Reader
(UNCLASSIFIED)

> Utkarsh - I was able to get a clean build with this OSMesa patch - but it
> looks like the OSMesa pvserver is not compatible with the production
>5.0.1
> client??????

That's not the case. It should be compatible, so long are you're
building 5.0.1 on the server side too.

> **********************************************************************
> Connection failed during handshake. This can happen for the following
> reasons:
>  1. Connection dropped during the handshake.
>  2. vtkSocketCommunicator::GetVersion() returns different values on the
>     two connecting processes (Current value: 100).
>  3. ParaView handshake strings are different on the two connecting
>     processes (Current value: paraview.5.0.connect_id.9407).
> **********************************************************************

This message is printed on both client and server. See the value for
item 3. Do they match? Looks like you're using connection ids. Are
they being specified appropriately on both ends?