from:"Hennessey, Joseph G CTR USARMY RDECOM ARL \(US\)"

Re: [Paraview] [Non-DoD Source] Re: Error when trying to turn on Volume Rendering for large tetrahedral data in ParaView 5.4.1

2018-01-24 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

Utkarsh,

Thanks, turning on "Use Data Partitions" helped quite a bit.
The rendering is working for me now. I still suspect there
is a bug somewhere, but with "Use Data Partitions" on
I do not seem to be hitting it, and it is renders faster as well.

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center
Aberdeen Proving Ground, MD 21005
Email:  joseph.g.hennessey2@mail.mil


-Original Message-
From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com]
Sent: Wednesday, January 24, 2018 4:00 PM
To: Hennessey, Joseph G CTR USARMY RDECOM ARL (US) 
<joseph.g.hennessey2@mail.mil>
Cc: paraview@paraview.org
Subject: [Non-DoD Source] Re: [Paraview] Error when trying to turn on Volume 
Rendering for large tetrahedral data in ParaView 5.4.1

All active links contained in this email were disabled.  Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.






Joe,

Sorry, doesn't ring a bell. One thing to try is to turn of "Use Data 
Partitions" (see [1]) if your data is already partitioned between ranks such 
that we can build a sorting order.

Utkarsh


[1] Caution-https://blog.kitware.com/improved-parallel-rendering-in-paraview/

On Wed, Jan 24, 2018 at 3:16 PM, Hennessey, Joseph G CTR USARMY RDECOM ARL 
(US) <joseph.g.hennessey2@mail.mil> wrote:
> Hello,
>
> I am experiencing an error with volume rendering very large
> tetrahedral data with ParaView version  5.4.1.
>
> The data is loaded properly and the surface representation works, but
> when I change the representation to Volume, I get the standard dialog
> below to which I respond "Yes"
>
> 'This will change the representation type to "Volume".
> That may take a while, depending on your dataset. Are you sure?'
>
> I am tested this on two of the HPC supercomputer systems while
> connected to a remote server with multiple compute nodes,
> communicating over MPI. I have verified, I am not running out of
> memory  on the compute nodes or on the client but on large data, (over
> 40 million or so tetrahedrons) the compute nodes will crash without
> any error messages and the remote connection will drop, running out of
> memory would cause a similar failure, but as far as I can tell, that
> is not the case here.
>
> I wanted to see if anyone else had hit this problem, before I try
> building debug versions of the software and using a debugger on them,
> to trace the failure down more thoroughly.
>
> The data has 4 vectors and a scalar defined at each tetrahedron, and
> it renders fine with smaller subsets (less than 20 million or so
> tetrahedron). I would like to be able to scale up to a billion
> tetrahedrons eventually, so a 40 million limit is a problem.
>
> I suspect that there might be an issue in
> vtkOpenGLProjectedTetrahedraMapper.cxx
> where some buffer is maybe 32 bit instead of 64 bit, but I have not
> confirmed this.
>
> Has anyone already solved this problem yet?
>
> Thanks,
>
> Joe
>
> ~~~
> Joseph G. Hennessey Ph.D., SAIC
> Team SAIC
> Army Research Lab
> DOD Supercomputing Resource Center
> Email:  joseph.g.hennessey2@mail.mil
>
>
> ___
> Powered by Caution-www.kitware.com
>
> Visit other Kitware open-source projects at
> Caution-http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> Caution-http://paraview.org/Wiki/ParaView
>
> Search the list archives at:
> Caution-http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> Caution-https://paraview.org/mailman/listinfo/paraview
>



smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
https://paraview.org/mailman/listinfo/paraview

[Paraview] Error when trying to turn on Volume Rendering for large tetrahedral data in ParaView 5.4.1

2018-01-24 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

Hello,

I am experiencing an error with volume rendering very large
tetrahedral data with ParaView version  5.4.1.

The data is loaded properly and the surface representation works,
but when I change the representation to Volume, I get the standard 
dialog below to which I respond "Yes" 

'This will change the representation type to "Volume".
That may take a while, depending on your dataset. Are you sure?'

I am tested this on two of the HPC supercomputer systems
while connected to a remote server with multiple compute nodes,
communicating over MPI. I have verified, I am not running out of memory
 on the compute nodes or on the client but on large data,
(over 40 million or so tetrahedrons) the compute nodes will crash
without any error messages and the remote connection will drop,
running out of memory would cause a similar failure, but as far as
I can tell, that is not the case here.

I wanted to see if anyone else had hit this problem, before I try building 
debug versions of the software and using a debugger on them,
to trace the failure down more thoroughly.

The data has 4 vectors and a scalar defined at each tetrahedron,
and it renders fine with smaller subsets (less than 20 million
or so tetrahedron). I would like to be able to scale up to a billion
tetrahedrons eventually, so a 40 million limit is a problem.

I suspect that there might be an issue in 
vtkOpenGLProjectedTetrahedraMapper.cxx
where some buffer is maybe 32 bit instead of 64 bit,
but I have not confirmed this.

Has anyone already solved this problem yet?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center
Email:  joseph.g.hennessey2@mail.mil



smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
https://paraview.org/mailman/listinfo/paraview

[Paraview] Problems with mpi4py and SGI's mpt 2.14 and 2.15 versions of MPI

2017-09-07 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

Hello,

I have been running into problems with
mpi4py and SGI's mpt 2.14 and 2.15  versions of MPI
while compiling ParaView 5.3.0 on HPC systems.

mpi4py cannot find MPI_CONVERSION_FN_NULL
when compiling mpi4py.MPI.c

MPI_CONVERSION_FN_NULL was not used by the
version of mpi4py that came with ParaView 5.2.0
and when I swap the ParaView 5.2.0 version of mpi4py
in place of the ParaView 5.3.0 , 5.4.0 or 5.4.1 versions of mpi4py then
ParaView 5.3.0, 5.4.0 and 5.4.1 (with the 5.2.0 version of mpi4py)
compile just fine.

Has anyone found a better solution to this issue?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
Email:  joseph.g.hennessey2@mail.mil




smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Using 64 or more cores on a single node when running client/server

2017-09-07 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

Hello,

Has anyone managed to use ParaView 5.4.x with more than 64 core 
on a single node when running in client/server moder.

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
Email:  joseph.g.hennessey2@mail.mil




smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Monitoring the progress of a paraview filter

2017-07-24 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

Hello,

I am trying to monitor the progress of a paraview filter (contour)
on rather large data, so that I could  predict when it will finish.
Is there a recommended way to do this? I am running using
42 paraview servers and I cannot find an easy way of estimating
the filter percent of progress or expected completion time.

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center
Aberdeen Proving Ground, MD 21005




smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] [Non-DoD Source] Eye separation has been wrong since Immersive ParaView 5.2 - here's how to fix it

2017-07-18 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

Mark,

I have discussed the changes I made with my colleagues.
We do not want to harm your work with the Cave,
so we would be okay with backing out our changes.

We can scale our data to be of size greater than 1 
by using the transform data inside of ParaView
and our data will still work. My changes were only
necessary when working with data of size less than or 
a lot less than zero.

Please let me know what I can do to assist, my changes
are found in the ParaView 5.x versions, ParaView 4.4.0
still has your code in it without my changes for visualizing
small data in stereo with devices such as the zSpace.

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center
Email:  joseph.g.hennessey2@mail.mil


