- Use on/off vs longer compressed/uncompressed.
For consistency, replaced yes/no with on/off.
- Avoid the combination of binary/compressed,
which is disallowed and provokes a warning anyhow
- 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).
- only treat text as an option if it is preceded by 0-4 spaces.
This prevents the description of an option from being accidentally
detected as an option.
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.
