CFD Online Discussion Forums - [Technical] Negative labels in faceProcAddressing

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)

- - [Technical] Negative labels in faceProcAddressing (https://www.cfd-online.com/Forums/openfoam-meshing/85217-negative-labels-faceprocaddressing.html)

Negative labels in faceProcAddressing

Hi

I am working a bit with the procAddressing, because I have a submesh, which is generated inside the solver, so it has no *procAddressing files attached to it, which means I need to generate these prior to be able to use

reconstrucPar -region submesh

One question, however, is that in faceProcAddressing some of the labels are negative. These labels correspond to boundary labels on a procBoundary<N>to<M>. These negative labels, are they reflecting the fact that the corresponding boundary procBoundary<M>to<N> is the owner of the faces and the latter boundary is "neighbouring" those same faces?

Thanks

Niels

Hi Niels,

As a matter of fact, I have recently finished the parallel mesh+field reconstruction tool that works without addressing from decomposition - it is needed for parallelised topological changes. It unfortunately requires changes in the library, so it will come out with the next release.

As for negative labels, I have just been looking at that - have a look at decomposePar source code and search for "turning index" comments. This is one of mine, and the date (one of those deleted from the source code by Henry Weller and OpenCFD) is 5/Dec/2001. This is how it works:

- since the processor boundary represents the same internal face twice, we need to remember whether the face has been flipped or not. For a flipped face, the index is negative;
- however, the complete numbering needs to offset by one to account for flipping of face zero.
- take the sign: if it is negative, the face is flipped
- calculate mag(addressingIndex) - 1 and you will get the global face index.

Enjoy,

Hrv

Hi Hrv

Perfect! Thanks for that explanation, it solved one of my headaches in the faceProcAddressing, as I have completed a small matlab script which generates all the addressing on my submesh, but I could not understand why the indices where off by 1 and especially why index 0 where not their at all in any available faceProcAddressing.

BTW: Are you planning to give a summer school in Zagreb this year?

Thanks,

Niels

Good hunting, Niels.

Since you already have the global addressing indices and local-to-global mesh mapping, you can easily sort out the other ones.

The Summer School will happen in Zagreb as usual - the announcement is my "birthday present", so please wait for it for a few days.

Hrv

Okay, I will await the announcement patiently. Pre-congratulations :)

/ Niels

Guide: Reconstructing parallel processed runtime generated submeshes.

As seen above, the files {point,face,cell}ProcAddressing in connected to submeshes are not generated soforth the submesh is generated runtime. This means that as of present no tools are available to reconstruct the submesh. I have created a Matlab routine to generated these, and the guideline is as follows:

1. On the global (non-decomposed mesh), write the {point,face,cell}Maps, which can be obtained from fvMeshSubset.H.

2. Load these into your favourite language. I have used Matlab, so note that it start indexing on 1! The maps are called pm, fm and cm.

3. Loop over each processors. In these load the {point,face,cell}ProcAddressing for the decomposed mesh in processor*/constant/polyMesh. For both cells and points the method is straight forward. These ProcAddressings are called: ppa, fpa, cpa.

Code:

// Cell:

count = 0;

for j=1:length(cpa)

    I = find(cm == cpa(j))

    if ~isempty(I)

          count = count + 1; subcpa(count) = I - 1;

    end

end

subcpa = subcpa(1:count)



// Point:

count = 0;

for j=1:length(ppa)

    I = find(pm == ppa(j))

    if ~isempty(I)

          count = count + 1; subppa(count) = I - 1;

    end

end

subppa = subppa(1:count)

The method for faceProcAddressing is a bit more complex. Do as follows remembering that faceProcAddressing can be negative and is offset by 1. See Hrv's post above.

Code:

fpa = sign(fpa) .* ( abs(fpa) - 1);



for j=1:length(fpa)

    I = find(fm == abs(fpa(j)));

    

    if ~isempty(I)

        count = count + 1;

        if fpa(j) == 0 // sign(0) = 0, so not good ;)

            subfpa(count) = I;

        else

            subfpa(count) = sign(fpa(j)) * (I);

        end

    end

end

subfpa = subfpa(1:count);

This, however, is not sufficiently, as a submesh will typically have gotten some new boundaries, hence faces on the top level mesh being internal are now boundary face and they might appear some arbitrary place in subpfa. So:

a. Look in the boundary file for the non-decomposed submesh and locate the startFace for the problematic boundary (assuming only one such boundary in this description). Call this integer: nStart.

b. In the processor directory locate the number of faces, say N, following the problematic boundary. There will always be some, at least procBoundary<N>to<M> type boundaries.

c. Do the following index swapping in subfpa:

Code:

I             = find( subfpa >= nStart + 1); // Offset by 1!

bcs         = subfpa(I);

subfpa(I) = [];

subfpa    = [subfpa(1:end-N); bcs; subfpa(end-N+1:end)];

4. Write the {point,face,cell}ProcAddressing files to
processor*/constant/submeshName/polyMesh/.

I hope this can help someone.

Best regards,

Niels

Hrv,

Will the next release also include a parallel mesh+field decomposition tool?

Matt