Ideally, I'd like to Glyph the fluxes at face centres. So, a glyph in the face-normal direction if the flux is positive, and vice-versa. That's basically what I'm looking for. Is this possible?

In that case, you could try out this workaround (which would only work for scalar surface fields): write out the face centroids as positions and the <scalar surface field> x the <face area vector> as vectors at these points.
This would equivalent to a Lagrangian field (cloud) and you could glyph that immediately.

This could be a convenient workaround for now, yes. I can't seem to find an example of constructing a cloud with position vectors (face-centres), though. Could you point me to the most relevant Lagrangian class?

Symmetric Tensor
 

Hi all

I may have found a bug in the native paraView reader. I'm using OpenFoam 1.6.x with the packaged ParaView (3.6) from the ThirdParty directory.

When I visualise data from R (the Reynolds stress tensor) I believe ParaView picks up the wrong components.
The order of the 6-component array (symmTensorField) is intepreted by PV as Rxx Ryy Rzz Rxy Rxz Ryz, while the correct order in OpenFoam is Rxx Rxy Rxz Ryy Ryz Rzz.

Please tell me if I'm wrong...
Cheers

Matteo

There are classes available in src/lagrangian/basic:

• IOPosition/
• passiveParticle/

However, the simplest would probably be to simply examine the output (eg, by tutorials/combustion/dieselFoam/aachenBomb) and forge the output files yourself.

Hi Matteo,
That's intended. The reader reorders the symmTensor components so that the order matches with the order shown in the selection combo box of the ParaView GUI.

Attachment 2387

Note that the component order is defined by the ParaView GUI so every reader has to follow the order (readers cannot change the order displayed in the component selection).

Takuya

Takuya, thanks for the quick reply.

However, my post wasn't too clear, I'm afraid.

What I mean is that the reordering you mention is not done properly (at least with my data). I'm not concerned with the order. If ParaView orders the components like in the image you posted, it's fine for me, as long as it picks up the right components of the original data.

For example: I'm trying to visualise the boundary conditions for the inlet patch, so I know the values in advance. And I know that R is something like this:

(<positive value> 0 <negative value> <positive value> 0 <positive value>)

This, in OpenFoam means: xx xy xz yy yz zz

When I try to visualise it with paraFoam, I see the correct values ONLY for xx. When i visualise yy i see all 0 values (like xy in the original data). When i visualise zz i see negative values (like xz in the original data) which is clearly wrong, since Rzz can't be negative. An so on...

So, I think the bug is in the fact that the reordering you mention is not performed at all.

I hope it is clearer now :)

Thanks for your help
Matteo

Matteo,
paraFoam?? Sorry but I'm confused. To clarify, which reader are you talking about (PV3FoamReader or vtkPOpenFOAMReader)? The reader I'm talking about (and am responsible for) is vtkPOpenFOAMReader, which has nothing to do with the paraFoam script.

Takuya

.....OK.... forget it... I posted in the wrong thread.
I'm indeed talking about the PV3FoamReader... I'm sorry if you wasted time after my problem...

I'm going to post it in the right thread.

Hi Takuya,

Apart from using inspection of the paraview GUI, is there any documentation about how 6-component data are interpreted? Presumably the component ordering should be VTK and not paraview-specific. The only thing I've seen in VTK is vtkTensor which seems to be 9-component, but haven't seen anything about the interpretation of generic n-Tuple datasets.
Is this a new fix in your reader or did something change in VTK? I noticed that the corresponding code is conditionally enabled: /mark

Hi Mark,
No, I am not aware of any concrete documentation about this. The date stamp in the reader source code corresponds to a change to ParaView3/Qt/Core/pqScalarBarRepresentation.cxx, where the component labels are hard-coded.
----------------------------
revision 1.7
date: 2008-06-27 21:30:35 +0900; author: utkarsh; state: Exp; lines: +26 -10;
commitid: PAb32eXp878ziA8t;
ENH: Fixed BUG #5979. 6 component vectors are now labelled as
[XX, YY, ZZ, XY, XZ, YZ]. The color component chooser as well the calculator use this convention while naming components.
----------------------------
The reason why the date is off a week (20080620 vs. 2008-06-27) has totally slipped out of my memory though - it's 1.5 years ago. Before the change IIRC the components were labelled with numbers (0, 1, ... 5).

