- The code create a box with a (0,0,0) point.
The new definition is more logical and makes it very easy to grow
the bounding box to include new points. It also simplifies much of
the logic in the constructors.
- Use ROOTVGREAT instead of VGREAT for sizing greatBox and invertedBox.
Avoids some overflow issues reported by Mattijs (thus GREAT has been
used in treeBoundBox), but might still need further revision.
- Constructor for bounding box of a single point.
- add(boundBox), add(point) ...
-> Extend box to enclose the second box or point(s).
Eg,
bb.add(pt);
vs.
bb.min() = Foam::min(bb.min(), pt);
bb.max() = Foam::max(bb.max(), pt);
Also works with other bounding boxes.
Eg,
bb.add(bb2);
// OR
bb += bb2;
vs.
bb.min() = Foam::min(bb.min(), bb2.min());
bb.max() = Foam::max(bb.max(), bb2.max());
'+=' operator allows the reduction to be used in parallel
gather/scatter operations.
A global '+' operator is not currently needed.
Note: may be useful in the future to have a 'clear()' method
that resets to a zero-sized (inverted) box.
STYLE: make many bounding box constructors explicit
reduce()
- parallel reduction of min/max values.
Reduces coding for the callers.
Eg,
bb.reduce();
instead of the previous method:
reduce(bb.min(), minOp<point>());
reduce(bb.max(), maxOp<point>());
STYLE:
- use initializer list for creating static content
- use point::min/point::max when defining standard boxes
- Could be related to interrupted builds.
So if there are any parts of the build that rely on an explicit
'wmakeLnInclude', make sure that the contents are properly updated.
--
ENH: improved feedback from top-level Allwmake
- Report which section (libraries, applications) is being built.
- Provide final summary of date, version, etc, which can be helpful
for later diagnosis or record keeping.
- The -log=XXX option for Allwmake now accepts a directory name
and automatically appends an appropriate log name.
Eg,
./Allwmake -log=logs/ ->> logs/log.linux64GccDPInt32Opt
The default name is built from the value of WM_OPTIONS.
--
BUG: shell not exiting properly in combination with -log option
- the use of 'tee' causes the shell to hang around.
Added an explicit exit to catch this.
--
- Detecting the '-k' (-non-stop) option at the top-level Allwmake, which
may improve robustness.
- Explicit continue-on-error for foamyMesh (as optional component)
- unify format of script messages for better readability
COMP: reduce warnings when building Pstream (old-style casts in openmpi)
- polyMesh constructor from cell shapes invoked 'removeFiles'.
This may or may not be what the caller wants or expects.
With the ParaView blockMesh viewer, this behaviour causes deletion of
all mesh data (points, faces, etc) when the viewer is refreshed.
Triggered even when just building the blockMesh topology.
- only a few places that construct a polyMesh from cell shapes
(mostly mesh conversion utilities).
Ensure that the file removal (if any) occurs in the application
and *not* as a side-effect of calling the polyMesh constructor.
--
blockMesh (application)
- The placement of the removeFiles seems to also remove freshly
generated sets (Bug or feature to remove sets?)
+-----------------------+---------------+------------------+
| Application | Constructor | removeFiles |
| | (patch info) | new / existing |
+-----------------------+---------------+------------------+
| blockMesh | dictionary | existing |
| ansysToFoam | names | new |
| cfx4ToFoam | dictionary | new |
| fluentMeshToFoam | names | new |
| gambitToFoam | dictionary | new |
| gmshToFoam | names | new |
| ideasUnvToFoam | names | new |
| kivaToFoam | dictionary | new |
| mshToFoam | names | new |
| netgenNeutralToFoam | names | new |
| plot3dToFoam | names | new |
| tetgenToFoam | names | new |
| vtkUnstructuredToFoam | names | new |
+-----------------------+---------------+------------------+
Pstream: added maxCommsSize setting to do (unstructured) parallel transfers in blocks.
Tested:
- with maxCommsSize 0 produces exactly same result as plus.develop
- compiles with label64
- with maxCommsSize e.g. 3 produces exactly same result as plus.develop
- with maxCommsSize=0 exactly the same messages (with Pstream::debug = 1) as plus.develop
See merge request !85
cellZones and pointZones can now be created in one action without the
need to first create a cellSet or pointSet and converting that to the
corresponding zone, e.g.
actions
(
// Example: create cellZone from a box region
{
name c0;
type cellZoneSet;
action new;
source boxToCell;
sourceInfo
{
box (0.04 0 0)(0.06 100 100);
}
}
);
- only occurs in combination with distributedTriSurfaceMesh in snappy.
- workaround similar to that previously used for surfaceRedistributePar
(issue #60).
Minor adjustment of incompressible motorBike tutorial to detect use of
distributedTriSurfaceMesh.
- there was a slight mix of MUST_READ and MUST_READ_IF_MODIFIED
but with no obvious code to handle runtime modified values
of the decomposition, or how this works with alternative
dictionaries.
On 64-bit systems, the system installations of boost, cgal are under
lib64/. The behaviour for a ThirdParty build is mostly lib/ but this
can also be changing.
Boost 1_62_0 and older build into 'lib/'.
CGAL-4.9 builds into 'lib64/', older versions into 'lib/'.
Future-proof things by using lib$WM_COMPILER_LIB_ARCH for boost and
cgal build rules, and forcing these as build targets in the ThirdParty
makeCGAL as well.
--
STYLE: check for boost/version.hpp, CGAL/version.h instead their directories
- Cleanup/centralize handling of -decomposeParDict by relocating
common code into argList. Ensures that all processes receive
identical information about the -decomposeParDict opton.
- Only use alternative decomposeParDict for simpleFoam/motorBike
tutorial so that this will be included in the test loop for snappy.
- Added Mattijs' fix for surfaceRedistributePar.
- 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.
blockMesh -help
Usage: blockMesh [OPTIONS]
options:
-blockTopology write block edges and centres as .obj files
-case <dir> specify alternate case directory, default is the cwd
-dict <file> specify alternative dictionary for the blockMesh description
-noFunctionObjects
do not execute functionObjects
-region <name> specify alternative mesh region
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
Block description
For a given block, the correspondence between the ordering of
vertex labels and face labels is shown below.
For vertex numbering in the sequence 0 to 7 (block, centre):
faces 0 (f0) and 1 are left and right, respectively;
faces 2 and 3 are bottom and top;
and faces 4 and 5 are front the back:
4 ---- 5
f3 |\ |\ f5
| | 7 ---- 6 \
| 0 |--- 1 | \
| \| \| f4
f2 3 ---- 2
f0 ----- f1
Using: OpenFOAM-dev (see www.OpenFOAM.org)
Build: dev-dc59c63351e7
