CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Paraview & paraFoam

Native ParaView Reader Bugs

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree3Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   September 12, 2010, 17:14
Default SurfaceFields in the Paraview Reader
  #221
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
Hi Takuya,
Just wanted you to know that I took a look at the surfaceFields on your reader this weekend, and managed to successfully implement it.

I resorted to using the ParaView-3.6.1 version of the reader (r173-20090920), and from your latest SVN logs, it looks like my modifications would not conflict with any of the latest additions (like the vtkPolyhedron stuff).

I've also provided a snapshot of the new functionality:




It's been tested with mesh-motion and topo-changes, so I'm pretty sure it works well. I haven't incorporated other functionality like face-point interpolation, but it shouldn't be too tough to add at this point.

Internal surfaceFields are switched off by default, but can be added using the 'Read internal surface meshes' option. When this is switched off, only boundaryFields of surfaceFields can be viewed.

I'm also attaching the sources for other folks to take a look at. I must apologize for the heavy formatting modifications, and you're welcome to incorporate them if you wish.
Attached Files
File Type: gz vtkOpenFOAMReaderSurfaceFields.tar.gz (93.8 KB, 13 views)
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   September 14, 2010, 00:42
Default
  #222
Super Moderator
 
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 11
7islands is on a distinguished road
Excellent. I'll see if I can forward-port your code to the SVN version (I must admit the biggest obstacle is the formatting changes which made simple diff'ing useless).

About the point interpolation stuff I'm opted for leaving it off, since point-interpolated (averaged) face flux across faces with different normal directions that are connected to a point do not have physical meaning anyway.

Meanwhile, do you have any idea about how we create glyphs out of the polygonal data? If we don't have to take face areas into account
* Generate Surface Normals (Compute Cell Normals: on)
-> Cell Centers
-> Glyph (Scalars: phi, Vectors: Normals, Scale Mode: scalar)
should work but is it sufficient?

Takuya
7islands is offline   Reply With Quote

Old   September 14, 2010, 09:52
Default
  #223
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
Point interpolation for face-fluxes probably doesn't make sense, but for other tensorial data, like surface(Vector/Tensor)Fields, it's probably okay.

I haven't tried your approach for glyphs, and it's probably the best way to do it, but for testing, i wrote out fluxes in vector form from FOAM:

surfaceVectorField phiVec = phi * (mesh.Sf() / mesh.magSf());

if (mesh.time().outputTime())
{
phiVec.write();
}
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   September 14, 2010, 11:37
Default
  #224
Super Moderator
 
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 11
7islands is on a distinguished road
Quote:
Originally Posted by deepsterblue View Post
Point interpolation for face-fluxes probably doesn't make sense, but for other tensorial data, like surface(Vector/Tensor)Fields, it's probably okay.
Sounds reasonable, I'd accept point interpolation code (with some mechanisms to avoid confusion for face fluxes) if someone contributes.

Quote:
I haven't tried your approach for glyphs, and it's probably the best way to do it, but for testing, i wrote out fluxes in vector form from FOAM:

surfaceVectorField phiVec = phi * (mesh.Sf() / mesh.magSf());

if (mesh.time().outputTime())
{
phiVec.write();
}
Got it, thanks for the clarification.

There are still many adjustments yet to make but it's been integrated and working with the SVN version of the reader now. Again, thanks for the contribution.

Takuya
7islands is offline   Reply With Quote

Old   December 3, 2010, 12:55
Default pointData at BC: append vs. multiblock
  #225
Member
 
Oliver Borm
Join Date: Mar 2009
Posts: 59
Rep Power: 8
deepblue17 is on a distinguished road
Hello,

I've just tested the latest version of this reader, which works in general really good! But I have a small problem in a decomposed case. When I look at the point data (cell data is all ok), there is a difference between the Appended and the Multiblock version. It seems to me, that the BC in the appended version are not correctly treated, as these values are just zero. Also the clean to grid filter does not help. Working with the appended version, makes it much easier to extract desired blocks from the imported case.

Can anybody reproduce this?