-Original Message-
From: Hennessey, Joseph G CTR USARMY RDECOM ARL (US) 
Sent: Monday, June 26, 2017 11:42 AM
To: 'Stock, Mark' <mark.st...@nrel.gov>; Gena Bug via ParaView
<paraview@paraview.org>
Subject: RE: [Non-DoD Source] [Paraview] Eye separation has been wrong since
Immersive ParaView 5.2 - here's how to fix it

Hello,

I am the one who requested the changes,
they were made to correct the stereo separation with working with zSpace
hardware
for data that was small in size (floating point values of coordinates, >> 1,
for example data that ranged from 0.000 to  0.001
I checked its use with data across 13 orders of magnitude from data of size
1,000,000 to data of scale 1/1,000,000.
I admit my fix is an approximation, but I am attempting to get a reasonable
agreement of size with  the non stereo operation

  double eyeSeparationCorrectionFactor = 10.0;
  double shiftDistance = this->EyeSeparation / (2.0 *
eyeSeparationCorrectionFactor);
  if(this->Distance < 1.0)
  {
shiftDistance *= this->Distance;
  }

  // Front (aka near)
  double F = E[2] - (this->Distance + this->Thickness);//E[2] -
1.0;//this->ClippingRange[1];
  // Back (aka far)
  double nearDistanceCorrectionFactor  = 1000.0;
  double B = E[2] - (this->Distance / nearDistanceCorrectionFactor);//E[2]
- .1;//this->ClippingRange[0];

Without these changes with small data the stereo separation is incorrect,
(too large)
also small data will not even show up in the render window as the clipping
planes will be wrong.

This change

"  if (cameraParallel == 0 && dot(normalVCVSOutput,vertexVC.xyz) > 0.0) {
normalVCVSOutput = -1.0*normalVCVSOutput; }"

I did not make and do not know its purpose.

I think we  need a solution that works for both caves and planar display
hardware,
and I think the underlying issue is that there is different render code
being used,
that is a subset of the full normal rendering solution, which is creating
these issues.
I think the correct solution is to remove  the separate render code and use
the primary
code for both client and server rendering of mono and stereo. I do not have
a cave to
test with, but I do not see why we can not find a solution that works for
everyone.

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center
Aberdeen Proving Ground, MD 21005

-Original Message-
From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Stock,
Mark
Sent: Friday, June 23, 2017 5:23 PM
To: Gena Bug via ParaView <paraview@paraview.org>
Subject: [Non-DoD Source] [Paraview] Eye separation has been wrong since
Immersive ParaView 5.2 - here's how to fix it

All active links contained in this email were disabled.  Please verify the
identity of the sender, and confirm the authenticity of all links contained
within the message prior to copying and pasting the address to a Web
browser.  






Hello,

If you're an Immersive ParaView user, you may have noticed that 5.x versions
don't work as well in your CAVE. Specifically, I've noticed the following
differences when compared with ParaView 4.4.0:

1) I can place an object in space properly but it seems to move 10x as fast
when I move my head.
2) If I move the object just a little farther away from its initial
position, it clips out (vanishes).
3) When I am viewing a triangle mesh, some triangles seem to flip normals
(and get dark) when I move the object around.

The first two problems are caused by a change in the VTK source code from
March 2016 which arbitrarily multiples the eye separation distance by 10,
and also tightens the near and far clipping planes. The third can be
corrected by adding a single comment (which will help CAVE and Immersive
users, but probably nobody else). Both fixes will require you to build
ParaView from source - which you're probably doing anyway. I can't comment
on how these changes will affect HMD VR users.


The first and second problems are caused by a single commit to the VTK
repository that began to appear in ParaView with version 5.2.0. The problem
code is

Re: [Paraview] [Non-DoD Source] Eye separation has been wrong since Immersive ParaView 5.2 - here's how to fix it

2017-06-26 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

Hello,

I am the one who requested the changes,
they were made to correct the stereo separation with working with zSpace
hardware
for data that was small in size (floating point values of coordinates, >> 1,
for example data that ranged from 0.000 to  0.001
I checked its use with data across 13 orders of magnitude from data of size
1,000,000 to data of scale 1/1,000,000.
I admit my fix is an approximation, but I am attempting to get a reasonable
agreement of size with  the non stereo operation

  double eyeSeparationCorrectionFactor = 10.0;
  double shiftDistance = this->EyeSeparation / (2.0 *
eyeSeparationCorrectionFactor);
  if(this->Distance < 1.0)
  {
shiftDistance *= this->Distance;
  }

  // Front (aka near)
  double F = E[2] - (this->Distance + this->Thickness);//E[2] -
1.0;//this->ClippingRange[1];
  // Back (aka far)
  double nearDistanceCorrectionFactor  = 1000.0;
  double B = E[2] - (this->Distance / nearDistanceCorrectionFactor);//E[2]
- .1;//this->ClippingRange[0];

Without these changes with small data the stereo separation is incorrect,
(too large)
also small data will not even show up in the render window as the clipping
planes will be wrong.

This change

"  if (cameraParallel == 0 && dot(normalVCVSOutput,vertexVC.xyz) > 0.0) {
normalVCVSOutput = -1.0*normalVCVSOutput; }"

I did not make and do not know its purpose.

I think we  need a solution that works for both caves and planar display
hardware,
and I think the underlying issue is that there is different render code
being used,
that is a subset of the full normal rendering solution, which is creating
these issues.
I think the correct solution is to remove  the separate render code and use
the primary
code for both client and server rendering of mono and stereo. I do not have
a cave to
test with, but I do not see why we can not find a solution that works for
everyone.

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center
Aberdeen Proving Ground, MD 21005

-Original Message-
From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Stock,
Mark
Sent: Friday, June 23, 2017 5:23 PM
To: Gena Bug via ParaView 
Subject: [Non-DoD Source] [Paraview] Eye separation has been wrong since
Immersive ParaView 5.2 - here's how to fix it

All active links contained in this email were disabled.  Please verify the
identity of the sender, and confirm the authenticity of all links contained
within the message prior to copying and pasting the address to a Web
browser.  






Hello,

If you're an Immersive ParaView user, you may have noticed that 5.x versions
don't work as well in your CAVE. Specifically, I've noticed the following
differences when compared with ParaView 4.4.0:

1) I can place an object in space properly but it seems to move 10x as fast
when I move my head.
2) If I move the object just a little farther away from its initial
position, it clips out (vanishes).
3) When I am viewing a triangle mesh, some triangles seem to flip normals
(and get dark) when I move the object around.

The first two problems are caused by a change in the VTK source code from
March 2016 which arbitrarily multiples the eye separation distance by 10,
and also tightens the near and far clipping planes. The third can be
corrected by adding a single comment (which will help CAVE and Immersive
users, but probably nobody else). Both fixes will require you to build
ParaView from source - which you're probably doing anyway. I can't comment
on how these changes will affect HMD VR users.


The first and second problems are caused by a single commit to the VTK
repository that began to appear in ParaView with version 5.2.0. The problem
code is in VTK/Rendering/Core/vtkCamera.cxx starting at line 452 in versions
5.3 and 5.4. This problem can be fixed by replacing

  double eyeSeparationCorrectionFactor = 10.0;
  double shiftDistance = this->EyeSeparation / (2.0 *
eyeSeparationCorrectionFactor);
  if(this->Distance < 1.0)
  {
shiftDistance *= this->Distance;
  }



