changed flag which caused infinite while loop. Background info:
- findCellZoneTopo tries to find for all named surface intersections
which side of the face is in the faceZone
- i.e. it tries to make the cellZone consistent with the faceZone
(to fix small problems)
- this had some logic to assign the neighbour cellZone to the owner cellZone
- which didn't check for the neighbour being the same value as the owner
- but still set a 'changed' flag which caused the loop to never end.
- Place common code under OSspecific.
By including "endian.H", either one of WM_BIG_ENDIAN or WM_LITTLE_ENDIAN
will be defined.
Provides inline 32-bit and 64-bit byte swap routines that can be
used/re-used elsewhere.
The inplace memory swaps currently used by the VTK output are left for
the moment pending further cleanup of that code.
For example, to mesh a sphere with a single block the geometry is defined in the
blockMeshDict as a searchableSurface:
geometry
{
sphere
{
type searchableSphere;
centre (0 0 0);
radius 1;
}
}
The vertices, block topology and curved edges are defined in the usual
way, for example
v 0.5773502;
mv -0.5773502;
a 0.7071067;
ma -0.7071067;
vertices
(
($mv $mv $mv)
( $v $mv $mv)
( $v $v $mv)
($mv $v $mv)
($mv $mv $v)
( $v $mv $v)
( $v $v $v)
($mv $v $v)
);
blocks
(
hex (0 1 2 3 4 5 6 7) (10 10 10) simpleGrading (1 1 1)
);
edges
(
arc 0 1 (0 $ma $ma)
arc 2 3 (0 $a $ma)
arc 6 7 (0 $a $a)
arc 4 5 (0 $ma $a)
arc 0 3 ($ma 0 $ma)
arc 1 2 ($a 0 $ma)
arc 5 6 ($a 0 $a)
arc 4 7 ($ma 0 $a)
arc 0 4 ($ma $ma 0)
arc 1 5 ($a $ma 0)
arc 2 6 ($a $a 0)
arc 3 7 ($ma $a 0)
);
which will produce a mesh in which the block edges conform to the sphere
but the faces of the block lie somewhere between the original cube and
the spherical surface which is a consequence of the edge-based
transfinite interpolation.
Now the projection of the block faces to the geometry specified above
can also be specified:
faces
(
project (0 4 7 3) sphere
project (2 6 5 1) sphere
project (1 5 4 0) sphere
project (3 7 6 2) sphere
project (0 3 2 1) sphere
project (4 5 6 7) sphere
);
which produces a mesh that actually conforms to the sphere.
See OpenFOAM-dev/tutorials/mesh/blockMesh/sphere
This functionality is experimental and will undergo further development
and generalization in the future to support more complex surfaces,
feature edge specification and extraction etc. Please get involved if
you would like to see blockMesh become a more flexible block-structured
mesher.
Henry G. Weller, CFD Direct.
- Use ensightCase for case writing.
Rebase ensightPartCells/ensightPartFaces on
ensightCells/ensightFaces routines.
- Greatly reduces code duplication potential source of errors.
to handle the size of bubbles created by boiling. To be used in
conjunction with the alphatWallBoilingWallFunction boundary condition.
The IATE variant of the wallBoiling tutorial case is provided to
demonstrate the functionality:
tutorials/multiphase/reactingTwoPhaseEulerFoam/RAS/wallBoilingIATE
ENH: wallDist - added option to evaluate every XXX steps
Added functionality to update the wall distance every XXX steps
Note: only applies to movePoints() - topology change bypasses the update interval and triggers a re-calculation
Syntax:
```
wallDist
{
method ...
updateInterval 5; // optional - default is 1
}
```
Test case: [mixerVesselAMI2D.tgz](/uploads/c0bee1decc0337018272f3566b6a4416/mixerVesselAMI2D.tgz)
See merge request !62
Writing an empty list in binary results in unnecessary newlines that
make the output 'noisier'.
Old output
~~~~~~~~~~
ASCII
someEmptyList___0();
Binary
someEmptyList___
0
;
Updated
~~~~~~~
ASCII
someEmptyList___0();
Binary
someEmptyList___0;
All of the access methods for autoPtr include validity checks and will
fail if the underlying point is NULL. In some cases, however, we'd
like to retain the automatic deletion mechanism, but still address a
nullptr. This is mostly for cases in which a file-stream should be
allocated, but only on the master process. For these cases we'd still
like to pass through and reference the underlying pointer (eg, to
obtain the correct method call) without tripping the pointer check
mechanism. If we attempt to use the ptr() method, the autoPtr memory
management is bypassed and we risk memory leaks.
Instead provide an alternative mechanism to obtain the raw underlying
pointers/references. Use rawPtr() and rawRef() for these potentially
useful, but also potentially dangerous, operations.
This supports the abstraction of the set of fields from the field code
generation macros making it easier to change the set of fields supported
by OpenFOAM. This functionality is demonstrated in the updated
fvPatchFields macros and will be applied to the rest of the field code
generation macros in the future.
