[Paraview] Minor bug in OPENFOAM import filter

[Takuya OSHIMA]

Hi David and Eugene,

From: David Lonie <david.lonie at 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.devilliers at engys.com>
Subject: RE: [Paraview] Minor bug in OPENFOAM filter
Date: Wed, 22 Jun 2016 15:56:56 +0000

> 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.lonie at 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.devilliers at 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