Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-01-03T10:03:55Zhttps://develop.openfoam.com/Development/openfoam/-/issues/20Placeholder: self-intersections of surfaces (surfacePatch utility)2020-01-03T10:03:55ZPrashant SonakarPlaceholder: self-intersections of surfaces (surfacePatch utility)Tested again with non-overlapping nodes/edges case.
It still fails (see intersections of unitCubes.stl)
[surfaceToPatch.tgz](/uploads/0a78a54cddbf2e7f03a36a27fed5d9aa/surfaceToPatch.tgz)
Tested again with non-overlapping nodes/edges case.
It still fails (see intersections of unitCubes.stl)
[surfaceToPatch.tgz](/uploads/0a78a54cddbf2e7f03a36a27fed5d9aa/surfaceToPatch.tgz)
Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/361Add in architecture checking IOobjects read.2020-01-03T10:00:50ZMark OLESENAdd in architecture checking IOobjects read.Placeholder for topics related to "arch" handling (endian, label and scalar sizes) that was added for v1612.
We now emit arch hints such "LSB,label=32,scalar=64", but don't do anything with them on input.
The first point is to simply to...Placeholder for topics related to "arch" handling (endian, label and scalar sizes) that was added for v1612.
We now emit arch hints such "LSB,label=32,scalar=64", but don't do anything with them on input.
The first point is to simply to check their types on input: "arch" exists and is identical to the current OpenFOAM configuration.
The next would be a special-purpose foam-convert utility. Handling a change from int64 to int32 might only work in very special cases. For example, when snappy needs 64-bit labels because the input surfaces have so many points and faces, but the resulting mesh would still fit with int32.Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/315cellMotion bc does not write patchType (if used on constraint types)2020-01-03T09:59:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcellMotion bc does not write patchType (if used on constraint types)This was tested in v1606+, not sure if fixed already.This was tested in v1606+, not sure if fixed already.https://develop.openfoam.com/Development/openfoam/-/issues/158uniform/functionObjects/functionObjectProperties gets written even if no func...2020-01-03T09:58:37ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comuniform/functionObjects/functionObjectProperties gets written even if no functionObjectsE.g. icoFoam/cavity case
E.g. icoFoam/cavity case
Version v1612https://develop.openfoam.com/Development/openfoam/-/issues/404multiple intersections not found by shm2020-01-03T09:56:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commultiple intersections not found by shmThis can cause mesh leakage.
Problem 1: triSurfaceSearch::findLineAll does not increase starting point after finding hit. This should not be needed since any previous intersections are excluded through the shapeMask.
Problem 2: fast tria...This can cause mesh leakage.
Problem 1: triSurfaceSearch::findLineAll does not increase starting point after finding hit. This should not be needed since any previous intersections are excluded through the shapeMask.
Problem 2: fast triangle-bounding box calculation misses some intersections.https://develop.openfoam.com/Development/openfoam/-/issues/432BUG? SHM: layer addition on faceZone2020-01-03T09:50:48ZPrashant SonakarBUG? SHM: layer addition on faceZoneAttached example where box (STL) is used to generate cellZone/FaceZone.
However when adding layers to faceZone, the name is listed based on region name instead of faceZone.
SHM reports
```
patch faces layers overall thi...Attached example where box (STL) is used to generate cellZone/FaceZone.
However when adding layers to faceZone, the name is listed based on region name instead of faceZone.
SHM reports
```
patch faces layers overall thickness
[m] [%]
----- ----- ------ --- ---
Interface 914 2.98 0.313 95.9
```
which doesn't exist in patch nor internal faceZone (at time 3)!
[v1612_SHM_layer_faceZone.tgz](/uploads/1721adce2a769d81b2095a1704daad78/v1612_SHM_layer_faceZone.tgz)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/572snappyHexMesh : visualising connection between inside and outside points2020-01-03T09:46:50ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh : visualising connection between inside and outside pointsWould be nice to have a leak-detection process, either built-in or stand-alone, that can detect mesh paths between provided 'inside' and 'outside' points.Would be nice to have a leak-detection process, either built-in or stand-alone, that can detect mesh paths between provided 'inside' and 'outside' points.https://develop.openfoam.com/Development/openfoam/-/issues/1537BUG: Wrong FatalIOError message in displacementMethod and optMeshMovement2020-01-03T09:44:02ZVaggelis PapoutsisBUG: Wrong FatalIOError message in displacementMethod and optMeshMovement<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The core of the FatalIOError message, including the table of contents of the base class, is not printed by displacementMethod::New and optMeshMovement::New due to exiting the FatalIOError call with exit(FatalError) instead of exit(FatalIOError).
### Steps to reproduce
Enter a non-valid displacementMethod (in dynamicMeshDict) or meshMovement type (in optimisationDict) in any of the tutorials under $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation.
### What is the current *bug* behaviour?
No error message content is printed, only the Fatal Error line.
### What is the expected *correct* behavior?
The full FatalError message, including the toc of the base class should be printed.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1538BUG: writeMorpherCPs expects a controlBoxes entry2020-01-03T09:43:42ZVaggelis PapoutsisBUG: writeMorpherCPs expects a controlBoxes entry<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The *writeMorpherCPs* preProcessing utility expects a *controlBoxes* entry in volumetricBSplinesMotionSolverCoeffs, within dynamicMeshDict. NURBS3DVolume no longer expects this entry (defeatured before release) but *writeMorpherCPs* was not updated accordingly.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1540BUG: continuation of updateMethods with empty activeDesignVariables2020-01-03T09:43:15ZVaggelis PapoutsisBUG: continuation of updateMethods with empty activeDesignVariables<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When activeDesignVariables are not set explicitly, all design variables
are treated as active. These are allocated properly when starting from
0 but not when starting from an intermediate optimisation cycle
(e.g. running 5 optimisation cycles, stopping and restarting).
The bug affects the BFGS, DBFGS, LBFGS, SR1, SQP and conjugateGradient updateMethods.
### Steps to reproduce
1. Copy an optimisation case using BFGS, say $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/turbulent/opt/BFGS/op1
2. Comment out the *activeDesignVariables* in *optimisationDict*.
3. Run for a number of optimisation cycles using *adjointOptimisationFoam*, say 5.
4. Change the *endTime* to 10, to run another 5 optimisation cycles and re-run *adjointOptimisationFoam*. The solver will crash upon trying to compute the update of the design variables since the *activeDesignVariables* list will be empty.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/528directionalPressureGradientExplicitSource hard to use2020-01-03T09:39:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdirectionalPressureGradientExplicitSource hard to useA mesh generator might generate a faceZone (possibly incorrectly oriented) or a cellZone. The faceZone has to be oriented correctly (e.g. orientFaceZone, topoSet with setsToFaceZone and 'flip' option) and the cellZone constructed (topoSe...A mesh generator might generate a faceZone (possibly incorrectly oriented) or a cellZone. The faceZone has to be oriented correctly (e.g. orientFaceZone, topoSet with setsToFaceZone and 'flip' option) and the cellZone constructed (topoSet with faceToCell, setToCellZone). Maybe it could be made such that we only start from a cellZone and the 'faceZone' (i.e. measuring plane) gets derived from velocity and outside faces of the cellZone?Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/541foamList does not link without scotch present2020-01-03T09:32:20ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamList does not link without scotch presentIs missing the dummy version.Is missing the dummy version.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/487foamList does not link if no fftw library (since randomProcesses not built)2020-01-03T09:32:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamList does not link if no fftw library (since randomProcesses not built)Remove it from the Make/options?Remove it from the Make/options?Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/535Harmonize \par vs \param for application options2020-01-03T09:24:40ZMark OLESENHarmonize \par vs \param for application optionsAs noted in !125 and #293 there is a mix of `\par` and `\param` for application options. Andy's suggestion of introducing a doxygen alias would be a good, flexible solution.
@petebachantAs noted in !125 and #293 there is a mix of `\par` and `\param` for application options. Andy's suggestion of introducing a doxygen alias would be a good, flexible solution.
@petebachantv1712AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1534Wiki home: broken link to page "Submitting issues"2019-12-27T10:02:17ZGerasimos ChourdakisWiki home: broken link to page "Submitting issues"In the [wiki home](https://develop.openfoam.com/Development/openfoam/wikis/home), in the sentence:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/p...In the [wiki home](https://develop.openfoam.com/Development/openfoam/wikis/home), in the sentence:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/page-submitting-issues)
```
the [Submitting Issues](https://develop.openfoam.com/Development/openfoam/wikis/Submitting-issues) link is broken. Replace with:
```
Users can provide feedback by submitting *issues* or *feature requests*; please see [Submitting Issues](/Development/openfoam/wikis/Submitting-issues)
```https://develop.openfoam.com/Development/openfoam/-/issues/1515compilation failure of libs POSIX (latest version Dec 2019, PLUS)2019-12-26T08:48:56Zsariew8compilation failure of libs POSIX (latest version Dec 2019, PLUS)i failed to install the latest version (openfoam-plus) in POSIX library. Where should i fix them?
---
[log.make.tar.gz](/uploads/e044e9a16a178ec32a70dce26771523d/log.make.tar.gz)i failed to install the latest version (openfoam-plus) in POSIX library. Where should i fix them?
---
[log.make.tar.gz](/uploads/e044e9a16a178ec32a70dce26771523d/log.make.tar.gz)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1042External forces for rigid body dynamics2019-12-24T11:18:55ZAdminExternal forces for rigid body dynamicsCurrently the rigidBodyDynamics library only supports springs, dampers and a prescribed rotation. I'd love to see a functionality that allows for an external force restraint. E.g for simulating a rigid body that is being pushed by a cert...Currently the rigidBodyDynamics library only supports springs, dampers and a prescribed rotation. I'd love to see a functionality that allows for an external force restraint. E.g for simulating a rigid body that is being pushed by a certain force. Which might be especially useful for overset simulations. Attached is this restraint, which I'd like to see added to src/rigidBodyDynamics/restraints. The force is time and direction variable via function1.
[externalForce.zip](/uploads/a7e0e7af6e122a0b2b3b8c67b7ef001a/externalForce.zip)
Best regards
Stephan
\## Reattaching the author to the issue ticket: @Goeke ##https://develop.openfoam.com/Development/openfoam/-/issues/1489LiquidEvaporationBoil spalding number defined on molar basis2019-12-24T10:34:28ZAdminLiquidEvaporationBoil spalding number defined on molar basisIn OpenFOAM-2.4.0 at **src/lagrangian/intermediate/submodels/Reacting/PhaseChangeModel/LiquidEvaporationBoil/LiquidEvaporationBoil.C**
line 318:
dMassPC[lid] += pi d Sh Dab rhos log(1.0 + Xr) dt;
where d is the droplet diameter, Sh is...In OpenFOAM-2.4.0 at **src/lagrangian/intermediate/submodels/Reacting/PhaseChangeModel/LiquidEvaporationBoil/LiquidEvaporationBoil.C**
line 318:
dMassPC[lid] += pi d Sh Dab rhos log(1.0 + Xr) dt;
where d is the droplet diameter, Sh is the Sherwood number (Sh(Re,Sc)), Dab the vapor diffusivity assuming properties at the film, rhos the density at the film and Xr (line313):
// molar ratio
const scalar Xr = (Xs - Xc)/max(SMALL, 1.0 - Xs);
The units of dMassPC are in kg. However, the dimensionless group Xr is expressed in terms of molar fractions.
In literature, Xr is better known as the Spalding mass number (BM) where the ratio is expressed in terms of mass fractions rather than molar fractions [1,2]
I wonder if there is an implementation reason, which I do not see immediately, or if this is an implementation issue that should be fixed in order to correctly predict the evaporation rate.
Thank you in advance for your support and reply.
Alessandro
[1] Sergei S. Sazhin, Advanced models of fuel droplet heating and evaporation, Progress in Energy and Combustion Science, Volume 32, Issue 2, 2006.
[2] Patrick Jenny, Dirk Roekaerts, Nijso Beishuizen, Modeling of turbulent dilute spray combustion, Progress in Energy and Combustion Science, Volume 38, Issue 6, 2012.
\## Reattaching the author to the issue ticket: @pappo1890 ##https://develop.openfoam.com/Development/openfoam/-/issues/1490postProcess with cyclicACMI patches2019-12-23T14:55:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compostProcess with cyclicACMI patches<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
Run the oscillatingACMI2D tutorial with some e.g. isoSurface functionObject as
``postProcess```
and it will crash since the pointMesh gets cleared out but the pointField (from volPointInterpolation) does not.
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
In polyMesh::readUpdate make sure to update pointMesh (or MeshObject) in general instead of deleting it.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1464nearWallFields does not produce correct sampling location2019-12-23T14:53:36ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comnearWallFields does not produce correct sampling location<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
nearWallFields uses mappedPatchBase::facePoint to find a starting location which is on a tet-face when using the FACE_DIAG cell decomposition. Even on e.g. pitzDaily this might not find a point for all wall faces. Run e.g. nearWallFields with
```
type nearWallFields;
fields
(
(U UNear)
);
// Patches/groups to sample (regular expressions)
patches (wall);
// Distance to sample
distance 0.00001;
```
the fourth face on the top-wall is not found correctly and it falls back to the cell centre.
2) the destination for tracking is calculated from the fall-back cell centre in above case instead of the wanted location on the wall face.
See the UNear on the top-wall. Above tiny distance (0.00001) should produce near-zero.
![topWall](/uploads/b303ab599ba14ba04a2e14c2341252ae/topWall.png)