OpenFOAM-6

mirror of https://github.com/OpenFOAM/OpenFOAM-6.git synced 2025-12-08 06:57:46 +00:00

Files

Henry Weller fc2b2d0c05 OpenFOAM: Rationalized the naming of scalar limits

In early versions of OpenFOAM the scalar limits were simple macro replacements and the
names were capitalized to indicate this.  The scalar limits are now static
constants which is a huge improvement on the use of macros and for consistency
the names have been changed to camel-case to indicate this and improve
readability of the code:

    GREAT -> great
    ROOTGREAT -> rootGreat
    VGREAT -> vGreat
    ROOTVGREAT -> rootVGreat
    SMALL -> small
    ROOTSMALL -> rootSmall
    VSMALL -> vSmall
    ROOTVSMALL -> rootVSmall

The original capitalized are still currently supported but their use is
deprecated.

2018-01-25 09:46:37 +00:00

starcd

OpenFOAM: Rationalized the naming of scalar limits

2018-01-25 09:46:37 +00:00

calcPointCells.C

Further standardization of loop index naming: pointI -> pointi, patchI -> patchi

2016-05-18 21:20:42 +01:00

createPolyBoundary.C

Standardized cell, patch, face and processor loop index names

2016-04-25 12:00:53 +01:00

createPolyCells.C

Further standardization of loop index naming: pointI -> pointi, patchI -> patchi

2016-05-18 21:20:42 +01:00

meshReader.C

Parallel IO: New collated file format

2017-07-07 11:39:56 +01:00

meshReader.H

Updated member type comments

2016-11-28 21:23:00 +00:00

meshReaderAux.C

Parallel IO: New collated file format

2017-07-07 11:39:56 +01:00

README

Add the OpenFOAM source tree

2014-12-10 22:40:10 +00:00

README

With pro-STAR version v4, the input formats have changed radically.
  * Easier to parse space-delimited input formats
  * No arbitrary or integral couples
  * No trimmed or degenerate cells
  * Support for polyhedral cells
  * Boundaries are directly connected to cell and faces

Since the boundaries are now connected directly to the faces,
we now must be concerned with cell face notation otherwise we perform the
incorrect lookup.
Fortunately, there are only 4 primitive shapes to be concerned with.

Hexa:
   Foam                  pro-STAR
   ~~~~~~~~~~~~~~        ~~~~~~~~~~~
   Face 0 (0 4 7 3)  ->  F5: (0 4 7 3)
   Face 1 (1 2 6 5)  ->  F6: (1 2 6 5)
   Face 2 (0 1 5 4)  ->  F3: (0 1 5 4)
   Face 3 (3 7 6 2)  ->  F4: (2 3 7 6)
   Face 4 (0 3 2 1)  ->  F1: (0 3 2 1)
   Face 5 (4 5 6 7)  ->  F2: (4 5 6 7)


Prism:
   Foam                  pro-STAR
   ~~~~~~~~~~~~~~        ~~~~~~~~~~~
   Face 0 (0 2 1)    ->  F1: (0 2 1)
   Face 1 (3 4 5)    ->  F2: (3 4 5)
   Face 2 (0 3 5 2)  ->  F5: (0 3 5 2)
   Face 3 (1 2 5 4)  ->  F6: (1 2 5 4)
   Face 4 (0 1 4 3)  ->  F3: (0 1 4 3)


Tetra:
   Foam                  pro-STAR
   ~~~~~~~~~~~~~~        ~~~~~~~~~~~
   Face 0 (1 2 3)    ->  F6: (1 2 3)
   Face 1 (0 3 2)    ->  F5: (0 3 2)
   Face 2 (0 1 3)    ->  F3: (0 1 3)
   Face 3 (0 2 1)    ->  F1: (0 2 1)


Pyramid:
   Foam                  pro-STAR
   ~~~~~~~~~~~~~~        ~~~~~~~~~~~
   Face 0 (0 3 2 1)  ->  F1: (0 3 2 1)
   Face 1 (0 4 3)    ->  F5: (0 4 3)
   Face 2 (3 4 2)    ->  F4: (2 3 4)
   Face 3 (1 2 4)    ->  F6: (1 2 4)
   Face 4 (0 1 4)    ->  F3: (0 1 4)

Noting that several faces are skipped over in the pro-STAR definitions,
simply introducing a new cell modeller will be a problem.
Instead, subtract 1 from the pro-STAR faces and use lookup tables.


Here are the pro-STAR macro snippets used for creating the primitive cells:

! hexa
v 10 0 0 0
v 11 1 0 0
v 12 1 1 0
v 13 0 1 0
v 14 0 0 1
v 15 1 0 1
v 16 1 1 1
v 17 0 1 1
c hexa 10 11 12 13 14 15 16 17

! prism
v 20 0 0 0
v 21 1 0 0
v 22 1 1 0
v 23 0 0 1
v 24 1 0 1
v 25 1 1 1
c prism 20 21 22 23 24 25

! tet
v 30 0 0 0
v 31 1 0 0
v 32 1 1 0
v 33 0.75 0.75 1
c tetra 30 31 32 33

! pyramid
v 40 0 0 0
v 41 1 0 0
v 42 1 1 0
v 43 0 1 0
v 44 0.5 0.5 1
c pyra 40 41 42 43 44

! list faces
flist all