with simply

  double shiftDistance = this->EyeSeparation;


The second problem (clipping planes) is just a few lines down. I fixed it by
replacing

  // Front (aka near)
  double F = E[2] - (this->Distance + this->Thickness);//E[2] -
1.0;//this->ClippingRange[1];
  // Back (aka far)
  double nearDistanceCorrectionFactor  = 1000.0;
  double B = E[2] - (this->Distance / nearDistanceCorrectionFactor);//E[2]
- .1;//this->ClippingRange[0];



with

  // Front (aka near)
  double F = E[2] - 1.0;//this->ClippingRange[1];
  // Back (aka far)
  double B = E[2] - .1;//this->ClippingRange[0];



The third problem can be fixed by commenting out this line in
VTK/Rendering/OpenGL2/vtkOpenGLPolyDataMapper.cxx (around line 1198 in 5.1,
1416 in 5.2 to 5.4):

"  if (cameraParallel == 0 && dot(normalVCVSOutput,vertexVC.xyz) > 0.0) {
normalVCVSOutput = -1.0*normalVCVSOutput; }"

Re: [Paraview] [Non-DoD Source] Re: ResetCamera throwing bad_alloc

2017-05-11 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

Utkarsh,

It does not crash when it is commented out.

It is trying to read an ExodusII file

# create a new 'ExodusIIReader
test_data = ExodusIIReader(FileName=path)

# show data in view
test_Display = Show(test_data, renderView1)

but does not crash until ResetCamera is called.

So, I guess the problem is with the ExodusIIReader,
and just doesn't manifest until the ResetCamera,
triggers an update to the pipeline. I know the data
is okay as I can read it with another version of ParaView
5.3.0 on the same system.

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center
Aberdeen Proving Ground, MD 21005
Voice:  410-278-3619
Fax:410-278-8799
Email:  joseph.g.hennessey2@mail.mil


-Original Message-
From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com]
Sent: Thursday, May 11, 2017 3:44 PM
To: Hennessey, Joseph G CTR USARMY RDECOM ARL (US) 
<joseph.g.hennessey2@mail.mil>
Cc: paraview@paraview.org
Subject: [Non-DoD Source] Re: [Paraview] ResetCamera throwing bad_alloc

All active links contained in this email were disabled. Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.





  Joe,

Do you see the error if you comment out all the "#Show stuff in
renderView1" part?

Utkarsh

On Thu, May 11, 2017 at 3:13 PM, Hennessey, Joseph G CTR USARMY RDECOM ARL 
(US) <joseph.g.hennessey2@mail.mil < 
Caution-mailto:joseph.g.hennessey2@mail.mil > > wrote:


Hello,

I am getting an error on running a python script with pvpython and 
ParaView
5.3.0 on linux.

# get active view
renderView1 = GetActiveViewOrCreate('RenderView')

# uncomment following to set a specific view size
renderView1.ViewSize = [1200, 600]

# Properties modified on renderView1
renderView1.Background = [1.0, 1.0, 1.0]

#Show stuff in renderView1
.
.
.

# reset view to fit data
renderView1.ResetCamera()

ResetCamera() is throwing an error

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Has anyone seen this particular error before with just calling 
ResetCamera()
on a renderView?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center


___
Powered by Caution-www.kitware.com < Caution-http://www.kitware.com >

Visit other Kitware open-source projects at 
Caution-http://www.kitware.com/opensource/opensource.html < 
Caution-http://www.kitware.com/opensource/opensource.html >

Please keep messages on-topic and check the ParaView Wiki at: 
Caution-http://paraview.org/Wiki/ParaView < 
Caution-http://paraview.org/Wiki/ParaView >

Search the list archives at: 
Caution-http://markmail.org/search/?q=ParaView < 
Caution-http://markmail.org/search/?q=ParaView >

Follow this link to subscribe/unsubscribe:
Caution-http://public.kitware.com/mailman/listinfo/paraview < 
Caution-http://public.kitware.com/mailman/listinfo/paraview >






smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] ResetCamera throwing bad_alloc

2017-05-11 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

Hello,

I am getting an error on running a python script with pvpython and ParaView
5.3.0 on linux.

# get active view
renderView1 = GetActiveViewOrCreate('RenderView')

# uncomment following to set a specific view size
renderView1.ViewSize = [1200, 600]

# Properties modified on renderView1
renderView1.Background = [1.0, 1.0, 1.0]

#Show stuff in renderView1
.
.
.

# reset view to fit data
renderView1.ResetCamera()

ResetCamera() is throwing an error

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Has anyone seen this particular error before with just calling ResetCamera()
on a renderView?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center



smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] [Non-DoD Source] Re: Volume rendering with OSPRay Renderer not working with ParaView 5.3.0-RC3 (UNCLASSIFIED)

2017-03-08 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

David,

I can not send my data set,
But I am experiencing similar problems
With one of visit's sample data sets.

curv3d.silo (A multi-block containing a structured curvilinear grid)

I clip it and then render it with the default volume renderer

and it works, but then when I turn on OSPRay it fails. (crashes)

Strangely enough it also fails (does not renderer visibly) in the default 
renderer when I do not first clip it.


My data which is failing is instead a large unstructured grid with cell/Point 
arrays

They visualize ok with the default Volume renderer but are invisible with the

OSPRay volume renderer. I have not yet found a sample I can share with you 
that has the same

behavior. I will see if I can get you one though. Do you know of any similar 
publicly available samples?


I have also tried the vtk analyze sample data

S01_epi_r01_001.img
S01_epi_r01_001.hdr

Which are image (uniform rectangular grids)

S01_epi_r01_001 renderers correctly with both the default volume renderer

and the OSPRay one.

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center


-Original Message-
From: David E DeMarle [mailto:dave.dema...@kitware.com]
Sent: Wednesday, March 08, 2017 3:02 PM
To: Hennessey, Joseph G CTR USARMY RDECOM ARL (US) 
<joseph.g.hennessey2@mail.mil>
Cc: paraview@paraview.org
Subject: [Non-DoD Source] Re: [Paraview] Volume rendering with OSPRay Renderer 
not working with ParaView 5.3.0-RC3 (UNCLASSIFIED)

All active links contained in this email were disabled. Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.






Wavelet->Volume Works for me on Linux, builtin mode.


Can you provide more details?




David E DeMarle
Kitware, Inc.
R Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Wed, Mar 8, 2017 at 2:51 PM, Hennessey, Joseph G CTR USARMY RDECOM ARL (US) 
<joseph.g.hennessey2@mail.mil < 
Caution-mailto:joseph.g.hennessey2@mail.mil > > wrote:


CLASSIFICATION: UNCLASSIFIED

Hello,

I am finding that the volume rendering is not working with

OSPRay Renderer not working with ParaView 5.3.0-RC3.

The volume render sample that I am testing looks fine

when rendered with the default renderer, but when I switch to the

OSPRay volume renderer, then nothing is shown.

Has anyone managed to volume render data, using

the OSPRay renderer with ParaView 5.3.0-RC3?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center



CLASSIFICATION: UNCLASSIFIED

