[doug]

I have my own mesh generator written in Fortran. I'd like to write my own mesh files for OpenFOAM rather than reading the mesh into Fluent, and then converting the Fluent mesh into the OpenFOAM mesh. I'm looking for instructions on writing my own mesh files from my own fortran program. What I understand so far is that I need to create fives files: boundary, faces, neighbour, owner, and points. Any direction would be helpful.

[jcriner]

Doug,

Though I am relatively new to OpenFoam, I have recently done the same thing (my fortran grid generators now write OpenFoam). I'm learning C++ on the fly, but I couldn't leave my Fortran codes behind. It took a bit of work, but by digging through the documentation, forums, and examining the test case grid files (for syntax) you should be able to decipher all you need. My stuff seems to be working just fine now, though you might defer to a comments from a more experienced OpenFoamer. I'm not sure if your grids start as structured hex or unstructured, but either way some keys to look out for:

1. points = a list of all the point coordinates. Each point should only be listed once.

2. faces = foreach face, the point labels that make up the face. point labeling starts at 0. order matters... for interior faces, the normal (rhr) should point in to the cell sharing the face that has the higher cell number. for boundary faces the normal should point out of the domain. For quad, 4(p0 p1 p2 p3). For tri 3(p0 p1 p2), and so on. Face list ordering is also important. It needs to be upper triangular and also the boundary face sets need to be consecutive at the end. To quote Mattijs, "Simply said upper-triangular order is that the order of faces corresponds to the order of the cells they connect.
- take all (higher numbered) cells connected to a cell.
- sort them according to their cell label
- the faces connecting to those cells should now also be ordered.

renumberMesh will do this for you.

3. neighbour, owner = for each face from the properly ordered faces file, the cell label (starting from 0) that is the owner of the face and neighbour of the face repsectively. owner is the lower cell label, neighbour is the higher cell label (normal points in to). All of the boundary faces at the end of the file will have a neighbour of -1.

4. boundary = foreach boundary the name, type, physical type, starting face label and number of faces. check the boundary file in the test cases to get a feel for the syntax and type / physical type.

5. the files above should be located in root/case/constant/polyMesh. my grid generators create the directory and write the files. you will also need a root/case/system directory with controlDict and maybe the fvSchemes and fvSolution in order for checkMesh and paraFoam to work. I just copy these over from an existing case.

6. I would always use "checkMesh root case" initially to be sure your format is correct as it will detect face ordering issues and geometric issues as well. Then view it in paraFoam.

7. The only thing left is to make sure that the field files in 0 have boundary information that corresponds to the boundary type / physical type / name that you have just written in root/case/constant/polyMesh/boundary. You can do this either using FoamX (which will create time 0 after you select the boundary conditions and save) or manually with copy / paste / editor.

Though a little rough around the edges, I hope this info gives you some direction.

James

[doug]

Thank you so much. That's a great start. I've been trying to track down some info on creating directories via Fortran as well. Sounds like you have that figured out too. Any suggestions on that would be helpful. I'm running g95 and gfortran. Thanks.

-Doug

[olesen]

Hi Doug,

Being lazy, I personally would not target the OpenFOAM formats directly, but rather target another format (fluent, star-cd, etc) and let the corresponding converter do the nasty work for you.

I have some experience in reading/writing Star-CD formats, which seem to provide a reasonable combination of simplicity and element types. They are ASCII and can represent all primitive cell shapes and polyhedral. Take a took at the star4ToFoam and/or the foamMeshToStar converters that I posted here a while ago.

I also toyed with inventing an OpenFOAM meta-mesh format that would be easier to target. The format would use cellShapes or faceLists instead, with support for cellZones.
I wrote a simple foamMeshToMeta writer as proof of concept, but didn't bother with creating the corresponding reader since I don't know if there is a real need for yet another format.

If there is a real interest in such a format however, there still remains the usual restrictions of continguous point ids, contiguous cells within cellZones and point ids starting with 0. All of which may place an inordinate burden on the generator.

[hjasak]

If you look at the mesh class constructors, you will find the one that takes cell shapes and boundary faces:


//- Construct from cell shapes
polyMesh
(
const IOobject& io,
const pointField& points,
const cellShapeList& shapes,
const faceListList& boundaryFaces,
const wordList& boundaryPatchNames,
const wordList& boundaryPatchTypes,
const word& defaultBoundaryPatchType,
const wordList& boundaryPatchPhysicalTypes
);

Also, there is another one, using points, faces (face = list of point labels) and cells (cell = list of face labels):


//- Construct from components without boundary.
// Boundary is added using addPatches() member function
polyMesh
(
const IOobject& io,
const pointField& points,
const faceList& faces,
const cellList& cells
);

Here, you need to worry about the ordering of the face list, but I have already described that in the forum in detail.

In other words, the job is alreadt done for you.

Hrv

[olesen]

Hi Hrv,

Just for clarification. Can this actually work with poly cells? As far as I can see, the cellShape depends on the cellModel, which would presumably be "unknown" for a general poly and cannot deliver the mesh faces required.
What did I miss?

/mark

[hjasak]

Depends which one you mean:

Definition with cell shapes: Of course not. You mesh is either defined by known cell shapes or it is general polyhedral. Thus, a cell shape definition only accepts shaped cells, right?

