Adds overset discretisation to selected physics:
- diffusion : overLaplacianDyMFoam
- incompressible steady : overSimpleFoam
- incompressible transient : overPimpleDyMFoam
- compressible transient: overRhoPimpleDyMFoam
- two-phase VOF: overInterDyMFoam
The overset method chosen is a parallel, fully implicit implementation
whereby the interpolation (from donor to acceptor) is inserted as an
adapted discretisation on the donor cells, such that the resulting matrix
can be solved using the standard linear solvers.
Above solvers come with a set of tutorials, showing how to create and set-up
simple simulations from scratch.
- eliminates the PtrList requirement (more flexible)
COMP: use tmp intermediate for volPointInterpolation return value
- gcc 4.8.5 had some weird issue of otherwise not binding a const-ref.
(in foamVtkInternalWriterTemplates.C)
- By definition, binary STL uses float (not double) when reading.
The ascii STL should be the same. This reduces memory overhead when
loading files. The older triSurface reader had float, the surfMesh
reader had double, but now has float.
- Inconsistency in the STL merge-tolerances between triSurface reader,
surfMesh reader and WM_SP vs WM_DP. Now use consistent tolerances
conrresponding to 10,100 * doubleSMALL.
- Similar float/double code adjustments for TRI format since this is
very similar to the STL reader and had a similar inconsistency between
the triSurface and surfMesh version. The AC3D reader still uses
double when reading, but this can be revisited in the future (and can
then remove the stichTriangles method too).
2)Adapting divU in TEqn.H for compressibleInterDyMFoam and compressibleInterFoam
3)Re-instated sixDoFRigidBodyDisplacement as patch for pointFields. It allows to use a different fvDynamincMesh type
independently of the BC's
This is important when LTS stepping or large Co number is used.
Updating rhoBuoyantPimpleFoam to handle closed domain for rho thermo and incompressible Eos.
Consolidating chtMultiRegionSimpleFoam and chtMultiRegionFoam pEqs to use the same formulation as rhoBuoyantPimpleFoam and
rhoBuoyantSimpleFoam
- with the xml append format it is possible to write raw binary
(instead of base64), but the writer becomes more complicated.
Either needs two passes to create, or need to allocate a block
of space for the header information (like VTK itself does) and
write later.
* internalWriter
* patchWriter
* surfaceMeshWriter
* lagrangianWriter
Also these special purpose ones:
* foamVtkWriteSurfFields
- this shifts responsibility away from caller to the individual writers
for knowing which file formats are supported and which file ending is
appropriate. When the writer receives the output format request,
it can elect to downgrade or otherwise adjust it to what it can
actually manage (eg, legacy vs xml vs xml-append).
But currently still just with legacy format backends.