___
Powered by Caution-www.kitware.com < Caution-http://www.kitware.com >

Visit other Kitware open-source projects at 
Caution-http://www.kitware.com/opensource/opensource.html < 
Caution-http://www.kitware.com/opensource/opensource.html >

Please keep messages on-topic and check the ParaView Wiki at: 
Caution-http://paraview.org/Wiki/ParaView < 
Caution-http://paraview.org/Wiki/ParaView >

Search the list archives at: 
Caution-http://markmail.org/search/?q=ParaView < 
Caution-http://markmail.org/search/?q=ParaView >

Follow this link to subscribe/unsubscribe:
Caution-http://public.kitware.com/mailman/listinfo/paraview < 
Caution-http://public.kitware.com/mailman/listinfo/paraview >





CLASSIFICATION: UNCLASSIFIED


smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Volume rendering with OSPRay Renderer not working with ParaView 5.3.0-RC3 (UNCLASSIFIED)

2017-03-08 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Hello,

I am finding that the volume rendering is not working with

OSPRay Renderer not working with ParaView 5.3.0-RC3.

The volume render sample that I am testing looks fine

when rendered with the default renderer, but when I switch to the 

OSPRay volume renderer, then nothing is shown.

Has anyone managed to volume render data, using 

the OSPRay renderer with ParaView 5.3.0-RC3?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center



CLASSIFICATION: UNCLASSIFIED


smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] [Non-DoD Source] XDMF and nested Grid Collections (UNCLASSIFIED)

2017-02-14 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Alessandro,

This looks like a useful feature to add to the reader, and we will put in our 
list of things to work on. But, I can not immediately implement this as we 
have a number of high priority updates such as c++11 support, and an updated 
base Xdmf library currently pending.

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center

-Original Message-
From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Alessandro 
De Maio
Sent: Tuesday, February 14, 2017 9:21 AM
To: paraview@paraview.org
Subject: [Non-DoD Source] [Paraview] XDMF and nested Grid Collections

All active links contained in this email were disabled. Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.






Hi,

I'm trying to export from a parallel MPI CFD code a set of results using 
xdmf/hdf5 format in order to be read in Paraview.
The computational domain is divided into several parts (unstructured 
polyhedral grid) and the idea is to write a xdmf  with a further subdivision 
to be read in parallel by mpi paraview.
So it's a nested subdivision in which the external level is based on different 
parts of the domain (that should be extractable in Paraview after the reading) 
and each part is divided into a number of chunks equal to the number of 
processes of the parallel Paraview execution. With such a subdivision, reading 
this file with a parallel Paraview execution, each Paraview process loads a 
fraction of each part and, if all the chunks of each part have the same 
dimension, all the Paraview processes are balanced.

In the following there is an example for two parts and two Paraview processes.

I've used nested Grid Collections of type Spatial and it seems that everything 
is ok but the problem is that in Paraview the names of the first level 
collection items  is lost (in the following example  tet_cell1 and tet_cell2) 
and these items are called "Block 0" and "Block 1". The leaf elements of the 
tree instead (Grid_01, Grid_02, ...) mantain their correct name.

I've tried also to change the GridType of the external level from Collection 
to Tree (that should be supported in the xdmf data format) but in this case 
the item in Paraview is empty (0 cells and 0 nodes).

Is there any error in my procedure? It's the first time that I use xdmf.

Thank you in advance for your help.

Alessandro




http://www.w3.org/2001/XInclude < 
Caution-http://www.w3.org/2001/XInclude > " Version="3.3">
  

  

  
../positive/xdmf/tet_cell1.h5:Data0
  
  
../positive/xdmf/tet_cell1.h5:Data1
  
  
../positive/xdmf/tet_cell1.h5:Data2
  



  
../negative/xdmf/tet_cell1.h5:Data0
  
  
../negative/xdmf/tet_cell1.h5:Data1
  
  
../negative/xdmf/tet_cell1.h5:Data2
  

  

  


  
../positive/xdmf/tet_cell2.h5:Data0
  
  
../positive/xdmf/tet_cell2.h5:Data1
  
  
../positive/xdmf/tet_cell2.h5:Data2
  



  
../negative/xdmf/tet_cell2.h5:Data0
  
  
../negative/xdmf/tet_cell2.h5:Data1
  
  
../negative/xdmf/tet_cell2.h5:Data2
  


  


  



CLASSIFICATION: UNCLASSIFIED


smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] ParaView 5.1.2 is not recording changes to the LUT position when tracing is one with all options (UNCLASSIFIED)

2017-01-13 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Hello,

ParaView 5.1.2 is not recording changes to the LUT Scalar Bar position and
size when tracing is one with all options.

And that even when I manually set the positions of the LUT in the script
file run by pvpython,

Paraview will seem to pull the settings for the lut from the last postion
that the lut was used in the GUI

and not like I like desire from the script values.

Has anyone else experienced this?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center
Aberdeen Proving Ground, MD 21005
Voice:  410-278-3619
Fax:410-278-8799
Email:  joseph.g.hennessey2@mail.mil



CLASSIFICATION: UNCLASSIFIED


smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] [Non-DoD Source] Re: Problem with WriteAnimation in a python file silently failing under pvbatch but working when called with pvpython (UNCLASSIFIED)

2017-01-10 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Andy,

I have tried the various options --mpi , -dr and I also tried --mpi -dr and it 
had no effect.

What I did find though was that the compute nodes are running an osmesa build 
of paraview.
and I had been running in a hardware accelerated GL build of paraview when I 
ran pvpython.

When I forced it to use the pvpython version from the osmesa build (which is 
the one the batch file uses.)
I got this error.

GL_Version: ERROR: In 
/p/home/joeh/PV/Build_5.1.2_osmesa/paraview/src/paraview/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx,
 
line 597
vtkOSOpenGLRenderWindow (0x2fcc250): GLEW could not be initialized.

When it hit the

WriteAnimation('full_image_path.png', Magnification=2, FrameRate=15.0, 
Compression=True)

line. This error message did not occur when running the GL build of pvpython 
from ParaView 5.1.2.

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center


-Original Message-
From: Andy Bauer [mailto:andy.ba...@kitware.com]
Sent: Tuesday, January 10, 2017 9:52 AM
To: Hennessey, Joseph G CTR USARMY RDECOM ARL (US) 
<joseph.g.hennessey2@mail.mil>
Cc: ParaView <paraview@paraview.org>
Subject: [Non-DoD Source] Re: [Paraview] Problem with WriteAnimation in a 
python file silently failing under pvbatch but working when called with 
pvpython (UNCLASSIFIED)

All active links contained in this email were disabled. Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.






Hi Joe,


I haven't seen this issue or heard anyone else with something like this. Are 
you running pvbatch in serial? If you share a python script which demonstrates 
the issue it may be an easy issue to track down.

There are some slight differences between pvpython and pvbatch. My guess would 
be that it's due to pvbatch initializing mpi while pvpython does not by 
default. You could try running pvpython with the --mpi option to see if having 
it initialize pvpython gives you the same behavior. Also you could try -dr to 
disable the registry (i.e. config settings) to see if that makes a difference.


Cheers,

Andy


On Tue, Jan 10, 2017 at 9:19 AM, Hennessey, Joseph G CTR USARMY RDECOM ARL 
(US) <joseph.g.hennessey2@mail.mil < 
Caution-mailto:joseph.g.hennessey2@mail.mil > > wrote:


