Re: [Paraview] Minor bug in OPENFOAM import filter

2016-06-29 Thread Eugene de Villiers
David,

That’s perfect.

Eugene

From: David Lonie [mailto:david.lo...@kitware.com]
Sent: 28 June 2016 21:40
To: Eugene de Villiers <e.devilli...@engys.com>
Cc: Takuya OSHIMA <osh...@eng.niigata-u.ac.jp>; paraview@paraview.org
Subject: Re: [Paraview] Minor bug in OPENFOAM import filter

On Tue, Jun 28, 2016 at 3:06 PM, David Lonie 
<david.lo...@kitware.com<mailto:david.lo...@kitware.com>> wrote:
On Sat, Jun 25, 2016 at 1:02 PM, Eugene de Villiers 
<e.devilli...@engys.com<mailto:e.devilli...@engys.com>> wrote:
Hi Takuya, David,

That would be perfect. What kind of timeline are we looking at to see this in a 
release version?

It's difficult to say for sure. It might be out in the next patch release, but 
it might have to wait for the next major/minor release. The openFOAM reader is 
a complicated bit of code, I'm still investigating the best way to go about 
implementing this. I'll update this thread once I know more.

Good news -- I found an easy fix. Instead of failing outright when

(scalar (scalar scalar))

is found because the internal data structures can't handle nested lists 
following scalar data, I patched the reader to simply read the nested list, 
discard it, print a warning, and continue reading the file.

You'll still see a warning pop up in paraview, but the file should still read 
successfully as long as the unsupported list does not appear in a field used 
for visualization.

The patch is here: https://gitlab.kitware.com/vtk/vtk/merge_requests/1598

If this is agreeable to everyone, we'll get it merged and incorporated into a 
future release.

Dave
___
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] Minor bug in OPENFOAM import filter

2016-06-28 Thread David Lonie
On Tue, Jun 28, 2016 at 3:06 PM, David Lonie 
wrote:

> On Sat, Jun 25, 2016 at 1:02 PM, Eugene de Villiers <
> e.devilli...@engys.com> wrote:
>
>> Hi Takuya, David,
>>
>> That would be perfect. What kind of timeline are we looking at to see
>> this in a release version?
>>
>
> It's difficult to say for sure. It might be out in the next patch release,
> but it might have to wait for the next major/minor release. The openFOAM
> reader is a complicated bit of code, I'm still investigating the best way
> to go about implementing this. I'll update this thread once I know more.
>

Good news -- I found an easy fix. Instead of failing outright when

(scalar (scalar scalar))

is found because the internal data structures can't handle nested lists
following scalar data, I patched the reader to simply read the nested list,
discard it, print a warning, and continue reading the file.

You'll still see a warning pop up in paraview, but the file should still
read successfully as long as the unsupported list does not appear in a
field used for visualization.

The patch is here: https://gitlab.kitware.com/vtk/vtk/merge_requests/1598

If this is agreeable to everyone, we'll get it merged and incorporated into
a future release.

Dave
___
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] Minor bug in OPENFOAM import filter

2016-06-28 Thread David Lonie
On Sat, Jun 25, 2016 at 1:02 PM, Eugene de Villiers 
wrote:

> Hi Takuya, David,
>
> That would be perfect. What kind of timeline are we looking at to see this
> in a release version?
>

It's difficult to say for sure. It might be out in the next patch release,
but it might have to wait for the next major/minor release. The openFOAM
reader is a complicated bit of code, I'm still investigating the best way
to go about implementing this. I'll update this thread once I know more.

Dave
___
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] Minor bug in OPENFOAM import filter

2016-06-25 Thread Eugene de Villiers
Hi Takuya, David,

That would be perfect. What kind of timeline are we looking at to see this in a 
release version?

Eugene

-Original Message-
From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Takuya OSHIMA
Sent: 25 June 2016 12:11
To: paraview@paraview.org
Subject: Re: [Paraview] Minor bug in OPENFOAM import filter

Hi David and Eugene,

From: David Lonie <david.lo...@kitware.com>
Subject: Re: [Paraview] Minor bug in OPENFOAM import filter
Date: Fri, 24 Jun 2016 13:34:10 -0400

> Alternatively, I saw some discussion around skipping every entry in 
> boundaryField specifications other than 'value'. This would likely be 
> quite easy to implement. My only question is, would it break anything 
> for the visualization?

