[philippose]

Hello,

Good evening!

Had a quick question.... how can I get a list of the point labels which are associated with a given cell?

Basically, I would like to know which are the points used to construct cell "x". Not the co-ordinates of the points, but the indices into the points file.

With cellShape::points(pointField& p), I am able to get the co-ordinates...

Philippose

[hjasak]

mesh.cellPoints()[yourCellIndex]

Enjoy,

Hrv

[philippose]

Hey Hrv :-)!

A Good day to you (cant say the same about here... gloomy and raining!!)

Thanks a lot for that bit of information...! I was looking for something like this in the online DOxygen documentation, but I guess thats one search combination I missed out :-)!

Shall try it out once I am back home today!

Have a nice afternoon!

Philippose

[philippose]

Hello again,

And a good Saturday too :-)!

mesh.cellPoints()[cellIndex] worked out perfectly fine, but now I have a question....

I have the following scenario:

Scenario: The mesh to be dealt with in this application is known to be pure tetrahedral all the time.

Within a class, derived from the main class "fvMesh", I have the declarations:

const pointField& p = points();
const cellShapeList& cells = cellShapes();

And then I loop over each cell in the above list, with the normal:

forAll(cells,cellI)
{
...
...
...
}

Why is it, that the order of the points given out by OpenFOAM when I do the following, not the same in both cases? :

Case #1: I get the list of point indices of each cell in the list using:

const labelList& cellPts = cellPoints()[cellI]

I then extract the co-ordinates of the points from
the indices given, using:

p[cellPts[0]] ... p[cellPts[1]] ... p[cellPts[2]] ... p[cellPts[3]]


Case #2: I directly extract the co-ordinates of the points of each cell using:

pointField cellCoods = cells[cellI].points(p);

Now... if I list out these co-ordinates, though in each case they are referring to the same cells, the order of the points is not the same... here is a small excerpt from a mesh:

Cell Number: 0 cellPoints()[cellI] / cells[cellI].points(p)
1 => (-0.000934155 0.00717543 0.00075323) / (-0.000779351 0.00702664 0.000844531)
2 => (-0.000946054 0.00694285 0.000935769) / (-0.000946054 0.00694285 0.000935769)
3 => (-0.000955684 0.00713269 0.000964328) / (-0.000955684 0.00713269 0.000964328)
4 => (-0.000779351 0.00702664 0.000844531) / (-0.000934155 0.00717543 0.00075323)

Cell Number: 1 cellPoints()[cellI] / cells[cellI].points(p)
1 => (0.00103122 -0.00410962 0.0035804) / (0.00117277 -0.00503376 0.00316564)
2 => (0.00117277 -0.00503376 0.00316564) / (0.00103122 -0.00410962 0.0035804)
3 => (0.000399665 -0.00473561 0.0035637) / (0.000636406 -0.00429302 0.00311771)
4 => (0.000636406 -0.00429302 0.00311771) / (0.000399665 -0.00473561 0.0035637)

Cell Number: 2 cellPoints()[cellI] / cells[cellI].points(p)
1 => (0.00165181 0.00828201 -0.000808099) / (0.00162034 0.00814437 -0.000685601)
2 => (0.00181862 0.00810301 -0.00070875) / (0.00181862 0.00810301 -0.00070875)
3 => (0.00162034 0.00814437 -0.000685601) / (0.00165181 0.00828201 -0.000808099)
4 => (0.0017221 0.0082631 -0.000613056) / (0.0017221 0.0082631 -0.000613056)

As can be seen, for example in Cell Number 0, points 1 and 4 are swapped between the two lists... in cell Number 1, points 1 and 2, and points 3 and 4 are swapped, and in Cell Number 2, points 1 and 3 are swapped.

Is this difference there for a specific reason, or is it a bug in the OpenFOAM code? I am basically writing a small application to convert OpenFOAM meshes directly into the Netgen neutral format, and everything is working except for the fact that the ordering of the point indices don't seem to be right, and Netgen reports that most cells are wrongly oriented, so I was debugging my code when I chanced upon this apparent discrepancy.

Have a nice weekend!

Philippose

[hjasak]

Hehe, not that easy. The lists are constructed in different order because the thing is done in a different way.

In primitiveMesh, cellPoints are the transpose of the pointCell list. In a cell, you loop through faces in order and grab them as they come, skipping the duplicates. In both cases, you get the same set of points, so no bug.

Remember, there is NO GUARANTEE on the order of points for get - simply because a polyhedral cell does not have a defined shape. If you waht a guaranteed order to make a shape, you ask the mesh for its cellShapes and then process the shapes. The models for shapes are in /home/hjasak/.OpenFOAM-1.4.2/cellModels and should be self-explanatory. Remember, for a tru polyhedron there is no shape!!

Enjoy,

Hrv

[philippose]

Hi Hrv,