CLASSIFICATION: UNCLASSIFIED

Hello,

I have found that pvbatch is silently failing in a python file when
WriteAnimation
is called and used with ParaView 5.2.0 under linux.

But pvpython will execute the same command from the same python file
correctly.

The call where it is failing is below

WriteAnimation('full_image_path.png', Magnification=2, FrameRate=15.0,
Compression=True)

and it is not giving any error messages, it just never returns when 
called
by pvbatch

Has anyone else experienced this, or have an idea of how to correct it?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center


CLASSIFICATION: UNCLASSIFIED

___
Powered by Caution-www.kitware.com < Caution-http://www.kitware.com >

Visit other Kitware open-source projects at 
Caution-http://www.kitware.com/opensource/opensource.html < 
Caution-http://www.kitware.com/opensource/opensource.html >

Please keep messages on-topic and check the ParaView Wiki at: 
Caution-http://paraview.org/Wiki/ParaView < 
Caution-http://paraview.org/Wiki/ParaView >

Search the list archives at: 
Caution-http://markmail.org/search/?q=ParaView < 
Caution-http://markmail.org/search/?q=ParaView >

Follow this link to subscribe/unsubscribe:
Caution-http://public.kitware.com/mailman/listinfo/paraview < 
Caution-http://public.kitware.com/mailman/listinfo/paraview >





CLASSIFICATION: UNCLASSIFIED


smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Problem with WriteAnimation in a python file silently failing under pvbatch but working when called with pvpython (UNCLASSIFIED)

2017-01-10 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Hello,

I have found that pvbatch is silently failing in a python file when
WriteAnimation
is called and used with ParaView 5.2.0 under linux.

But pvpython will execute the same command from the same python file
correctly.

The call where it is failing is below

WriteAnimation('full_image_path.png', Magnification=2, FrameRate=15.0,
Compression=True)

and it is not giving any error messages, it just never returns when called
by pvbatch

Has anyone else experienced this, or have an idea of how to correct it?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., SAIC
Team SAIC
Army Research Lab
DOD Supercomputing Resource Center


CLASSIFICATION: UNCLASSIFIED


smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Need paraview data examples with human readable names vs md5 sums (UNCLASSIFIED)

2016-11-09 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Hello,

Recent versions of ParaViewData (5.0.0 and above) have their file names as
md5 sums.
While version 4.4.0 of ParaViewData and earlier used human readable names.
Is there still a version of ParaViewData (5.0.0 and above) that has human
readable names?

Thank,

Joe

~~~
Joseph G. Hennessey Ph.D., Leidos
Army Research Lab
DOD Supercomputing Resource Center
Aberdeen Proving Ground, MD 21005
Email:  joseph.g.hennessey2@mail.mil



CLASSIFICATION: UNCLASSIFIED


smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Possible error in loading multiple PLY files at once. (UNCLASSIFIED)

2016-10-14 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Hello,

I am seeing an error when attempting to load PLY files formed
from saving parallel .vtm surface files that have been saved in 
the PLY format.  The file name convention for loading them at once
seems to break down and only load random subsections of the .vtm
files. Has anyone else seen this behavior before?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., Leidos
Army Research Lab
DOD Supercomputing Resource Center
Aberdeen Proving Ground, MD 21005
Email:  joseph.g.hennessey2@mail.mil



CLASSIFICATION: UNCLASSIFIED


smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] [Non-DoD Source] Re: 5.1.2/OpenGL2 issue (UNCLASSIFIED)

2016-08-24 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

nGL2\vtkOpenGLRenderWindow.cxx

void vtkOpenGLRenderWindow::OpenGLInitState()
{
  glDepthFunc( GL_LEQUAL );
  glEnable( GL_DEPTH_TEST );

  // initialize blending for transparency
  glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
  GL_ONE,GL_ONE_MINUS_SRC_ALPHA);
  glEnable(GL_BLEND);

it seems that glBlendFuncSeparate is a function that is being defined as NULL 
for some reason.

This is occurring in 5.1.0 and 5.1.2 but it is defined properly and works 
correctly in 5.0.1 for some reason.

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., Leidos
Army Research Lab
DOD Supercomputing Resource Center
Aberdeen Proving Ground, MD 21005
Voice:  410-278-3619
Fax:410-278-8799
Email:  joseph.g.hennessey2@mail.mil


-Original Message-
From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com] 
Sent: Wednesday, August 24, 2016 10:24 AM
To: Dave Pratt <david.pratt@dren.mil>
Cc: Angelini, Richard C (Rick) CIV USARMY RDECOM ARL (US) 
<richard.c.angelini@mail.mil>; ParaView <paraview@paraview.org>; Hennessey, 
Joseph G CTR USARMY RDECOM ARL (US) <joseph.g.hennessey2@mail.mil>
Subject: Re: [Non-DoD Source] Re: [Paraview] 5.1.2/OpenGL2 issue

All active links contained in this email were disabled.  Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.  






Dave,

Is it possible to do a debug build and see which call is failing?

Utkarsh

On Wed, Aug 24, 2016 at 10:20 AM, Dave Pratt <david.pratt@dren.mil> wrote:
>
> Utkarsh,
>We are running VirtualGL 2.3.3 and TurboVNC 1.2.1 on all systems and
> Paraview is executed under a vglrun environment.   Paraview 5.0.1 has been
> running on this system for quite some time.  Version 5.1.2  throws a 
> segfault at
>
> [VGL] WARNING: The OpenGL rendering context obtained on X display
> [VGL]:0.0 is indirect, which may cause performance to suffer.
> [VGL]If :0.0 is a local X display, then the framebuffer device
> [VGL]permissions may be set incorrectly.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x in ?? ()
> (gdb) where
> #0  0x in ?? ()
> #1  0x2fd4db69 in vtkOpenGLRenderWindow::OpenGLInitState() ()
>from
> /p/app/DAAC/paraview/5.1.2/lib/paraview-5.1/libvtkRenderingOpenGL2-pv5
> .1.so.1
> #2  0x2fd4e86c in
> vtkOpenGLRenderWindow::CreateHardwareOffScreenWindow(int, int) ()
>from
> /p/app/DAAC/paraview/5.1.2/lib/paraview-5.1/libvtkRenderingOpenGL2-pv5
> .1.so.1
> #3  0x2fdf1515 in 
> vtkXOpenGLRenderWindow::CreateOffScreenWindow(int,
> int) ()
>from
> /p/app/DAAC/paraview/5.1.2/lib/paraview-5.1/libvtkRenderingOpenGL2-pv5
> .1.so.1
> #4  0x2fd4d0e5 in vtkOpenGLRenderWindow::SupportsOpenGL() ()
>from
> /p/app/DAAC/paraview/5.1.2/lib/paraview-5.1/libvtkRenderingOpenGL2-pv5
> .1.so.1
> #5  0x2aaab938b3b8 in 
> vtkPVDisplayInformation::SupportsOpenGLLocally()
> ()
>from
> /p/app/DAAC/paraview/5.1.2/lib/paraview-5.1/libvtkPVClientServerCoreRe
> ndering-pv5.1.so.1
> #6  0x2aaab938b3f4 in
> vtkPVDisplayInformation::CopyFromObject(vtkObject*) ()
>from
> /p/app/DAAC/paraview/5.1.2/lib/paraview-5.1/libvtkPVClientServerCoreRe
> ndering-pv5.1.so.1
> #7  0x2df6723b in
> vtkPVSessionCore::GatherInformationInternal(vtkPVInformation*, 
> unsigned int)
> ()
>from
> /p/app/DAAC/paraview/5.1.2/lib/paraview-5.1/libvtkPVServerImplementati
> onCore-pv5.1.so.1
> ...
>
>
>
>
>
> On 08/24/16 08:56 AM, Utkarsh Ayachit wrote:
>
> No, that's not it. Hopefully someone with more knowledge on this than 
> me can chime in at some point. I'm told that VirtualGL < 2.3.1 did not 
> forward the glXCreateContextARB calls we need for creating OpenGL 3.2 
> context needed by ParaView (OpenGL2 backend).
>
> To update my know how about it in the mean time, I read up a bit on 
> TightVNC and VGL [1,2]. So, is your setup intended to use VirtualGL?
> If so, shouldn't you be running `vglrun paraview`? I believe that's 
> the [VGL] warning messages are all about, aren't they?
>
> Utkarsh
>
> [1] Caution-http://www.virtualgl.org/vgldoc/2_1_1/#hd009
> [2]
> Caution-https://hpc.nrel.gov/users/software/visualization-analytics/vi
> rtualgl-turbovnc
>
> On Wed, Aug 24, 2016 at 9:36 AM, Angelini, Richard C (Rick) CIV USARMY 
> RDECOM ARL (US) <richard.c.angelini@mail.mil> wrote:
>
> Yes - this is an OpenGL2 build.
>
> Is this the information on TurboVNC that you’re looking for?
>
> server glx vendor string: VirtualGL
> server glx version string: 1.4
>
> 
>

