- 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 |
+-----------------------+---------------+------------------+
ENH: runTimePostProcessing - added option to clear/remove objects after use
When specifying line and surface function-object-based visualisation, use the optional `clearObjects` flag to indicate that source objects should be removed/cleared after use.
Test case: [cavity.tgz](/uploads/62cc2761d132f42456f2af08f1499eba/cavity.tgz)
Syntax:
```
surfaces
{
cuttingPlane1
{
type functionObject;
functionObject cuttingPlane;
clearObjects yes; // new option
...
```
Note: only files that have been used will be removed, e.g. if a function object has created multiple surface files, unused files will remain at the end of the run - in the attached case the p surface remains...
See merge request !89
Integration of ihcantabria wave models
Integration of functionality produced by The Environmental Hydraulics Institute "IHCantabria" (http://www.ihcantabria.com/en/)
- Original code introduced in commit 95e9467e
- Restructured and updated by OpenCFD into a new `waveModels` library available to the interFoam family of solvers
Main source:
`$FOAM_SRC/waveModels`
Tutorials:
`$FOAM_TUTORIALS/multiphase/interFoam/waveExample*`
Capabilities include:
- Wave generation
- Solitary wave using Boussinesq theory
- Cnoidal wave theory
- StokesI, StokesII, StokesV wave theory
- Active wave absorption at the inflow/outflow boundaries based on shallow water theory
IHCantabria Authors:
- Javier Lopez Lara (jav.lopez@unican.es)
- Gabriel Barajas (barajasg@unican.es)
- Inigo Losada (losadai@unican.es)
See merge request !88
- extend the sampling concept to include surfMeshes and surfFields
for storage.
- Note the createOnRead switch in surfMeshSamplers can be desirable in
some situations to force creation of the surface faces within the
constructor.
- was using the ids coming from the zones instead of the sorted order
from ensightFaces, which led to a clash in the mesh point maps that
were manifest as a jumbled order.
BUG: missing newlines in foamToEnsight nfaced/nsided ASCII output
- was correct for foamToEnsightParts, but not for foamToEnsight
--
* Many thanks to Justin Graupman for all of his testing,
which has been a great help in isolating and fixing various issues.
ENH: reduce number of variables, simplify code
- Note: use boolList instead of scalarList for managing the face signs
since its lazy evaluation can be convenient when sign information is
not required.
New feature extract eulerian particles
New functionality to extract particle data from multiphase calculations and replay the data in lagrangian cases, using both the raw input particle data, and data processed into a (smaller) set of injection locations.
See merge request !82
Description
Replays an set of particle data based on an injectedParticleCloud,
using the assumption of one particle per parcel.
Usage
\verbatim
model1
{
type injectedParticleInjection;
SOI 0;
massTotal 0; // Place holder only
parcelBasisType fixed;
nParticle 1; // 1 particle per parcel
cloud eulerianParticleCloud;
positionOffset (-0.025 2 -0.025);
}
\endverbatim
Description
Interrogates an injectedParticleCloud to convert the raw particle
data into a set of 'binned' injectors.
The bins are set according to the particle \c tag property, from which:
- diameters are converted into \c general distributions with a
user-specified bin width
- raw velocity and diameter data are resampled and stored to provide
variations per injector
The mass to inject can be set according to the raw input data mass total
by using the \c applyDistributionMassTotal switch
Usage
\verbatim
model1
{
type injectedParticleDistributionInjection;
SOI 0;
parcelBasisType mass;
cloud eulerianParticleCloud;
positionOffset (-0.025 2 -0.025);
binWidth 0.1e-3;
parcelsPerInjector 500;
resampleSize 100; // optional
applyDistributionMassTotal yes;
// Placeholder only when using applyDistributionMassTotal
massTotal 0;
}
\endverbatim
Note
The each injector location is assumed to be operating under steady
conditions, i.e. using a constant flow rate profile
SourceFiles
InjectedParticleDistributionInjection.C
See also
Foam::injectedParticle
Foam::injectedParticleCloud
Foam::functionObjects::extractEulerianParticles
Foam::distributionModels::general