Definition with cells: As I said (and wrote the code ), a cell is defined as a list of faces. It does not say how many faces or how many vertices in the face - this is a proper polyhedral definition. You will, of course, be checked that the cell is a valid one, i.e. faces match and close the volume + all other relevant checks of mesh consistency and quality.

Clear?

Hrv

[doug]

James-

Could you give me some pointers on creating directory structures using fortran? I've searched on the internet and am struggling to locate any guidance.

Thanks.

-Doug

[lam]

Hi all,

I notice that everybody talk about
the directories:
-faces,
-boudary,
-points,
-and cells
to define a mesh in Foam

But I DO NOT have a directory which is created when I do, for example:
"blockMesh $FOAM_RUN/tutorials/icoFoam cavity"
when I do this command, I have:
faces, boudary,points, neighbour, owner, whch are creted!
But there is not the directory "cells"!

Is it normal?

Lam

[rafal]

Hi Lam,

you have all of those files in:
/path/to/cavity/constant/polyMesh

are you sure you have read userguide?
if yes, please read it once again.
this will spare you lots of frustration.
understanding userguide and programmers guide is the fastest way to get into OFoam. Faster than Message Board.
Try to browse also see all files in the case dir. OF is free and OPEN (you can see all
tricks, isnt it the reason that you started
adventure with OF), unlike case files of other
CFD soft.

rafal

[rafal]

By the way cells (to answer explicitly)
is a list of faces in arbitrary order and
created by polymesh based points, faces
and on all the the connectivity informations
(owners, neighbours). keep browsing
rafal

[eugene]

From OF1.2 (iirc) blockMesh and the various converters no longer produces the cells file. The owner/neighbour files contain all the information previously stored in the cells file and do so more compactly.

However, a case without the owner/neighbour files but with a cells file will still run. I.e. the owner /neighbour format is backward compatible with the cells format.

For the contents and format of the owner/neighbour files see the manuals and this forum.

[lam]

RAfal, I've read many times User's guide. (and I know that thoses files are in /cavity/constant/polyMesh as you said),
But now, thanks to Eugen, it's clear: OpenFOam doesn't produce cells fils anymore!
I think that it is NOT mentioned in any guides, isn't it?

Cheers,

Lam

[rafal]

Hi Lam. I sorry if you took my comment wrong.
my hard copy documentation is 1.2, but i had
also swift read through 1.3 when it was released
back last year. and i had impression i read
about this there, but it must have been in
release notes of 1.3. No offense.
rafal

[jcriner]

Doug,

It all depends on the compiler features and OS. Many compilers have advanced fortran string functions such as trim() as well as system calls. With sincere apologies to all C++ people (and advanced Fortan people as well), below is seriously crude way to make directories in fortran using just about any compiler on a linux box. I'll leave it to you to figure out what is going on and how to make it suit your needs.

character(len=256) froot,fpath,mpath

call getenv("PWD",froot)
fpath=(froot(1:index(froot,' ')-1)//'/constant/polyMesh')
mpath=('mkdir -p '//fpath(1:index(fpath,' ')-1))

write(*,*) froot(1:index(froot,' ')-1)
write(*,*) fpath(1:index(fpath,' ')-1)
write(*,*) mpath(1:index(mpath,' ')-1)

call system(mpath)

James

[jcriner]

And before anyone asks, the forum post mechanism does not take kindly to two consecutive spaces and apparently strips it down to one. The last "index" function for mpath in the write statement should be searching for two consecutive spaces as mpath has single spaces in it "mkdir -p stuff".

James

[doug]

Hi all-

Thanks for the help I've received so far. I'm having trouble when I check my mesh. I think I have my mesh faces ordered correctly, but I'm still getting upper-triangular errors. Can anyone be more specific on what upper-triangular really means? I realize that:
To quote Mattijs, "Simply said upper-triangular order is that the order of faces corresponds to the order of the cells they connect.
- take all (higher numbered) cells connected to a cell.
- sort them according to their cell label
- the faces connecting to those cells should now also be ordered.

Thanks for your help.

-Doug

[olesen]

Hi Doug,

The renumberMesh source should give you the necessary information about what to do.

/mark

[deinstein]

Hello,

I am putting together OF output for our unstructured mesh generator, which will hopefully be publicly available soon. For what its worth, the algorithms were designed for high-quality, scale-invariant tetrahedral grids of complex biological structures. With any luck our JCP paper will be out soon.

The stupid questions:

1) the Polymesh headers
FoamFile
{
version 2.0;
format ascii;

seem to imply that it is possible to write binary versions (if not why the ascii?). Is there standard bit encoding? In the binary version is the header in ascii and the rest binary? Some clues to writing binary Polymesh would be most welcome.

2) The examples I have seen for writing boundary files in OF all have external boundary faces arranged consecutively in the faces file, e.g.

startFace 1160229;
nFaces 17222;

Clearly, it must be possible to simply list the faces. In that case, do I simply skip the startFace, keep the nfaces and follow it with an explicit list of boundary faces?

Kind Regards,
Dan

[mattijs]

http://openfoamwiki.net/index.php/Write_OpenFOAM_meshes