[Paraview] Issues with ParaView 5.1.0 and VGL (UNCLASSIFIED)

2016-06-28 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Hello,

I am experiencing an error when running ParaView 5.1.0 using VGL

When starting ParaView 5.1.0 I get the following warnings

[VGL] WARNING: The OpenGL rendering context obtained on X display
[VGL]:0.0 is indirect, which may cause performance to suffer.
[VGL]If :0.0 is a local X display, then the framebuffer device
[VGL]permissions may be set incorrectly.

And then ParaView 5.1.0 seg faults.

ParaView 5.0.1 when run under VGL does not produce the same
warnings and works just fine.

Is their some new requirement for VGL support that ParaView 5.1.0 has
over version 5.0.1?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., Lockheed Martin
Army Research Lab
DOD Supercomputing Resource Center
Email:  joseph.g.hennessey2@mail.mil



CLASSIFICATION: UNCLASSIFIED


smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] [Non-DoD Source] ANN: ParaView 5.1.0 available for download (UNCLASSIFIED)

2016-06-24 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Rick,

In the superbuild source directory

The file

CMake/DetermineParaViewVersion.cmake line 10

Change

set (hardcoded_paraview_version "5.0.1")

to

set (hardcoded_paraview_version "5.1.0")

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., Lockheed Martin
Army Research Lab
DOD Supercomputing Resource Center
120 Aberdeen Blvd.
Aberdeen Proving Ground, MD 21005
Voice:  410-278-3619
Fax:410-278-8799
Email:  joseph.g.hennessey2@mail.mil


-Original Message-
From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Angelini, 
Richard C (Rick) CIV USARMY RDECOM ARL (US)
Sent: Friday, June 24, 2016 9:48 AM
To: Utkarsh Ayachit ; ParaView 
; ParaView Developers 
Subject: Re: [Paraview] [Non-DoD Source] ANN: ParaView 5.1.0 available for 
download

All active links contained in this email were disabled.  Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.  






Utkarsh - I’ve having trouble getting a build using 5.1 ….   I’m running a
“make install” and it seems to be looking for install/lib/paraview-5.1 but what 
actually exists in the build directory is install/lib/paraview-5.0  … not sure 
if my superbuild is hosed or if there’s something wrong deep in one of the 
configuration files.



-- Installing: 
/home/angel/PV/5.1.0/Build/install/share/applications/paraview.desktop
-- Up-to-date: 
/home/angel/PV/5.1.0/Build/install/share/icons/hicolor/22x22/apps/paraview.
png
-- Up-to-date: 
/home/angel/PV/5.1.0/Build/install/share/icons/hicolor/32x32/apps/paraview.
png
-- Up-to-date: 
/home/angel/PV/5.1.0/Build/install/share/icons/hicolor/96x96/apps/paraview.
png
-- Up-to-date: 
/home/angel/PV/5.1.0/Build/install/share/appdata/paraview.appdata.xml
[100%] Completed 'paraview'
[100%] Built target paraview
Install the project...
-- Install configuration: "Release"
CMake Error at cmake_install.cmake:36 (file):
  file INSTALL cannot find
  "/home/angel/PV/5.1.0/Build/install/lib/paraview-5.1".



Rick Angelini
USArmy Research Laboratory
CISD/HPC Architectures Team
Phone:  410-278-6266




-Original Message-
From: ParaView  on behalf of Utkarsh Ayachit 

Date: Tuesday, June 21, 2016 at 12:04 PM
To: ParaView , ParaView Developers 

Subject: [Non-DoD Source] [Paraview] ANN: ParaView 5.1.0 available for download

All active links contained in this email were disabled.  Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.  






Folks,

ParaView 5.1.0 is now available for download [1]. Please refer to the release 
notes on the Kitware blog [2]. As always, we look forward to your feedback [3].

Also stay tuned to the Kitware Blog [4] for upcoming features and enhancements 
to ParaView, ParaView Catalyst, ParaViewWeb and much more!

- ParaView Team

[1] Caution-Caution-http://www.paraview.org/download/
[2] Caution-Caution-https://blog.kitware.com/paraview-5-1-0-release-notes/
[3] Caution-Caution-http://paraview.uservoice.com
[4] Caution-Caution-https://blog.kitware.com/tag/ParaView/
___
Powered by Caution-Caution-www.kitware.com

Visit other Kitware open-source projects at 
Caution-Caution-http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at:
Caution-Caution-http://paraview.org/Wiki/ParaView

Search the list archives at: 
Caution-Caution-http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
Caution-Caution-http://public.kitware.com/mailman/listinfo/paraview

___
Powered by Caution-www.kitware.com

Visit other Kitware open-source projects at 
Caution-http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
Caution-http://paraview.org/Wiki/ParaView

Search the list archives at: Caution-http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
Caution-http://public.kitware.com/mailman/listinfo/paraview


CLASSIFICATION: UNCLASSIFIED


smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:

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

2016-06-06 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Utkarsh,

I have rebuilt osmesa using mesa 11.2.2 but
it ParaView rebuilt with the new version is giving
me the same error as before, complaining that the
GL version 2.1 with gpu_shader4 extension is not
Supported.

I think I know  why  this is occurring and I wondered if you
could confirm this for me.

I configured mesa with these parameters

./configure \
--disable-xvmc \
--disable-glx \
--disable-dri \
--with-dri-drivers= \
--with-gallium-drivers=swrast \
--enable-texture-float \
--disable-egl \
--with-egl-platforms= \
--enable-gallium-osmesa \
--enable-gallium-llvm=yes \
--prefix=