Thanks
Attached Images
File Type: jpg appended.jpg (18.6 KB, 21 views)
File Type: jpg multiblock.jpg (15.1 KB, 17 views)
deepblue17 is offline   Reply With Quote

Old   December 3, 2010, 23:13
Default
  #226
Super Moderator
 
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 11
7islands is on a distinguished road
Hi Oliver,
* I cannot replicate the BC problem. Can you tell me the exact replication procedure, preferably by modifying one of the tutorial cases? Or if you won't mind you can send me the whole case via dropbox.com or whatnot. And can you elaborate more to explain what the two pictures are?

* I don't get what you mean by "Working with the appended version, makes it much easier to extract desired blocks from the imported case." Can you elaborate a bit more please?

T
7islands is offline   Reply With Quote

Old   December 5, 2010, 09:03
Default
  #227
Member
 
Oliver Borm
Join Date: Mar 2009
Posts: 59
Rep Power: 8
deepblue17 is on a distinguished road
Hello,

the pictures show the point data static pressure. The first one with the

Case Type: Decomposed Case (Appended)

and the second one:

Case Type: Decomposed Case (Multiblock)

As you can see at the cyclicGgi boundary conditions there are nodes with a zero static pressure. The hole at the front patch where the values are identical in both pictures is just another processor.

I think the problem is with ggi type boundary conditions, which are only available in the extend version. As example you can use the tutorials/incompressible/icoDyMFoam/turboPassageRotating case: http://openfoam-extend.git.sourcefor...assageRotating


I just wanted to say, that the Option "Case Type: Decomposed Case (Appended)" is much more handy in some circumstances.

Last edited by deepblue17; December 5, 2010 at 09:31. Reason: tutorial case
deepblue17 is offline   Reply With Quote

Old   December 5, 2010, 09:21
Default
  #228
Senior Member
 
BastiL
Join Date: Mar 2009
Posts: 471
Rep Power: 11
bastil is on a distinguished road
Quote:
Originally Posted by deepblue17 View Post
Case Type: Decomposed Case (Appended)

and the second one:

Case Type: Decomposed Case (Multiblock)
What is the difference between those two options, please?
bastil is offline   Reply With Quote

Old   December 5, 2010, 09:25
Default
  #229
Member
 
Oliver Borm
Join Date: Mar 2009
Posts: 59
Rep Power: 8
deepblue17 is on a distinguished road
From the OFFReader README file:

2. The reader reconstructs decomposed meshes within a pvserver
process when in Decomposed Case (Appended) mode. Contrarily,
Decomposed Case (Multiblock) mode does not merge meshes but
output bare mesh of each decomposed region as a block of a
multiblock dataset.
deepblue17 is offline   Reply With Quote

Old   December 5, 2010, 10:42
Default
  #230
Super Moderator
 
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 11
7islands is on a distinguished road
Hi Oliver,
Thanks for the suggestion about the tutorial case. I cannot promise that I'll check it soon if it will require an installation of 1.6-ext though.

