[bastil]

Dear all,

I have a case where I want to ensure that the faces linked to four patches are one the same cpu. I think:

preservePatches (patch1 patch2 patch3 patch4);

in decomposePar should do the trick.I guess this this makes all four patches to be completely one the same cpu.

I tried to postprocess this by looking into the meshes in processor* using pvFoam from the external Paraview-Reader. If I do so I can not realize that all patches are on the same cpu but even one single patch is separated onto different CPUs. Is this a problem of pvFoam or a wrong distribution?
I remember checking it that way worked but I am not sure if it was paraFoam or pvFoam. How could I check the distribution?
I also ran the mixerGGI-Tutorial decomposed on 4CPUs and this has a "globalFaceZones" keyword which should make two zones be present on all four CPUs but my postprocessing does not show this, too.

[7islands]

I am not sure if I understand your problem correctly so I hope the following makes sense:
- Try reading the suspicious processor subdirectory individually (create e.g. processor0.foam under "processor0" subdirectory and open it) and compare the visualization with the whole case
- If the patch face distributions don't match there may be a bug in the reader
- Give me more details, at least the version of the reader, how you checked the processor distribution (there are several ways to do this) and a screenshot or two comprehensively demonstrating your problem

Takuya

[bastil]

Originally Posted by 7islands

- Try reading the suspicious processor subdirectory individually (create e.g. processor0.foam under "processor0" subdirectory and open it) and compare the visualization with the whole case

That's exactly what I am doing. I see that setting "preserveFaceZones" and "globalFaceZones" in decompseParDict of mixerGGI (1.5-dev) does not make any of the meshes in processor0...processor3 looking different from what I get when decomposing without any option. The "preserved" or "global" faces are distributed over CPUs and not present on all the CPUs.

- how you checked the processor distribution (there are several ways to do this)

That is my main question: How can I check processor distribuition. I tried to do it with the visual method mentioned above but all three decomposition methods (with preserveFaceZones, with globalFaceZones, and without anything) look the same. The output (numer of cells,...) reported by decomposePar also looks the same. However as soon as I try to run the tutorial it only works if the mesh was decomposed with "globalFaceZones" turned on - so there must be a difference in the distribution.

Regards Bastian

[7islands]

Originally Posted by bastil

That's exactly what I am doing. I see that setting "preserveFaceZones" and "globalFaceZones" in decompseParDict of mixerGGI (1.5-dev) does not make any of the meshes in processor0...processor3 looking different from what I get when decomposing without any option. The "preserved" or "global" faces are distributed over CPUs and not present on all the CPUs.

Ok it's now a bit clearer to me. If I read processor0 ... processor3 of the decomposed mixerGgi with the Read Zones option turned on I can see the circular outsideZone and insideZone present in all processor*. Maybe you forgot to turn the option on? For example processor0 should look like this
mixerGgiProcessor0.png
where the circular surface is the global face zones.

Originally Posted by bastil

That is my main question: How can I check processor distribuition.

The easiest and most convenient way I can think of is to read the whole case with the Decomposed Case (Multiblock) mode which is available only in the SVN version of the reader and colorize with vtkCompositeIndex or run Filters->Extract Block or Filters->Block Scalars or whatnot.

Takuya

[bastil]

Originally Posted by 7islands

Maybe you forgot to turn the option on?

My 100 Points go to Takuya - thanks that's it. However, I don't really understand why these faces are only included in the "faceZones" but not in the faces of each processor itself...?

The easiest and most convenient way I can think of is to read the whole case with the Decomposed Case (Multiblock) mode which is available only in the SVN version of the reader and colorize with vtkCompositeIndex or run Filters->Extract Block or Filters->Block Scalars or whatnot.

Thanks once more.

[7islands]

Originally Posted by bastil

However, I don't really understand why these faces are only included in the "faceZones" but not in the faces of each processor itself...?

Right, faces that do not belong to cells are ignored for several reasons (they may confuse downstream filters and sometimes users, they have no vol-fields to assign field values, etc). There once was a feature request to add an option to specifically display faces and face-fields but I'm too lazy to work on it

T

[deepsterblue]

Takuya,
I noticed your reference to my message I would like to re-iterate my request for face-field display (particularly for face fluxes, like phi). I'd like to be able to Glyph them based on magnitude / direction, preferably. Does this indeed require a lot of reader re-write?
I could do the lagrangian post-process as a work-around, I suppose, but I'd like to avoid reading-in VTK's at each time-step

[7islands]

No I don't think so, full two or three days (and one or two extra full days for testing) should be enough. It's matters of the priority of the feature request and time which I can spare for this project.

Looking at your website you seem to be a skilled developer so if you do this by yourself I'd be more than happy to accept your contribution

T

[deepsterblue]

Takuya,
I might be able to take a look. Could you point me to the relevant part of the source, so that I can get started? Should I be working on the current SVN stuff with Paraview-3.8.0?
It also looks like there's some confusion about the compatibility of the reader with different Paraview releases. I've been using 3.6.1 till now, and later releases of Paraview seem to be unsupported (?) when used with the reader, etc... A little background might be nice. As a minor fix, I would suggest that your SVN repository also be categorized based on Paraview release revision.

[deepsterblue]

Nevermind... Figured it out.

For those interested, the reader with surfaceField support is given in this thread:
http://www.cfd-online.com/Forums/ope...tml#post274905