Re: [Paraview] Change in OpenFOAM mesh reader
Please ignore my previous query. Lack of rigor on my part. Eugene de Villiers Managing Director e.devilli...@engys.com<mailto:e.devilli...@engys.com> Mob: +44 (0) 77 89748490 Tel: +44 (0)20 32393041 (ext. 202) Fax: +44 (0)20 33573123 [EngysR] This message is private and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from your system. ENGYS Limited is a company registered in England & Wales. Register number: 6936178. Register office: 1 The Green, Richmond, Surrey, TW9 1PL, United Kingdom. From: Eugene de Villiers Sent: 06 September 2017 16:13 To: 'paraview@paraview.org' <paraview@paraview.org> Subject: Change in OpenFOAM mesh reader Hi, It seems recent releases of the OpenFOAM reader have modified the interface such that a mesh MUST be present in the constant/polyMesh folder (at least since 5.3). In the past, the reader would also work with a mesh in the zero-time folder. Is there any reason for this change? Having the mesh in the 0-time folder is part of the current OpenFOAM interface standard. Removing this support reduces compatibility. Thanks for your feedback. Eugene de Villiers Managing Director e.devilli...@engys.com<mailto:e.devilli...@engys.com> Mob: +44 (0) 77 89748490 Tel: +44 (0)20 32393041 (ext. 202) Fax: +44 (0)20 33573123 [EngysR] This message is private and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from your system. ENGYS Limited is a company registered in England & Wales. Register number: 6936178. Register office: 1 The Green, Richmond, Surrey, TW9 1PL, United Kingdom. ___ 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] Change in OpenFOAM mesh reader
Hi, It seems recent releases of the OpenFOAM reader have modified the interface such that a mesh MUST be present in the constant/polyMesh folder (at least since 5.3). In the past, the reader would also work with a mesh in the zero-time folder. Is there any reason for this change? Having the mesh in the 0-time folder is part of the current OpenFOAM interface standard. Removing this support reduces compatibility. Thanks for your feedback. Eugene de Villiers Managing Director e.devilli...@engys.com<mailto:e.devilli...@engys.com> Mob: +44 (0) 77 89748490 Tel: +44 (0)20 32393041 (ext. 202) Fax: +44 (0)20 33573123 [EngysR] This message is private and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from your system. ENGYS Limited is a company registered in England & Wales. Register number: 6936178. Register office: 1 The Green, Richmond, Surrey, TW9 1PL, United Kingdom. ___ 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] Suggestion for STL import
Utkarsh, Unfortunately, the STL that produced the issue is confidential and also quite large, so I am unsure how to go about producing something equivalent. Let me know what you find after looking at the reader and I will try to find something appropriate. To be honest, the reasoning is speculative, but it is clear that the STL reader has some drawbacks. At the very least we would be happy to test any alterations you might come up with on the original input. Not merging the points is a reasonable work-around, but you will lose some utility (feature detection). I think it should be relatively easy to create or port an existing algorithm that is a bit more efficient (of course these kind of assumptions tend to be wrong, but anyway!). Eugene From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com] Sent: 05 July 2016 17:05 To: Eugene de Villiers <e.devilli...@engys.com> Cc: paraview@paraview.org Subject: Re: [Paraview] Suggestion for STL import Eugene, I am pretty sure the community will be interested in this! While I'll need to look into the reader to understand, to get things going, do you have a sample dataset to demonstrate the issue? Utkarsh On Tue, Jul 5, 2016 at 10:28 AM, Eugene de Villiers <e.devilli...@engys.com<mailto:e.devilli...@engys.com>> wrote: Hi, When importing STL format geometry or similar, where connectivity information is not implicit in the data structure, it appears that the connectivity is reconstructed via an octree search. This is very inefficient when surfaces with large differences in edge length are imported – we have had a recent case where an STL took 45mins to load. If the same input geometry is converted to OBJ format via an external tool, the load time reduces to minutes. A generally more efficient method is to calculate the distance of each point from a location outside the point cloud bounding box and then to bubble-sort the resulting list. Unless you are dealing with a pathological case your local search neighbourhood of identical distance points will be small and the algorithm very fast. More complex, multi-origin algorithms are also possible to counter pathological instances. I can provide more details and sample code if you are interested. Best regards, Eugene de Villiers Managing Director e.devilli...@engys.com<mailto:e.devilli...@engys.com> Mob: +44 (0) 77 89748490<tel:%2B44%20%280%29%2077%2089748490> Tel: +44 (0)20 32393041<tel:%2B44%20%280%2920%2032393041> (ext. 102) Fax: +44 (0)20 33573123<tel:%2B44%20%280%2920%2033573123> [logo_red-black_fonts_signature]<http://www.engys.com/> This message is intended only for the use of the addressee and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from your system. ___ Powered by www.kitware.com<http://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
[Paraview] Suggestion for STL import
Hi, When importing STL format geometry or similar, where connectivity information is not implicit in the data structure, it appears that the connectivity is reconstructed via an octree search. This is very inefficient when surfaces with large differences in edge length are imported – we have had a recent case where an STL took 45mins to load. If the same input geometry is converted to OBJ format via an external tool, the load time reduces to minutes. A generally more efficient method is to calculate the distance of each point from a location outside the point cloud bounding box and then to bubble-sort the resulting list. Unless you are dealing with a pathological case your local search neighbourhood of identical distance points will be small and the algorithm very fast. More complex, multi-origin algorithms are also possible to counter pathological instances. I can provide more details and sample code if you are interested. Best regards, Eugene de Villiers Managing Director e.devilli...@engys.com<mailto:e.devilli...@engys.com> Mob: +44 (0) 77 89748490 Tel: +44 (0)20 32393041 (ext. 102) Fax: +44 (0)20 33573123 [logo_red-black_fonts_signature]<http://www.engys.com/> This message is intended only for the use of the addressee and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from your system. ___ 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
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
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 filter
Hi Takuya! The problem is that not all boundaries have "value" entries. zeroGradient, fixedGradient, symmetry, empty - none have values. It is a frustrating inconsistency for 3rd-party interfaces, but that's the way it is unfortunately. If you want a reasonable and straight-forward solution, I would say check for a "value" entry and if you don't find it assume zero gradient. From our side it is much easier to modify boundaries to write value fields than to change the reader to deal with exceptions and new formats. The "value" entry format is also well defined (i.e. there are only two permutations), so it is easier to support. I know nothing about the parser, but I should note that it is entirely possible that multiple "value" keywords might exist in a boundary at different levels of the input structure. 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. So some kind of interpretation of OPENFOAM syntax would be required - a simple pattern-match won't work. Eugene -Original Message- From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Takuya OSHIMA Sent: 22 June 2016 16:22 To: paraview@paraview.org Subject: Re: [Paraview] Minor bug in OPENFOAM filter Hi Eugene and all, Sorry for not giving a concrete solution but just a comment. The current reader handles the complex OpenFOAM format without a priori knowledge of exact format of a specific dictionary entry. With further growing complexity and format extensions made over OpenFOAM versions, there can always be such a problem especially when reading entries required by certain types of boundary conditions. Either implementing such knowledge or skipping the entire dictionary entries other than the "value" entries in the boudaryFields could be an idea though. Takuya OSHIMA, Ph.D. Faculty of Engineering, Niigata University 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN From: paraview-requ...@paraview.org Subject: ParaView Digest, Vol 146, Issue 25 Date: Tue, 21 Jun 2016 12:00:08 -0400 > Hi, > > We have come across a minor but annoying bug in the Paraview OPENFOAM reader. > > The component of the Paraview OPENFOAM parser that reads boundary conditions > has been set up to always expect another number where a scalar is encountered > in the following configuration: > > (1.111 ### > > when you follow a bracket-scalar with another bracket like this > > (1.111 ( > > an exception is thrown and the field is not loaded. However, if the leading > number is an integer, then it copes fine: > > (1 (### > > So it simply doesn't parse a scalar followed by a bracket. Most of such > instances are not relevant to the display of data as they concern table > inputs for time varying vector boundary conditions. The current workaround is > to always use integers in interpolation input tables, but obviously this is > not ideal. To reproduce the issue, simply add the following entry to any > boundary condition for any volumetric field: > > RandomEntry table (1.1 ( 1 2 3)); > > It will result in an "Error reading line XXX ... " output and the field that > the entry was added to will not be loaded. If you change it to: > > RandomEntry table (1 ( 1 2 3)); > > Then it works fine. I can provide a small case that reproduces the issue if > the above is not clear. > > Best regards, > > Eugene de Villiers > e.devilli...@engys.com<mailto:e.devilli...@engys.com> > Mob: +44 (0) 77 89748490 > Tel: +44 (0)20 32393041 (ext. 102) > Fax: +44 (0)20 33573123 > [logo_red-black_fonts_signature]<http://www.engys.com/> > > This message is intended only for the use of the addressee and may contain > information that is privileged, confidential and exempt from disclosure under > applicable law. If the reader of this message is not the intended recipient, > or the employee or agent responsible for delivering the message to the > intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. If you > have received this e-mail in error, please notify us immediately by return > e-mail and delete this e-mail and all attachments from your system. > ___ 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
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
[Paraview] Minor bug in OPENFOAM import filter
Hi, We have come across a minor, but annoying bug in the Paraview OPENFOAM reader. The component of the Paraview OPENFOAM parser that reads boundary conditions has been set up to always expect another number where a scalar is encountered in the following configuration: (1.111 ### when you follow a bracket-scalar with another bracket like this (1.111 ( an exception is thrown and the field is not loaded. However, if the leading number is an integer, then it copes fine: (1 (### So it simply doesn't parse a scalar followed by a bracket. Most of such instances are not relevant to the display of data as they concern table inputs for time varying vector boundary conditions. The current workaround is to always use integers in interpolation input tables, but obviously this is not ideal. To reproduce the issue, simply add the following entry to any boundary condition for any volumetric field: RandomEntry table (1.1 ( 1 2 3)); It will result in an "Error reading line XXX ... " output and the field that the entry was added to will not be loaded. If you change it to: RandomEntry table (1 ( 1 2 3)); Then it works fine. I can provide a small case that reproduces the issue if the above is not clear. Best regards, Eugene de Villiers e.devilli...@engys.com<mailto:e.devilli...@engys.com> Mob: +44 (0) 77 89748490 Tel: +44 (0)20 32393041 (ext. 102) Fax: +44 (0)20 33573123 [logo_red-black_fonts_signature]<http://www.engys.com/> This message is intended only for the use of the addressee and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from your system. ___ 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] Minor bug in OPENFOAM filter
Hi, We have come across a minor but annoying bug in the Paraview OPENFOAM reader. The component of the Paraview OPENFOAM parser that reads boundary conditions has been set up to always expect another number where a scalar is encountered in the following configuration: (1.111 ### when you follow a bracket-scalar with another bracket like this (1.111 ( an exception is thrown and the field is not loaded. However, if the leading number is an integer, then it copes fine: (1 (### So it simply doesn't parse a scalar followed by a bracket. Most of such instances are not relevant to the display of data as they concern table inputs for time varying vector boundary conditions. The current workaround is to always use integers in interpolation input tables, but obviously this is not ideal. To reproduce the issue, simply add the following entry to any boundary condition for any volumetric field: RandomEntry table (1.1 ( 1 2 3)); It will result in an "Error reading line XXX ... " output and the field that the entry was added to will not be loaded. If you change it to: RandomEntry table (1 ( 1 2 3)); Then it works fine. I can provide a small case that reproduces the issue if the above is not clear. Best regards, Eugene de Villiers e.devilli...@engys.com<mailto:e.devilli...@engys.com> Mob: +44 (0) 77 89748490 Tel: +44 (0)20 32393041 (ext. 102) Fax: +44 (0)20 33573123 [logo_red-black_fonts_signature]<http://www.engys.com/> This message is intended only for the use of the addressee and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from your system. ___ 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