Quote:
Originally Posted by deepblue17 View Post
I just wanted to say, that the Option "Case Type: Decomposed Case (Appended)" is much more handy in some circumstances.
True, because as written in README the modes have different design points, in particular the multiblock mode is not for usability but for performance (I'd call them decomposed modes "for novices" and "for experts"). That is why the old mode had not been removed but kept with (Appended) added to its name.
Quote:
- Added "Decomposed Case (Multiblock)" mode to output each processor
subcase as a block of a multiblock dataset. The mode takes less
memory since each block will not be appended, hence no duplicated
dataset. The mode is also useful to check which mesh region
belongs to which processor subcase (Select vtkCompositeIndex from
Color By if one only want to see by colors, or select
Filters->Block Scalars if exact processor subdirectory number is
needed). The former "Decomposed Case" selection was renamed to
"Decomposed Case (Appended)".
Takuya
7islands is offline   Reply With Quote

Old   December 6, 2010, 08:51
Default
  #231
Super Moderator
 
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 11
7islands is on a distinguished road
Hi Oliver,
The problem was not a bug in the reader itself but was an artifact coming from a behavior of the append filter that is used by the reader internally. The append filter merges coincident points across decomposed regions (sort of "reconstructPar on the fly") within a server process and overrides the original values with the global face zone values which are in fact nonexistent. A workaround is either to use the multiblock mode or to run as many pvservers as the number of decomposed regions.

T
7islands is offline   Reply With Quote

Old   December 6, 2010, 10:54
Default
  #232
Member
 
Oliver Borm
Join Date: Mar 2009
Posts: 59
Rep Power: 8
deepblue17 is on a distinguished road
Hello Takuya,

thanks for having a look at it. The third workaround would be to use reconstructPar in advance. And the fourth would be, to just read the cell data (deactivate "Create cell-to-point filtered data") and apply afterwards the CellDataToPointData filter.

Is there any possibility to "fix" the append filter and assign the correct values from the patches and not the global face zones?

Or as alternative, how difficult would it be to assign the variables to the face and cell zones, if I active the "Read zones" button? At the moment I do the following, read the Internal Mesh and the zones. Apply the "Extract Block Filter" to the Internal Mesh and also to the desired CellZone. Afterwards apply the "Resample With Dataset" filter, with Input = Internal Mesh and Source = my CellZone in order to interpolate the variables to my cell zone.

Thanks,
Oliver
deepblue17 is offline   Reply With Quote

Old   December 6, 2010, 11:43
Default
  #233
Super Moderator
 
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 11
7islands is on a distinguished road
Quote:
Originally Posted by deepblue17 View Post
Hello Takuya,

thanks for having a look at it. The third workaround would be to use reconstructPar in advance. And the fourth would be, to just read the cell data (deactivate "Create cell-to-point filtered data") and apply afterwards the CellDataToPointData filter.
Uh, feel free to do whatever you like to do

Quote:
Is there any possibility to "fix" the append filter and assign the correct values from the patches and not the global face zones?
One way is to raise a discussion on the VTK-developers list about the behavior of the append filter. The behavior is caused by a relatively new modification to the filter
http://vtk.org/gitweb?p=VTK.git;a=co...2e01ae94c5e0ad
to fix what the VTK developers call a bug. If you are persuasive enough to make the developers believe the fix was not quite right for certain use cases there may be a good chance that the developers will reconsider.

Quote:
Or as alternative, how difficult would it be to assign the variables to the face and cell zones, if I active the "Read zones" button? At the moment I do the following, read the Internal Mesh and the zones. Apply the "Extract Block Filter" to the Internal Mesh and also to the desired CellZone. Afterwards apply the "Resample With Dataset" filter, with Input = Internal Mesh and Source = my CellZone in order to interpolate the variables to my cell zone.
Not sure until someone actually tries to add that feature, but one possible hurdle is how to tread zones outside of valid fields. If you implement the feature really well I'd be happy to include it in the reader.

Takuya
7islands is offline   Reply With Quote

Old   December 6, 2010, 12:43
Default
  #234
Member
 
Oliver Borm
Join Date: Mar 2009
Posts: 59
Rep Power: 8
deepblue17 is on a distinguished road
Quote:
Originally Posted by 7islands View Post
Not sure until someone actually tries to add that feature, but one possible hurdle is how to tread zones outside of valid fields.
Can you give an example when and why this should happen? I think there are only two possibilities. Either assign a default value, for example zero. Or split one region in two blocks, and assign the values were appropriate.
deepblue17 is offline   Reply With Quote

Old   December 6, 2010, 21:37
Default
  #235
Super Moderator
 
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 11
7islands is on a distinguished road
Quote:
Originally Posted by deepblue17 View Post
Can you give an example when and why this should happen?
An example is global face zones that are present in parallel ggi cases. They partially are in boundary faces (where valid fields are defined) whereas the valid fields of the rest are only in other decomposed regions. Certainly this will not be the only example since OpenFOAM is a fully customizable toolbox. I meant by "really well" in my previous post that a developer has to make a full imagination of possible use cases.

Quote:
I think there are only two possibilities. Either assign a default value, for example zero. Or split one region in two blocks, and assign the values were appropriate.
Or pull field values from other decomposed regions, assign NaNs, ..., etc. No one knows what approach is best, so a developer will have to do some trials. Frankly, I'm not sure all these are rewarding tasks for a contributor or even me.

Takuya
7islands is offline   Reply With Quote

Old   December 15, 2010, 20:14
Default
  #236
Member
 
Pablo Caron
Join Date: Nov 2009
Location: Buenos Aires, Argentina
Posts: 73
Rep Power: 7
pcaron is on a distinguished road
Hi Takuya,

Have you installed OpenFOAM-1.6-ext? There is a new way of compiling ThirdParty software and I couldn't find out how to compile paraview with MPI enabled.

I want to use the svn version of the reader.

Any ideas how to turn it on?

Thanks in advance.

Regards

Pablo
pcaron is offline   Reply With Quote

Old   December 15, 2010, 20:30
Default
  #237
Super Moderator
 
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 11
7islands is on a distinguished road
Hi Pablo,
Sorry but no, I haven't looked at that part of ThirdParty yet. I just built a normal version of ParaView.

T
7islands is offline   Reply With Quote

Old   January 18, 2011, 22:16
Default
  #238
Super Moderator
 
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 11
7islands is on a distinguished road
Oliver,
Quote:
Originally Posted by deepblue17 View Post
Is there any possibility to "fix" the append filter and assign the correct values from the patches and not the global face zones?
FYI, This should have been fixed. A good guy at Kitware restored the old behavior of the append filter in the git master of paraview/vtk.

Takuya
7islands is offline   Reply With Quote

Old   June 9, 2011, 15:12
Default kde-4.6.2 warnings
  #239
Member
 
Oliver Borm
Join Date: Mar 2009
Posts: 59
Rep Power: 8
deepblue17 is on a distinguished road
I recently updated kde to version 4.6.2. And now when starting paraview with the pf helper script the following warning appears, even with the foreground option and each time I select the reader in the paraview GUI pipeline:

Code:
Application asked to unregister timer 0x75000018 which is not registered in this thread. Fix application.
While starting paraview normally everthing is working fine. Do you have any idea why this problem occurs?

paraview is still working as expected, but after some time it's just annoying this ouput message window from pv. I assume it is some problem with the trap command.
deepblue17 is offline   Reply With Quote

Old   June 9, 2011, 16:18
Default
  #240
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,301
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Oliver,

Quote:
Originally Posted by deepblue17 View Post
While starting paraview normally everthing is working fine. Do you have any idea why this problem occurs?
Just to be sure, which reader are you talking about? The one integrated with ParaView or the one that is provided with OpenFOAM?

I personally haven't had the time to try and reproduce this with the latest Ubuntu, but I've read here in the forum (if I'm not mistaken) about people having the same problem when using OpenCFD's official release of ParaView for OpenFOAM in Ubuntu Natty (11.04).

Either way, these kinds of issues with ParaView are usually solved by rebuilding ParaView against the latest libraries, thus resolving some loose symbols that might get broken with the updates.

Ah, wait a second, I remember when it was the first time I read about this: http://www.cfd-online.com/Forums/blo...tml#comment762
Keep reading the comments and in that case, it was a kernel related issue...

Sooo, upgrading to ParaView 3.10.1 might be a good thing to do...

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Native VisIt Reader Bugs tj22 OpenFOAM Paraview & paraFoam 8 November 8, 2013 05:21
ParaView Reader %7c Visit tj22 OpenFOAM Paraview & paraFoam 16 September 25, 2008 14:01
OpenFOAM reader in the ParaView CVS tj22 OpenFOAM Paraview & paraFoam 16 December 22, 2007 10:05
Posted OpenFOAM native reader for ParaView3CVS 7islands OpenFOAM Paraview & paraFoam 0 October 24, 2007 10:52
Trying to submit soon Paraview reader tj22 OpenFOAM Paraview & paraFoam 3 June 5, 2006 14:07


All times are GMT -4. The time now is 07:24.