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 +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.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