It would be better if other entries like "gradient" (for Neumann-type boundary 
conditions) can also be taken into account.  However it needs a lot of work (we 
need to add a logic to calculate the distance from the adjacent cell center to 
the boundary face etc.).  I think for now we need to live with skipping every 
entry other than "value".

From: Eugene de Villiers <e.devilli...@engys.com>
Subject: RE: [Paraview] Minor bug in OPENFOAM filter
Date: Wed, 22 Jun 2016 15:56:56 +

> I would say check for a "value" entry and if you don't find it assume 
> zero gradient.

If I remember correctly, the reader already has a check for a "value"
entry and if not found it assumes zero gradient.

> It is important that only the first value entry on the base level of 
> the boundary condition is actually identified as the face value 
> correlated "value" entry.

I am sure that the reader already does this as well.

Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN

From: David Lonie <david.lo...@kitware.com>
Subject: Re: [Paraview] Minor bug in OPENFOAM import filter
Date: Fri, 24 Jun 2016 13:34:10 -0400

> Hi Eugene,
> 
> On Wed, Jun 22, 2016 at 11:45 AM, Eugene de Villiers 
> <e.devilli...@engys.com
>> wrote:
> 
>> Attached find a small case
>>
> 
> Thanks -- I've loaded this up and can reproduce the error. The error 
> occurs in vtkFoamEntryValue::ReadList, which contains the following comment:
> 
> // general-purpose list reader - guess the type of the list and read
> 
> // it. only supports ascii format and assumes the preceding '(' has
> 
> // already been thrown away.  the reader supports nested list with
> 
> // variable lengths (e. g. `((token token) (token token token)).'
> 
> // also *supports compound of tokens and lists (e. g. `((token token)*
> 
> // *token)') only if a list comes as the first value.*
> 
> 
> So the list (1.1 (1 2 3)) is being parsed as a list, and our reader 
> only supports lists
> 
> containing mixed tokens / lists if the lists precede the tokens. And 
> indeed, changing
> 
> file to read ((1 2 3) 1.1) will eliminate the error. The current 
> parser assumes that the
> 
> remainder of the list will also be scalars and attempts to read them 
> in -- then it
> 
> chokes when it encounters a '(' instead of another scalar.
> 
> 
> Again, I'm not familiar with the openFOAM format, but would writing 
> the list with the
> 
> nested list first be feasible on your end? I'm not sure if this is a 
> format restriction or
> 
> an implementation detail of our reader.
> 
> 
> Alternatively, I saw some discussion around skipping every entry in 
> boundaryField
> 
> specifications other than 'value'. This would likely be quite easy to 
> implement. My
> 
> only question is, would it break anything for the visualization?
> 
> 
> Dave
___
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
___
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] Minor bug in OPENFOAM import filter

2016-06-25 Thread Takuya OSHIMA
Hi David and Eugene,

From: David Lonie <david.lo...@kitware.com>
Subject: Re: [Paraview] Minor bug in OPENFOAM import filter
Date: Fri, 24 Jun 2016 13:34:10 -0400

> Alternatively, I saw some discussion around skipping every entry in
> boundaryField specifications other than 'value'. This would likely
> be quite easy to implement. My only question is, would it break
> anything for the visualization?

It would be better if other entries like "gradient" (for Neumann-type
boundary conditions) can also be taken into account.  However it needs
a lot of work (we need to add a logic to calculate the distance from
the adjacent cell center to the boundary face etc.).  I think for now
we need to live with skipping every entry other than "value".

From: Eugene de Villiers <e.devilli...@engys.com>
Subject: RE: [Paraview] Minor bug in OPENFOAM filter
Date: Wed, 22 Jun 2016 15:56:56 +

> I would say check for a "value" entry and if you don't find it
> assume zero gradient.

If I remember correctly, the reader already has a check for a "value"
entry and if not found it assumes zero gradient.

> It is important that only the first value entry on the base level of
> the boundary condition is actually identified as the face value
> correlated "value" entry.

I am sure that the reader already does this as well.

Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN

From: David Lonie <david.lo...@kitware.com>
Subject: Re: [Paraview] Minor bug in OPENFOAM import filter
Date: Fri, 24 Jun 2016 13:34:10 -0400

