[deepsterblue]

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.

[7islands]

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

[deepsterblue]

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();
}

[7islands]

Originally Posted by deepsterblue

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.

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

[deepblue17]

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

[7islands]

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

[deepblue17]

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.

[bastil]

Originally Posted by deepblue17

Case Type: Decomposed Case (Appended)

and the second one:

Case Type: Decomposed Case (Multiblock)

What is the difference between those two options, please?

[deepblue17]

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.

[7islands]

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.

Originally Posted by deepblue17

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.

- 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]

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

[deepblue17]

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

[7islands]

Originally Posted by deepblue17

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

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.

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

[deepblue17]

Originally Posted by 7islands

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.

[7islands]

Originally Posted by deepblue17

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.

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

[pcaron]

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

[7islands]

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]

Oliver,

Originally Posted by deepblue17

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

[deepblue17]

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:

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.

[wyldckat]

Hi Oliver,

Originally Posted by deepblue17

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