If we visit the bug #5979 in the tracker, we find that the component labels were named along with a particular file format (Exodus).

Feel free to reopen the issue at the paraview or vtk-developers list if you'd like :)

Takuya

Hi Takuya,

Thanks for the info. It's too bad that it is otherwise a bit difficult to find in paraview/vtk.
For a micro-optimization of your reader code, you can reduce the number of operations a little:
BTW: now that your reader is in the standard VTK repo, have you thought again about dropping the old ListTimeStepsByControlDict functionality? I don't know where it would ever be better than the discovery by directory method.

Hi,
Just wanted to drop notes about the current status of the reader.

1. ParaView 3.8, which includes a version of the reader, has just been released and is available for download from the ParaView website. The specifics of the reader is summarized in post #190 of this thread.
2. A talented guy at Kitware recently added experimental native support for polyhedral cells (vtkPolyhedron) to the Git heads of ParaView and VTK. Also, the reader in the Git heads already has support for the new cell type (which is my contribution). You can play with the feature by unchecking the "Decompose Polyhedra" at the bottom of the reader panel: Attachment 3562. Keep in mind that it is still an experimental feature. There are indeed many filters that do not work with this new cell type, particularly those that use cell locator, e.g. Stream Tracer, Plot over Line. Still yet it is cool - below is a screenshot of the iglooWithFridges tutorial case clipped with Extract Cells By Region. I hope it is good enough to demonstrate how cool the new feature is :)
   Attachment 3563 (vtkPolyhedron: the new feature, Decomposed polyhedra: what we have long been used to seeing)

Takuya

Paraview-3.8 reading time problem
 

Hi Takuya,

I've used version 173 through pvFoam for a long time. Everything works fine. Thanks for your great jobs, again! :D

I just installed P-3.8 to test both paraview and the new integrated reader.

I have a case with integer time steps, from 0 to 1100 (for simpleFoam), and after that fractional time steps, 1100 to 1100.5 (for icoFoam). When I used pvFoam (v173) there wasn't any complain. So, I used this case to test the integrated reader in P-3.8.

First I created a dummy file
Then I open this file with P-3.8 and the folowing issue arises several times
Any idea? Is this the right place to ask or Should I ask at paraview's blogs?

Regards

Pablo

Hi Pablo,
That is one of the problems whose workaround missed to go into PV 3.8, which also is a variant of the infamous setlocale problem. As a solution, try "export LC_ALL=C" before running ParaView. I personally believe this should ultimately be fixed in ParaView itself so once bugged it at the PV-list, to no avail :(

Yes, for the moment, this and the PV-list are both the right places.

Takuya

Adding export LC_ALL=C to pvFoam
 

Takuya, maybe I can use the pvFoam script and add this setting there, and pointing to paraview-3.8. Say pvFoam-3.8 :D

I'll modify it tomorrow, at work.

Thank you!

Pablo

pvFoam-3.8 working!
 

Hi Takuya, everything is working fine now. I added the "export ..." line and changed the paraviewPath to point to the correct paraview in pvFoam. Then I renamed to pvFoam-3.8.

Thanks for your help.

Regards

Pablo

Thanks for the report, Pablo.

Coincidentally, another push to the PV developers finally had the fix to the setlocale problem of PV itself go into the Git head of PV 3.9 (just now!) :)

Takuya

Takuya I want to test pv-3.9 but I can't. If I'm successful I'll implement this at work. So, I prefer to stay in version 3.8 with the workaround. I think it's the safe option.

Regards, and thank you for your help

Pablo

That's totally OK - just wanted to let all know.

T