> Hi Eugene,
> 
> On Wed, Jun 22, 2016 at 11:45 AM, Eugene de Villiers <e.devilli...@engys.com
>> wrote:
> 
>> Attached find a small case
>>
> 
> Thanks -- I've loaded this up and can reproduce the error. The error occurs
> in vtkFoamEntryValue::ReadList, which contains the following comment:
> 
> // general-purpose list reader - guess the type of the list and read
> 
> // it. only supports ascii format and assumes the preceding '(' has
> 
> // already been thrown away.  the reader supports nested list with
> 
> // variable lengths (e. g. `((token token) (token token token)).'
> 
> // also *supports compound of tokens and lists (e. g. `((token token)*
> 
> // *token)') only if a list comes as the first value.*
> 
> 
> So the list (1.1 (1 2 3)) is being parsed as a list, and our reader
> only supports lists
> 
> containing mixed tokens / lists if the lists precede the tokens. And
> indeed, changing
> 
> file to read ((1 2 3) 1.1) will eliminate the error. The current
> parser assumes that the
> 
> remainder of the list will also be scalars and attempts to read them
> in -- then it
> 
> chokes when it encounters a '(' instead of another scalar.
> 
> 
> Again, I'm not familiar with the openFOAM format, but would writing
> the list with the
> 
> nested list first be feasible on your end? I'm not sure if this is a
> format restriction or
> 
> an implementation detail of our reader.
> 
> 
> Alternatively, I saw some discussion around skipping every entry in
> boundaryField
> 
> specifications other than 'value'. This would likely be quite easy to
> implement. My
> 
> only question is, would it break anything for the visualization?
> 
> 
> Dave
___
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] Minor bug in OPENFOAM import filter

2016-06-24 Thread David Lonie
Hi Eugene,

On Wed, Jun 22, 2016 at 11:45 AM, Eugene de Villiers  wrote:

> Attached find a small case
>

Thanks -- I've loaded this up and can reproduce the error. The error occurs
in vtkFoamEntryValue::ReadList, which contains the following comment:

// general-purpose list reader - guess the type of the list and read

// it. only supports ascii format and assumes the preceding '(' has

// already been thrown away.  the reader supports nested list with

// variable lengths (e. g. `((token token) (token token token)).'

// also *supports compound of tokens and lists (e. g. `((token token)*

// *token)') only if a list comes as the first value.*


So the list (1.1 (1 2 3)) is being parsed as a list, and our reader
only supports lists

containing mixed tokens / lists if the lists precede the tokens. And
indeed, changing

file to read ((1 2 3) 1.1) will eliminate the error. The current
parser assumes that the

remainder of the list will also be scalars and attempts to read them
in -- then it

chokes when it encounters a '(' instead of another scalar.


Again, I'm not familiar with the openFOAM format, but would writing
the list with the

nested list first be feasible on your end? I'm not sure if this is a
format restriction or

an implementation detail of our reader.


Alternatively, I saw some discussion around skipping every entry in
boundaryField

specifications other than 'value'. This would likely be quite easy to
implement. My

only question is, would it break anything for the visualization?


Dave
___
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] Minor bug in OPENFOAM import filter

2016-06-22 Thread Eugene de Villiers
Hi Dave,

Sure thing. Attached find a small case. Just load the “case.foam” file from 
inside the directory once you have uncompressed it. You will see the error pop 
up (I am running Paraview 5.0.0).

Thanks for your help,

Eugene



From: David Lonie [mailto:david.lo...@kitware.com]
Sent: 22 June 2016 15:20
To: Eugene de Villiers <e.devilli...@engys.com>
Cc: paraview@paraview.org
Subject: Re: [Paraview] Minor bug in OPENFOAM import filter

On Wed, Jun 22, 2016 at 8:04 AM, Eugene de Villiers 
<e.devilli...@engys.com<mailto:e.devilli...@engys.com>> wrote:
Hi,

We have come across a minor, but annoying bug in the Paraview OPENFOAM reader.

Hi Eugene,

I'll take a look at this. I'm not terribly familiar with openfoam files, so if 
you could send me that small example to reproduce the bug I'd appreciate it :)

Thanks,
Dave


cavity.tar.gz
Description: cavity.tar.gz
___
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] Minor bug in OPENFOAM import filter

2016-06-22 Thread David Lonie
On Wed, Jun 22, 2016 at 8:04 AM, Eugene de Villiers 
wrote:

> Hi,
>
>
>
> We have come across a minor, but annoying bug in the Paraview OPENFOAM
> reader.
>

Hi Eugene,

I'll take a look at this. I'm not terribly familiar with openfoam files, so
if you could send me that small example to reproduce the bug I'd appreciate
it :)

Thanks,
Dave
___
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