but, I did not have a version of llvm available
and the configure script then set

Llvm = no

>From my reading of this webpage

http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D

It seems that without gallium-llvm,
the version of OpenGL built reverts to an older version,
which I believe is why I am still getting the error.

Would you agree with this?

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., Lockheed Martin
Army Research Lab
DOD Supercomputing Resource Center


-Original Message-
From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com]
Sent: Thursday, June 02, 2016 4:19 PM
To: Hennessey, Joseph G CTR USARMY RDECOM ARL (US) 
<joseph.g.hennessey2@mail.mil>
Cc: Angelini, Richard C (Rick) CIV USARMY RDECOM ARL (US) 
<richard.c.angelini@mail.mil>; Su, Simon M CIV USARMY RDECOM ARL (US) 
<simon.m.su@mail.mil>; ParaView <paraview@paraview.org>
Subject: Re: [Paraview] [Non-DoD Source] Re: 5.0.1/Exodus Reader 
(UNCLASSIFIED)

All active links contained in this email were disabled.  Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.






> And I have tried replacing the library
> lib/paraview-5.0/libOSMesa.so.7
> with both libOSMesa.so from 11.1.2 and 11.2.2 and they are both still
> giving the same error

Simply swapping the libraries won't work. Mesa 11.2 [1] added new API
OSMesaCreateContextAttribs() which is needed to create correct OpenGL context. 
The API is used at compile time if appropriate osmesa.h is being used.

You can try to update Projects/unix/osmesa.cmake in the superbuild source to 
use the configure arguments you used, and also change versions.cmake in the 
same repo to point to change the osmesa source tar ball to be 11.2. Now the 
superbuid will build 11.2 instead and it should then have the new API 
available.

[1] Caution-http://www.mesa3d.org/relnotes/11.2.0.html


CLASSIFICATION: UNCLASSIFIED


smime.p7s
Description: S/MIME cryptographic signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

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

2016-06-02 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Utkarsh,

I was wondering how to hack the superbuild for ParaView to use my newly built 
versions of osmesa

Swapping out the shared libraries does not seem to work, so perhaps a static 
link is occurring somewhere in the build process of ParaView If I just drop in 
my newly built version of osmesa in the superbuild build directory, replacing 
the current version of osmesa and then delete the source, build and install 
versions of ParaView in the superbuild directory forcing a recompile of all of 
ParaView 5.0.1 proper, would you expect that to work? Or am I missing something?

The version of libOSMesa in the superbuild is libOSMesa.so.7 while the new 
versions I am building are libOSMesa.so.8, I made symbolic link with 
libOSMesa.so.7 -> LibOSMesa.so.8 Which paraview seems to find but still 
produces the same error complaining of GL Version 2.1

Thanks,

Joe

~~~
Joseph G. Hennessey Ph.D., Lockheed Martin Army Research Lab DOD Supercomputing 
Resource Center
Email:  joseph.g.hennessey2@mail.mil

-Original Message-
From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Hennessey, 
Joseph G CTR USARMY RDECOM ARL (US)
Sent: Thursday, June 02, 2016 3:47 PM
To: Angelini, Richard C (Rick) CIV USARMY RDECOM ARL (US) 
<richard.c.angelini@mail.mil>; Utkarsh Ayachit 
<utkarsh.ayac...@kitware.com>; Su, Simon M CIV USARMY RDECOM ARL (US) 
<simon.m.su@mail.mil>
Cc: ParaView <paraview@paraview.org>
Subject: Re: [Paraview] [Non-DoD Source] Re: 5.0.1/Exodus Reader (UNCLASSIFIED)

All active links contained in this email were disabled.  Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.  

CLASSIFICATION: UNCLASSIFIED

Utkarsh,

I am running ParaView 5.0.1 connecting to a remote ParaView 5.0.1 server built 
with osmesa

And I have rebuild osmesa from both
Mesa 11.1.2 and Mesa 11.2.2 using

./configure \
--disable-xvmc \
--disable-glx \
--disable-dri \
--with-dri-drivers= \
--with-gallium-drivers=swrast \
--enable-texture-float \
--disable-egl \
--enable-shared \
--with-egl-platforms= \
--enable-gallium-osmesa \
--enable-gallium-llvm=yes \
--prefix=

And I have tried replacing the library

lib/paraview-5.0/libOSMesa.so.7

with both libOSMesa.so from 11.1.2 and 11.2.2

and they are both still giving the same error

paraview/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx line 587 
vtkOSOpenGLRenderWindow GL Version 2.1 with the gpu_shader4 extension is not 
supported by your graphics driver, but is required for the new OpenGL rendering 
 backend. Please update your OpenGL driver.
If you are using Mesa please make sure you have version 10.6.5 and make sure 
your  driver support OpenGL 3.2

Any suggestions?

Thanks,

Joe Hennessey

~~~
Joseph G. Hennessey Ph.D., Lockheed Martin Army Research Lab DOD Supercomputing 
Resource Center
Email:  joseph.g.hennessey2@mail.mil

-Original Message-
From: ParaView [Caution-mailto:paraview-boun...@paraview.org] On Behalf Of 
Angelini, Richard C (Rick) CIV USARMY RDECOM ARL (US)
Sent: Thursday, June 02, 2016 1:45 PM
To: Utkarsh Ayachit <utkarsh.ayac...@kitware.com>
Cc: ParaView <paraview@paraview.org>
Subject: Re: [Paraview] [Non-DoD Source] Re: 5.0.1/Exodus Reader

All active links contained in this email were disabled.  Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.  

Utkarsh - thanks - in the mean time, we're going to try to build Mesa 11.1 (?) 
outside of ParaView and link it in and see how far we can get!   8-)But it 
would certainly be cleaner to use the Superbuild when you get that updated with 
the proper Mesa build!

-Original Message-
From: Utkarsh Ayachit [Caution-Caution-mailto:utkarsh.ayac...@kitware.com]
Sent: Thursday, June 02, 2016 1:18 PM
To: Angelini, Richard C (Rick) CIV USARMY RDECOM ARL (US) 
<richard.c.angelini@mail.mil>
Cc: Chuck Atkins <chuck.atk...@kitware.com>; ParaView <paraview@paraview.org>
Subject: Re: [Paraview] [Non-DoD Source] Re: 5.0.1/Exodus Reader

Roger that. I will have updates for you early next week (plan to work on it as 
soon as I am done with the task at hand).

On Thu, Jun 2, 2016 at 12:45 PM, Angelini, Richard C (Rick) CIV USARMY RDECOM 
ARL (US) <richard.c.angelini@mail.mil> wrote:
> Our *immediate* concern is OSMesa - but we'll probably eventually want to 
> address Mesa w/X support .
>
> -Original Message-
> From: Utkarsh Ayachit
> [Caution-Caution-mailto:utkarsh.ayac...@kitware.com]
> Sent: Thursday, June 02, 2016 9:48 AM
> To: Angelini, Richard C (Rick) CIV US

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

2016-06-02 Thread Hennessey, Joseph G CTR USARMY RDECOM ARL (US)

CLASSIFICATION: UNCLASSIFIED

Utkarsh,

I am running ParaView 5.0.1 connecting to a remote ParaView 5.0.1 server built 
with osmesa

