Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-07-06T17:09:26Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1615chtMultiregionFoam relaxation problem2021-07-06T17:09:26ZTj KimchtMultiregionFoam relaxation problemIn the Pimple mode with relaxation of p_rgh, the chtMultiregionFoam solver returns an error message of
"not stored. Use field.storePrevIter()"
I found the solver already includes a function call of storePrevIter().
So I think that it is ...In the Pimple mode with relaxation of p_rgh, the chtMultiregionFoam solver returns an error message of
"not stored. Use field.storePrevIter()"
I found the solver already includes a function call of storePrevIter().
So I think that it is out of my job.
The solver in v1906 is same as the v1912.
With the same fvSolution file, OF-7 runs good.
Could you please check the reason?
My recommendation is to update solutioncontrol classes in v1912 similar to those in OF-7Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1611Wrong curvature at finite area boundary2022-05-06T08:04:23ZChiara PesciWrong curvature at finite area boundary<!--
*** 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
Curvature computation at finite area boundaries is wrong.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
To visualize the curvature field, one can modify for instance the *checkFaMesh* utility. A volScalarField can be added and the aMesh.faceCurvatures() can be written out on its boundary corresponding to the faMesh.
```
volScalarField curvVf
(
IOobject
(
"curvVf",
runTime.timeName(),
mesh,
IOobject::NO_READ,
IOobject::AUTO_WRITE
),
mesh,
dimensionedScalar(dimless/dimLength, Zero)
);
// Create volume-to surface mapping object
volSurfaceMapping vsm(aMesh);
vsm.mapToVolume(aMesh.faceCurvatures(), curvVf.boundaryFieldRef());
curvVf.write();
```
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
Consider the surface of half a sphere, this is represented by a finite area mesh with a boundary, the circumference at the equator. The curvature of the sphere is known; in this case the radius of the sphere is 1 m, thus the curvature should be -2.
### What is the current *bug* behaviour?
<!-- What actually happens -->
The figures below show the local curvature and the error in its computation on half a sphere for which the analytical curvature is known.
![curvatureV1912boundary](/uploads/d5527f5f263d9bc311c9bf0c605480b1/curvatureV1912boundary.png)
Note that the error persists when refining the mesh or using different cell/face shapes.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
```
Curvature: min = min(faceCurvatures) [0 -1 0 0 0 0 0] -2.0005
max = max(faceCurvatures) [0 -1 0 0 0 0 0] -1.48813
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1912 (problem present also in older versions)
- Operating system :
- Hardware info :
- Compiler :
### 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
-->
A correction for the faces having a point on the boundary of the finite area mesh has to be included. The curvature computation depends on the pointAreaNormals and at the boundary of the finite area mesh these normals introduce the error. A solution for cases where the mesh is not being highly deformed close to the boundary may be possible.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1604Restart not possible for liquidFilmFoam2022-04-26T16:10:40ZChiara PesciRestart not possible for liquidFilmFoam<!--
*** 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
Impossible to restart a simulation with liquidFilmFoam
### Steps to reproduce
Run the tutorial $FOAM_TUTORIALS/finiteArea/liquidFilmFoam/cylinder
Restart the simulation from latestTime
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
At restart the solver looks for the ```areaScalarField h``` (as it is given in the 0 folder), but in the saved time folders it is written out as a ```volScalarField``` (with object name H).
Two different fields, h (area) and H (vol), are created, but possibly the write() function is not case sensitive and the volScalarField overwrites the areaScalarField.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
```
--> FOAM FATAL IO ERROR:
unexpected class name volScalarField expected areaScalarField
while reading object h
file: /liquidFilmFoam/cylinder/0.5/h at line 15.
From function Foam::Istream& Foam::regIOobject::readStream(const Foam::word&, bool)
in file db/regIOobject/regIOobjectRead.C at line 170.
FOAM exiting
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1912
- Operating system :
- Hardware info :
- Compiler :
### 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
-->v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1601Feature request: sedFOAM submodule2023-11-24T16:26:48ZKutalmış BerçinFeature request: sedFOAM submodule### Functionality to add/problem to solve
http://servforge.legi.grenoble-inp.fr/pub/soft-sedfoam/
https://github.com/sedfoam/sedfoam
Following the short discussion in their repo: https://github.com/SedFoam/sedfoam/issues/15
the mainta...### Functionality to add/problem to solve
http://servforge.legi.grenoble-inp.fr/pub/soft-sedfoam/
https://github.com/sedfoam/sedfoam
Following the short discussion in their repo: https://github.com/SedFoam/sedfoam/issues/15
the maintainer of sedFOAM showed keen interest on OpenFOAM's submodule functionality.
sedFOAM is represented as a code suite for two-phase flow sediment flow applications.
### Target audience
Wave/free surface involved applications, e.g. masts erected in sea bed, tidal turbines, or in general, underwater structures close to sea bed (might misunderstand).
### Proposal
If the maintenance cost of adding and shipping a new submodule is very low for OpenFOAM, sedFOAM submodule would be a win-win.
### What does success look like, and how can we measure that?
The suite is based on a set of publications, and has its own user group (it seems). Also, reasonably well maintained by a group of people, compatible with recent OF versions.
### Funding
NA
@andy @mark @Mattijs @Sergio @Prashant @RogerKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1592Proposal: alphatWallBoilingWallFunctionFvPatchScalarField.C wall temperature ...2021-07-08T14:12:44ZRobin KamenickyProposal: alphatWallBoilingWallFunctionFvPatchScalarField.C wall temperature iterationHello everyone,
I have noticed that in the release OF-v1906 in the file OpenFOAM-v1906/src/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction/alphatWallBoilingWallFunctionFvPatchScalarField.C there wa...Hello everyone,
I have noticed that in the release OF-v1906 in the file OpenFOAM-v1906/src/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction/alphatWallBoilingWallFunctionFvPatchScalarField.C there was a for loop to evaluate wall temperature Tw. The for loop was, however, not executed because of lagging (line 1124 // NOTE: lagging Tw update.).
Thus, the wall temperature was not evaluated after the calculation of the thermal turbulent diffusivity. This led to zero error between TsupPrev and TsupNew and so the for loop was not executed. The fix to that would be the evaluation of the maximum error from all CPUs. Thus
`scalar maxErr(gMax(mag(TsupPrev - TsupNew)));`
instead of
`scalar maxErr(max(mag(TsupPrev - TsupNew)));`
When the original version is used then each processor might evaluate the error if condition on the line 1260
if (maxErr < 1e-1) differently, which means that some processor exits the for loop and some processor loops again. In this manner, the processors enter different parts of the code. Once they encounter a mpi function which requests information also from the other processor, it waits (forever, deadlock). This exactly happens when alphatWallBoilingWallFunctionFvPatchScalarField.C is used together with the turbulentTemperatureCoupledBaffleMixedFvPatchScalarField.C
I propose that the for loop to find wall temperature is implemented (as it was removed from OF-v1912) and the lagging to be fixed in the manner I showed above. It is generally recommended by literature to do this looping. Its absence might not be a big issue for heat transfer which uses correlations (film boiling and transitional boiling) but might be an issue for more complicated nucleate boiling.
Thank you,
Kind regards,
RobinKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1583checkMesh : patch geometry : include flatness2020-02-05T13:34:26ZPrashant SonakarcheckMesh : patch geometry : include flatness### Functionality to add/problem to solve
Would be nice for checkMesh to report whether a patch is flat for e.g. follow-on extrudeMesh.
### Proposal
Add to -allGeometry check the reporting of the maximum deviation of (face) normal w....### Functionality to add/problem to solve
Would be nice for checkMesh to report whether a patch is flat for e.g. follow-on extrudeMesh.
### Proposal
Add to -allGeometry check the reporting of the maximum deviation of (face) normal w.r.t. average.
Q:
- how much deviation is non-flat
- report per patch-region (e.g. for lid-driven cavity tutorial where single patch has 3 different orientations)
Cross-ref : EP#1159https://develop.openfoam.com/Development/openfoam/-/issues/1581transient solver with suitable ddtScheme2020-02-03T12:37:26ZPrashant Sonakartransient solver with suitable ddtScheme### Functionality to add/problem to solve
Trying to run a transient solver with 'steadyState' as ddtScheme usually causes a divide by zero (sigfpe). This is quite an easy mistake to make when starting from a steady-state solution.
###...### Functionality to add/problem to solve
Trying to run a transient solver with 'steadyState' as ddtScheme usually causes a divide by zero (sigfpe). This is quite an easy mistake to make when starting from a steady-state solution.
### Proposal
Would be nice to give a warning message. It still should be possible in general (e.g. to replace an outer loop with the time loop).
Cross Ref: EP#1204https://develop.openfoam.com/Development/openfoam/-/issues/1576coded FO does not support mesh changes2020-01-27T15:19:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcoded FO does not support mesh changes### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify...### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify missing callbacks
- syntax inside codedFunctionObject to specify the missing code ('codeMovePoints'?)
- redirection callshttps://develop.openfoam.com/Development/openfoam/-/issues/1570Cloud post-processing data not written when steady case converges using resid...2020-01-28T09:28:57ZAndrew HeatherCloud post-processing data not written when steady case converges using residualControl<!--
*** 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 -->
When using clouds in steady solvers combined with case termination controls set using `residualControl` in the `fvSolution` file, cloud post-processing data are not written on the last iteration.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Add `residualControl` settings to a steady flow solver with cloud functionality and cloud a post-processing object, e.g. `particleTracks`
```
particleTracks
{
type particleTracks;
trackInterval 5;
maxSamples 1000000;
resetOnWrite yes;
}
```
and notice that the cloud post-processing data are not written
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
When the criteria specified in the `residualControls` dictionary are achieved the solver loop calls `time.writeAndEnd()` to write any objects registered with `AUTO_WRITE` and exits. Operations such as cloud post-processing are currently only triggered when evolving the cloud and intercept the `writeTime()` flag and are therefore missed.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :
- Operating system :
- Hardware info :
- Compiler :
### 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
-->
Couple of options
- instead of exiting straight away, run for 1 more iteration with the `writeTime_` flag set (e.g. using `time.writeOnce()` and exit
- intercept the `write()` call to trigger other post-processing actionsv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1542checkMesh aspect ratio2024-01-10T16:47:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh aspect ratio### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calc...### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calculation from e.g. the cellDeterminant check and determine the aspect ratio in that.
### What does success look like, and how can we measure that?
Make e.g. cavity with a lot of grading. See if the reported aspect ratio changes if the case is rotated (e.g. using `transformPoints -rotate`)https://develop.openfoam.com/Development/openfoam/-/issues/1532Local Time Stepping for High Aspect Ratio Cells2022-04-26T16:10:39ZLiamLocal Time Stepping for High Aspect Ratio CellsLocal Time stepping an extremely effective method to obtain steady state solutions to a variety of cases. However, in cases with high aspect ratio cells, the local time-step becomes extremely small. This occurs in a number of situations,...Local Time stepping an extremely effective method to obtain steady state solutions to a variety of cases. However, in cases with high aspect ratio cells, the local time-step becomes extremely small. This occurs in a number of situations, specifically in cases where a wall resolved simulation is required. As the mesh must be refined to Y+ < 1, the aspect ratio becomes very high and the simulation begins to converge very slowly.
It has been shown in literature, and in other CFD codes, that taking into account the aspect ratio of the cell can speed up the convergence of the computation significantly (by an order of magnitude). In my own experience, certain cases (airfoils/de Lave nozzles) with high Reynolds number and thus very small Y+ = 1 distance, had an acceleration of over 100 times making these simulations optimum for parametric studies or optimization.
Implementing this feature which takes into account the aspect ratio of the cell in computing the local time-step would alleviate the number of iterations required to converge the solution in these cases. Literature on this can be found:
https://arc.aiaa.org/doi/pdf/10.2514/6.2001-2557
Additionally, this has been implemented into ANSYS Fluent under the name of "Convergence Acceleration for Stretched Meshes (CASM)".
http://www.pmt.usp.br/ACADEMIC/martoran/NotasModelosGrad/ANSYS%20Fluent%20Theory%20Guide%2015.pdf (PDF Pg. 699)
https://support.ansys.com/staticassets/ANSYS/Conference/Dallas/downloads/fluid-dynamics-14.0-update.pdf (PDF Pg. 14)
http://www.pmt.usp.br/academic/martoran/notasmodelosgrad/ANSYS%20Fluent%20Users%20Guide.pdf (PDF Pg. 1499)
An appropriate test case, for example, would be: NACA0012 with a wall-resolved mesh and the appropriate turbulence model for a wall-resolved RAS simulation. Running this at a high Re number would help high-light the effectiveness. Run the simulation with and without this new feature. The results should be effectively identical however using this feature the simulation should required significantly fewer iterations.v2206https://develop.openfoam.com/Development/openfoam/-/issues/1528snappyHexMesh castellation step creates gaps between curved triangulated surf...2024-01-02T13:17:31ZDries AllaertssnappyHexMesh castellation step creates gaps between curved triangulated surfaces### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, eve...### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, even when stl files are exported at very high resolution (highest resolution available in the CAD software).
### Steps to reproduce
The issue can be reproduced by applying snappyHexMesh on a multiregion case with a curved interface between two regions, and with the different regions specified by different stl files exported from CAD software.
### Example case
Attached is a minimal working example consisting of two concentric cylinders corresponding to a fluid and a solid region. Only the castellation step of snappyHexMesh is run. [MWE.tar.gz](/uploads/21ca31e1c36f1f0e4a2673ec786c5fd9/MWE.tar.gz)
### What is the current *bug* behaviour?
The castellation step of snappyHexMesh creates small gaps between two triangulated surfaces, i.e., on the interface between two regions. As a result, some faces on the interface are identified as walls instead of mappedWalls between the two surfaces. In the snapping step, the gaps are closed but the patch type of some faces remains wall instead of mappedWall.
### What is the expected *correct* behavior?
snappyHexMesh should not remove cells located between two triangulated surface when the two triangulated surfaces coincide within a certain tolerance. The tolerance should be such that coinciding surfaces exported by CAD software can be meshed without creating small gaps. Possibly, this tolerance could be a user input.
### Relevant logs and/or images
Attached is a log file ([log.txt](/uploads/d20cb17863dbfce7ae643e6f8d23c929/log.txt)) of the provided minimal working example (logs of surfaceFeatureExtract - blockMesh - snappyHexMesh - splitMeshRegions) as well as some figures showing the case setup and the gaps on the interface.
Overview of the multiRegion geometry.
![MWE_fig1](/uploads/46a8588961f77c7616bdefac7eede9f1/MWE_fig1.png)
Detailed view of the interface.
![MWE_fig2](/uploads/a691486b653b0a97414885d0052784e1/MWE_fig2.png)
View of the interface, showing some faces that are identified as type wall (white) instead of mappedWall (red)
![MWE_fig3](/uploads/d6a1e6157024dad044c6cc8306f2dd6c/MWE_fig3.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1906
- Operating system : CentOS Linux release 7.6.1810
- Hardware info :
- Compiler : intel
### Possible fixeshttps://develop.openfoam.com/Development/openfoam/-/issues/1507Modify the static regIOobject::store method, possibly remove the member version?2024-02-20T15:58:37ZMark OLESENModify the static regIOobject::store method, possibly remove the member version?Just discussed with @Mattijs, following up on discussions with @andy
Given the scenario of having a local (unregistered) field
```
volScalarField* ptr = volScalarField:New(...).ptr(); // An unregistered pointer
```
I would later like...Just discussed with @Mattijs, following up on discussions with @andy
Given the scenario of having a local (unregistered) field
```
volScalarField* ptr = volScalarField:New(...).ptr(); // An unregistered pointer
```
I would later like to register this on its objectRegistry and have the registry take ownership.
- Using `ptr->store()` merely changes the ownership flag, but doesn't register.
- Using `ptr->checkIn()` will register it, but not take ownership.
The static `store()` version is just the same as the member one, with a nullptr check, but does not actually give ownership to the registry.
The static regIOobject::store() should probably attempt to check-in the object if not already marked as registered_.
If the object cannot be checked in, Fatal, Warn, or package as autoPtr for deletion?
Minor (style) - the objectRegistry debug diagnostics will warn about attempting to insert an object with identical name. Should probably check if existing object is actually different.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1492fixup for PDRsetFields2019-11-19T11:21:20ZMark OLESENfixup for PDRsetFieldsPlaceholder for topics, changes etc.
@pratap @puttockPlaceholder for topics, changes etc.
@pratap @puttockMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1491SnappyHexMesh: Treat feature edge/cell between different PID for layer addtition2019-11-12T12:09:21ZPrashant SonakarSnappyHexMesh: Treat feature edge/cell between different PID for layer addtition### Functionality to add/problem to solve
Using mutli-region feature edge we can capture in-plane edges. Improve the snapping to help generate layers at this section.
### Links / references
EP#1084### Functionality to add/problem to solve
Using mutli-region feature edge we can capture in-plane edges. Improve the snapping to help generate layers at this section.
### Links / references
EP#1084Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1486surfaceFeatureExtract trims all features on a brick when minElem > 12020-01-06T19:29:41ZAdminsurfaceFeatureExtract trims all features on a brick when minElem > 1### Summary
Not sure if this is a bug report of a feature request, but here it goes.
When I extract features on a brick defined by an stl file, the edge features (12 of them) only get extracted if trimFeatures minElem is not used or set...### Summary
Not sure if this is a bug report of a feature request, but here it goes.
When I extract features on a brick defined by an stl file, the edge features (12 of them) only get extracted if trimFeatures minElem is not used or set to something not higher than 1. Since all the features are "connected" on the brick, I would have expected features to not be trimmed until at least a value of 13 on minElem.
This probably gets into how you are determining the number of elements in feature strings. In other software I've used, they generally separate things into "connected" feature groups and then apply element filtering to each of those. For example, a brick would have 12 connected feature edges and be in one group, so a minElem of 2 shouldn't trim any of the features, but in surfaceFeatureExtract, it does.
### Steps to reproduce
Run surfaceFeatureExtract on the attached brick model. No features will be extracted because minElem is set to 2. If you set it to 1, the features get extracted.
### Example case
[brick.zip](/uploads/be63b675856f5a189e7cd6035e0294e6/brick.zip)
### What is the current *bug* behaviour?
No features will be extracted because minElem is set to something above 1.
### What is the expected *correct* behavior?
I would expect all features to be extracted until minElem reaches 13, since there are 12 connected feature edges on a brick.
### Environment information
OpenFOAM version : v1906
Operating system : RHEL / Windows
Compiler : gcc / MinGW
### Possible fixes
I looked in surfaceFeatures.C to try and glean how feature strings were being determined, but I was unable to decipher the strategy being used. My guess is that there is a difference in strategy, if that's the case, then this is a feature request.
\## Reattaching the author to the issue ticket: @graups ##https://develop.openfoam.com/Development/openfoam/-/issues/1471Potentially redundant set of computations for G object within eddy-viscosity ...2022-04-26T16:10:39ZKutalmış BerçinPotentially redundant set of computations for G object within eddy-viscosity turbulence modelsSome of the eddy-viscosity-based turbulence models compute G (the turbulent kinetic energy production rate due to the anisotropic part of the stress tensor). For example, in kEpsilon:
```
volScalarField::Internal G
(
thi...Some of the eddy-viscosity-based turbulence models compute G (the turbulent kinetic energy production rate due to the anisotropic part of the stress tensor). For example, in kEpsilon:
```
volScalarField::Internal G
(
this->GName(),
nut.v()*(dev(twoSymm(tgradU().v())) && tgradU().v())
);
tgradU.clear();
```
Here, we compute a deviatoric-symmetric tensor (`(dev(twoSymm(tgradU().v()))`) with a full tensor `tgradU().v()`.
**Any tensor** can be divided into its symmetric and anti-symmetric parts. And any double-inner product of a symmetric tensor and an anti-symmetric tensor is zero.
Therefore, the above double-inner product can be reduced between two symmetric tensors without losing any level of accuracy in the final outcome.
Such reduction seems to be carried out in the more recently implemented turbulence models, e.g. v2f.
The simpler, cheaper-to-run alternative can be:
```
tmp<volTensorField> tgradU = fvc::grad(U);
const volScalarField::Internal G
(
this->GName(),
nut.v()*2*magSqr(dev(symm(tgradU.cref().v())))
);
tgradU.clear();
```
PS: Asked the question in CFD-Online: [here](https://www.cfd-online.com/Forums/openfoam-solving/229596-potentially-redundant-set-computations-g-object-within-turbulence-models.html).v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1458nearWallFields does not run with #includeFunc since "field" and "fields" keyw...2022-04-26T16:10:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comnearWallFields does not run with #includeFunc since "field" and "fields" keyword are reservedfunctionObject reading in functionObjectList::readFunctionObject assumes that 'field' and 'fields' entries are straight wordlists.
nearWallFields uses 'field' for a List of word tuple. The workaround is to use it in a #include file (so ...functionObject reading in functionObjectList::readFunctionObject assumes that 'field' and 'fields' entries are straight wordlists.
nearWallFields uses 'field' for a List of word tuple. The workaround is to use it in a #include file (so the nearWallFields dictionary is a subdictionary) and not in a #includeFunc context.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1456sampledSet 'uniform' does not produce same output in parallel2022-04-27T10:28:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsampledSet 'uniform' does not produce same output in parallel<!--
*** 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 -->
different number of samples when run in parallel.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Take pitzDaily tutorial. Use decomposeParDict with
```
//- The total number of domains (mandatory)
numberOfSubdomains 2;
////- The decomposition method (mandatory)
method random;
```
There will be 10 tracks when running in parallel but only 1 when running in parallel.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : develop (but probably also v1906)
- Operating system : openSUSE
- Hardware info :
- Compiler :
### 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
-->v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1417average printed in e.g. 'Average Courant Number' differs between parallel and...2022-03-10T20:13:05ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comaverage printed in e.g. 'Average Courant Number' differs between parallel and non-parallel<!--
*** 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
average printed in e.g. 'Average Courant Number' differs between parallel and non-parallel
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run e.g. pimpleFoam with
- binary writing so we don't have any write precision issues
- non-uniform 0/U
- no 0/phi
It will now calculate the initial phi and the Courant number from that (finiteVolume/cfdTools/incompressible/CourantNo.H). I would expect it to be the same for parallel and non-parallelKutalmış BerçinKutalmış Berçin