Thanks again for the information :-)! Switching from the OpenFOAM Polyhedral approach to the restricted cell shapes in use everywhere else, is like putting on a strait jacket :-)!

I shall look into the "cellModels" folder now, but I was able to solve my problem.... I dug into the Netgen source code, and found that it does a check on the imported tetrahedron mesh by calculating cell volumes using:

vol = (a x b).c (the usual tet volume formula I think)

where:
a = (node2 - node1)
b = (node3 - node1)
c = (node4 - node1)

and if (vol > 0), then the element is set as bad.

So what I do now, is to run this check internally during the export from OpenFOAM to Netgen format, and swap the node points so that this condition is met for all tet elements. As far as I have understood, a swap of nodes 1 and 4 should be sufficient for a sign change.

Things a working perfectly fine now... :-)! So, I have a standalone utility (like foamMeshToFluent), which converts OpenFOAM Tet meshes to Netgen Neutral format.

Here is the idea behind this entire exercise:
I was thinking... since Netgen already has mesh optimisation routines built into it targeted at tet meshes, why don't I run a moving mesh simulation in OpenFOAM, checking the Mesh Quality each time a mesh change occurs, and when the quality goes below a certain threshold, export the mesh to netgen, run the mesh optimisation routine, and import it back into OpenFOAM to continue with the simulation till the next quality problem.

Since Netgen can be used as a library rather than a standalone application, it should be possible to integrate this whole "export -> optimise -> import" cycle directly into an OpenFOAM top-level solver I think.... though I am not yet anywhere close to this level of functionality yet.

What do you think of the idea? Any better suggestions for the concept I am trying to implement?

I am really interested in this whole concept of mesh motion, as well as local refinement based on solution error, etc...etc.. but somehow everyone seems to have access to mesh generators capable of nice hexahedral cells, whereas I am working with pure tet meshes.

Have a nice weekend!

Philippose

[philippose]

Sorry... the usual equation for tetrahedral volume is:

Vol = -(1/6)*[(a x b).c]

Without the (1/6) it would be the volume of a hexahedron.

Philippose

[ankgupta8um]

Hi,

Does the list of point labels returned by the mesh.cellPoints()[CellIndex] satisfies the right-hand rule of giving an outward pointing vector ?
If not, is there an elegant way of obtaining the list of points for a cell that satisfies right-hand rule ?
Any response would be appreciated.
Regards,
Ankur

[mattijs]

Only the faces have orientation. First get faces of the cell and then the vertices of the face. (a face is a list of vertex labels oriented such that it is oriented out of the owner cell. See 6.1 in user guide)

const cell& cFaces = mesh.cells()[cellI];
forAll(cFaces, i)
{
const face& f = mesh.faces()[cFaces[i]];
}

[hjasak]

If you want an ordered set of vertices for a cell, ask for its shape and then the labels. Note that a tru polyhedral cell does not have a model (only hex and degenerate hex) and this method will not work for it.

Enjoy,

Hrv

[ankgupta8um]

Hi Hrv,

Thanks for the information.

I used cellShapes to get the ordered set of vertices and faces for the cells in a hex mesh. However, for different cells, the ordering is such that the local x,y,z directions are not consistent, i.e. the local x-min direction is different for different cells. Is there a way I can get a consistent x-min direction for all the cells ?

Thanks!
Regards,
Ankur

[suredross]

hello,
just a quick question.i would like to know how openFoam counts the cells in the mesh.as i understand now its from left to right??also does it finish with one patch before it moves on to the next?is it the same manner of counting for the cells on the boundary?i do need the answers for clarification purposes.

thank you
davey

[hjasak]

There is no defined order - cells come the way they are ordered in the cell list. In other words, it depends exclusively on the mesh generator.

If you are after reducing the matrix band, run renumberMesh. I have written it aaaaages ago but it does not see to be doing much for me...

Hrv

[suredross]

Hi Hrv,
thanks.so to be clear,blockmesh will start numbering from zero for a patch,up till the last cell in that patch and start from zero(or the last cell number from the previous patch)for the next patch.

davey

[hjasak]

Correct. The numbering will follow the local coordinate system of each block (x-, x-y, x-y-z).

Enjoy,

Hrv

[suredross]

Hi Hrv,
i still have issues especially concerning the count of boundary cells themselves?i have been trying to get my solver to read out the values of mesh cells onto the walls(2 different patches).for some reason the values being read out onto my 2 walls are from the same cell ids in the mesh which should not be the case.i am wondering,if u are a bit free,whether you can have a look at my case and solver for me-please.thanks for your earlier replies.
here is my solver:
jxnFoam.tar.gz

blockMesh
blockMeshDict.tar.gz

0 folder
0.tar.gz

it is a modified icoFoam case.

thanks

davey

[suredross]

Hi Hrv,
i managed to see my error.thanks for the help anyway.

cheers
davey