And I have rebuild osmesa from both
Mesa 11.1.2 and Mesa 11.2.2 using

./configure \
--disable-xvmc \
--disable-glx \
--disable-dri \
--with-dri-drivers= \
--with-gallium-drivers=swrast \
--enable-texture-float \
--disable-egl \
--enable-shared \
--with-egl-platforms= \
--enable-gallium-osmesa \
--enable-gallium-llvm=yes \
--prefix=

And I have tried replacing the library

lib/paraview-5.0/libOSMesa.so.7

with both libOSMesa.so from 11.1.2 and 11.2.2

and they are both still giving the same error

paraview/VTK/Rendering/OpenGL2/vtkOpenGLRenderWindow.cxx line 587 
vtkOSOpenGLRenderWindow GL Version 2.1 with the gpu_shader4 extension is not 
supported by your graphics driver, but is required for the new OpenGL rendering 
 backend. Please update your OpenGL driver.
If you are using Mesa please make sure you have version 10.6.5 and make sure 
your  driver support OpenGL 3.2

Any suggestions?

Thanks,

Joe Hennessey

~~~
Joseph G. Hennessey Ph.D., Lockheed Martin Army Research Lab DOD Supercomputing 
Resource Center
120 Aberdeen Blvd.
Aberdeen Proving Ground, MD 21005
Voice:  410-278-3619
Fax:410-278-8799
Email:  joseph.g.hennessey2@mail.mil


-Original Message-
From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Angelini, 
Richard C (Rick) CIV USARMY RDECOM ARL (US)
Sent: Thursday, June 02, 2016 1:45 PM
To: Utkarsh Ayachit 
Cc: ParaView 
Subject: Re: [Paraview] [Non-DoD Source] Re: 5.0.1/Exodus Reader

All active links contained in this email were disabled.  Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser.  






Utkarsh - thanks - in the mean time, we're going to try to build Mesa 11.1 (?) 
outside of ParaView and link it in and see how far we can get!   8-)But it 
would certainly be cleaner to use the Superbuild when you get that updated with 
the proper Mesa build!



-Original Message-
From: Utkarsh Ayachit [Caution-mailto:utkarsh.ayac...@kitware.com]
Sent: Thursday, June 02, 2016 1:18 PM
To: Angelini, Richard C (Rick) CIV USARMY RDECOM ARL (US) 

Cc: Chuck Atkins ; ParaView 
Subject: Re: [Paraview] [Non-DoD Source] Re: 5.0.1/Exodus Reader

Roger that. I will have updates for you early next week (plan to work on it as 
soon as I am done with the task at hand).

On Thu, Jun 2, 2016 at 12:45 PM, Angelini, Richard C (Rick) CIV USARMY RDECOM 
ARL (US)  wrote:
> Our *immediate* concern is OSMesa - but we'll probably eventually want to 
> address Mesa w/X support .
>
> -Original Message-
> From: Utkarsh Ayachit [Caution-mailto:utkarsh.ayac...@kitware.com]
> Sent: Thursday, June 02, 2016 9:48 AM
> To: Angelini, Richard C (Rick) CIV USARMY RDECOM ARL (US) 
> 
> Cc: Chuck Atkins ; ParaView 
> 
> Subject: Re: [Paraview] [Non-DoD Source] Re: 5.0.1/Exodus Reader
>
> Ah okay. Give me a few days to sort it out. The end goal is indeed to have 
> superbuild build the right versions of Mesa. Do you only  care about OSMesa 
> or also Mesa with X support?
>
> Utkarsh
>
>
>
>
> On Thu, Jun 2, 2016 at 8:48 AM, Angelini, Richard C (Rick) CIV USARMY RDECOM 
> ARL (US)  wrote:
>> Our current issues seem to be related to our osmesa build for the HPC_side
>> servers.   The Superbuild is building 7.11.2 - you are suggesting that
>> we need to *manually* build a different version of Mesa and somehow link
>> in that new version of Mesa in to the Superbuild? We rely exclusively
>> on the Superbuild for compiling ParaView across 20 different HPC 
>> systems - so stepping outside of the super build paradigm isn’t necessarily 
>> obvious
>> to me!8-)
>>
>>
>>
>>
>>
>> 
>> Rick Angelini
>> USArmy Research Laboratory
>> CISD/HPC Architectures Team
>> Phone:  410-278-6266
>>
>>
>>
>>
>> -Original Message-
>> From: Utkarsh Ayachit 
>> Date: Thursday, June 2, 2016 at 8:37 AM
>> To: Rick Angelini 
>> Cc: Chuck Atkins , ParaView 
>> 
>> Subject: Re: [Paraview] [Non-DoD Source] Re: 5.0.1/Exodus Reader
>>
>> All active links contained in this email were disabled.  Please 
>> verify the identity of the sender, and confirm the authenticity of 
>> all links contained within the message prior to copying and pasting 
>> the address to a Web browser.
>>
>>
>>
>>
>> 
>>
>>> So there is much more to be done than adding
>>>

Re: [Paraview] [Non-DoD Source] Re: Error when trying to turn on Volume Rendering for large tetrahedral data in ParaView 5.4.1

[Paraview] Error when trying to turn on Volume Rendering for large tetrahedral data in ParaView 5.4.1

[Paraview] Problems with mpi4py and SGI's mpt 2.14 and 2.15 versions of MPI

[Paraview] Using 64 or more cores on a single node when running client/server

[Paraview] Monitoring the progress of a paraview filter

Re: [Paraview] [Non-DoD Source] Eye separation has been wrong since Immersive ParaView 5.2 - here's how to fix it

Re: [Paraview] [Non-DoD Source] Eye separation has been wrong since Immersive ParaView 5.2 - here's how to fix it

Re: [Paraview] [Non-DoD Source] Re: ResetCamera throwing bad_alloc

[Paraview] ResetCamera throwing bad_alloc

Re: [Paraview] [Non-DoD Source] Re: Volume rendering with OSPRay Renderer not working with ParaView 5.3.0-RC3 (UNCLASSIFIED)

[Paraview] Volume rendering with OSPRay Renderer not working with ParaView 5.3.0-RC3 (UNCLASSIFIED)

Re: [Paraview] [Non-DoD Source] XDMF and nested Grid Collections (UNCLASSIFIED)

[Paraview] ParaView 5.1.2 is not recording changes to the LUT position when tracing is one with all options (UNCLASSIFIED)

Re: [Paraview] [Non-DoD Source] Re: Problem with WriteAnimation in a python file silently failing under pvbatch but working when called with pvpython (UNCLASSIFIED)

[Paraview] Problem with WriteAnimation in a python file silently failing under pvbatch but working when called with pvpython (UNCLASSIFIED)

[Paraview] Need paraview data examples with human readable names vs md5 sums (UNCLASSIFIED)

[Paraview] Possible error in loading multiple PLY files at once. (UNCLASSIFIED)

Re: [Paraview] [Non-DoD Source] Re: 5.1.2/OpenGL2 issue (UNCLASSIFIED)

[Paraview] Issues with ParaView 5.1.0 and VGL (UNCLASSIFIED)

Re: [Paraview] [Non-DoD Source] ANN: ParaView 5.1.0 available for download (UNCLASSIFIED)

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

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

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

23 matches

Site Navigation

Mail list logo

Footer information