ENH: Updated header documentation

This commit is contained in:
andy
2013-04-04 12:18:43 +01:00
parent a0c52565de
commit f66f9e9d37
3 changed files with 53 additions and 16 deletions

View File

@ -28,6 +28,19 @@ Description
Application to generate the patch geometry (points and faces) for use Application to generate the patch geometry (points and faces) for use
with the externalCoupled boundary condition. with the externalCoupled boundary condition.
Usage:
createExternalCoupledPatchGeometry <fieldName>
On execution, the field <fieldName> is read, and its boundary conditions
interrogated for the presence of an \c externalCoupled type. If found,
the patch geometry (points and faces) for the coupled patches are output
to the communications folder.
Note:
The addressing is patch-local, i.e. point indices for each patch point
used for face addressing starts at index 0.
SeeAlso SeeAlso
externalCoupledMixedFvPatchField externalCoupledMixedFvPatchField

View File

@ -32,34 +32,46 @@ Description
Values are transferred as plain text files, where OperFOAM data is written Values are transferred as plain text files, where OperFOAM data is written
as: as:
<value1> <surfaceNormalGradient1> # Patch: <patch name>
<value2> <surfaceNormalGradient2> <magSf1> <value1> <surfaceNormalGradient1>
<value3> <surfaceNormalGradient3> <magSf2> <value2> <surfaceNormalGradient2>
<magSf3> <value3> <surfaceNormalGradient3>
... ...
<valueN> <surfaceNormalGradientN> <magSfN> <valueN> <surfaceNormalGradientN>
and received as the constituent pieces of the `mixed' condition, i.e. and received as the constituent pieces of the `mixed' condition, i.e.
# Patch: <patch name>
<value1> <gradient1> <valueFracion1> <value1> <gradient1> <valueFracion1>
<value2> <gradient2> <valueFracion2> <value2> <gradient2> <valueFracion2>
<value3> <gradient3> <valueFracion3> <value3> <gradient3> <valueFracion3>
... ...
<valueN> <gradientN> <valueFracionN> <valueN> <gradientN> <valueFracionN>
At start-up, the boundary creates a lock file, e.g. Data is either sent/received as one file per patch, or as a single file
for all patches, based on the \c collate flag. In the former case, the
folder used for communications is:
$FOAM_CASE/comms/patchName/OpenFOAM.lock $FOAM_CASE/<commsDir>/patchName
and when using the \c collate option:
$FOAM_CASE/<commsDir>
At start-up, the boundary creates a lock file, i.e..
OpenFOAM.lock
... to signal the external source to wait. During the boundary condition ... to signal the external source to wait. During the boundary condition
update, boundary values are written to file, e.g. update, boundary values are written to file, e.g.
$FOAM_CASE/comms/patchName/data.out <fileName>.out
The lock file is then removed, instructing the external source to take The lock file is then removed, instructing the external source to take
control of the program execution. When ready, the external program control of the program execution. When ready, the external program
should create the return values, e.g. to file should create the return values, e.g. to file
$FOAM_CASE/comms/patchName/data.in <fileName>.in
... and then re-instate the lock file. The boundary condition will then ... and then re-instate the lock file. The boundary condition will then
read the return values, and pass program execution back to OpenFOAM. read the return values, and pass program execution back to OpenFOAM.

View File

@ -32,34 +32,46 @@ Description
application. Values are transferred as plain text files, where OperFOAM application. Values are transferred as plain text files, where OperFOAM
data is written as: data is written as:
<value1> <surfaceNormalGradient1> # Patch: <patch name>
<value2> <surfaceNormalGradient2> <magSf1> <value1> <qDot1> <htc1>
<value3> <surfaceNormalGradient3> <magSf2> <value2> <qDot2> <htc2>
<magSf3> <value3> <qDot3> <htc2>
... ...
<valueN> <surfaceNormalGradientN> <magSfN> <valueN> <qDotN> <htcN>
and received as the constituent pieces of the `mixed' condition, i.e. and received as the constituent pieces of the `mixed' condition, i.e.
# Patch: <patch name>
<value1> <gradient1> <valueFracion1> <value1> <gradient1> <valueFracion1>
<value2> <gradient2> <valueFracion2> <value2> <gradient2> <valueFracion2>
<value3> <gradient3> <valueFracion3> <value3> <gradient3> <valueFracion3>
... ...
<valueN> <gradientN> <valueFracionN> <valueN> <gradientN> <valueFracionN>
At start-up, the boundary creates a lock file, e.g. Data is either sent/received as one file per patch, or as a single file
for all patches, based on the \c collate flag. In the former case, the
folder used for communications is:
$FOAM_CASE/comms/patchName/OpenFOAM.lock $FOAM_CASE/<commsDir>/patchName
and when using the \c collate option:
$FOAM_CASE/<commsDir>
At start-up, the boundary creates a lock file, i.e..
OpenFOAM.lock
... to signal the external source to wait. During the boundary condition ... to signal the external source to wait. During the boundary condition
update, boundary values are written to file, e.g. update, boundary values are written to file, e.g.
$FOAM_CASE/comms/patchName/data.out <fileName>.out
The lock file is then removed, instructing the external source to take The lock file is then removed, instructing the external source to take
control of the program execution. When ready, the external program control of the program execution. When ready, the external program
should create the return values, e.g. to file should create the return values, e.g. to file
$FOAM_CASE/comms/patchName/data.in <fileName>.in
... and then re-instate the lock file. The boundary condition will then ... and then re-instate the lock file. The boundary condition will then
read the return values, and pass program execution back to OpenFOAM. read the return values, and pass program execution back to OpenFOAM.