Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-11-12T12:09:21Zhttps://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/1387Iso surface truncated by new "topo" method2020-12-20T14:06:24ZAdminIso surface truncated by new "topo" methodDuring the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown...During the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown in the picture attached (orange is Lambda2 via standard isoSurface and blue Lambda2 via isoSurfaceTopo).
![isoSurfaceTopoComparison](/uploads/332d5bd542ea4b4ce71eba275065dfe9/isoSurfaceTopoComparison.png)
\## Reattaching the author to the issue ticket: @Ricky-11 ##
\## Reattached image ##Mark OLESENMark OLESENhttps://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/1288Incorrect behaviour of overset and cellVolumeWeight2020-04-16T12:11:25ZAdminIncorrect behaviour of overset and cellVolumeWeight### Summary
I’ve identified three possible problems with overset and specifically cellVolumeWeight interpolation method. I’ve attached three patches that attempts to resolve the three problems. There is also a small test case to illust...### Summary
I’ve identified three possible problems with overset and specifically cellVolumeWeight interpolation method. I’ve attached three patches that attempts to resolve the three problems. There is also a small test case to illustrate the problems. The test case is explained in a little bit more detail in the README file.
1) First of cellVolumeWeight is a bit chatty. I’ve enclosed all Pouts into a if(debug). This is the first patch.
2) "Cell: X at:(x y z) zone: 0 changed from hole to calculated but there is no donor"
I think there could be several reasons why this error is thrown. A less fatal approach would be to revert cells with no donors to HOLE. Although it has to be done before findHoles and walkFront. The second patch does this.
3) Of course a better approach would be to find where the error is made. The cells shouldn’t have been set to CALCULATED in the first place. I attempt to fix this in patch 3.
### Steps to reproduce
Run the attached test case with overPimpleDyMFoam. The fatal error is thrown during the first iteration. Now change the number of cells in the x-direction in the background mesh from 36 to 37 and the case runs for a little longer until the overset grid again linest up with the background mesh.
Please see the README for instructions on how to run the case. Basically compile rangeLimitedLinearSpring and then run Allrun in the checkvalve folder.
### Example case
A very crude test case of a check valve closing during reverse flow is attached.
[testcase.tgz](/uploads/a8d1bad8d29b7156c61559f8e1c4c27c/testcase.tgz)
### What is the current *bug* behaviour?
I believe a mistake is made in the function combineCellTypes. There, allCellTypes is set to HOLE if interpolatedPatchTypes is a patch and if there is insufficient overlap. Now if the patch from the overset grid cuts the background mesh exactly between cells (or close enough) both cells on both sides will have good overlap and they aren’t set to HOLEs. This will cause findHoles to fail when it “walks” and sets faces to isBlocked. Later when the mesh is split there will be leaks and the entire region might not be found where there should be holes. Theses cells are instead set to CALCULATED. The third attached patch overcomes this problem by simply not checking if there is sufficient overlap and just sets the cells to HOLE when they are cut by a patch from another region. I think it’s a safe assumption that all cells cut by patches from other regions should be HOLE. Before commit 16fb52d42bb5eff4d59910c99410e6f524ef25cc where the tolerance is adjusted, it was also possilbe that the error wasn't thrown, instead regions in the background mesh where set to CALCULATED where they should have been HOLE.This could be seen as high velocites in the background mesh where there should be no solution.
### What is the expected *correct* behavior?
There should be no fatal error, at least not this particular one. The field cellTypes should be correctly calcualted.
### Relevant logs and/or images
Please see attached case.
### Environment information
OpenFOAM version : plus/v1812
Operating system : ubuntu, redhat 6.4
Compiler : gcc
This bug report is based of commit 4569a8b3c5636ae30122ac570cbbca697fc1e07f from 12th of april.
### Possible fixes
blamed file:
[src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/4569a8b3c5636ae30122ac570cbbca697fc1e07f/src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C)
In the attached tar-file there is a folder called patches, either apply them or use the file in the "foldermodified_files_after_patch3" which conatins all three patches.
This is a version where all three patches have been applied.
[cellVolumeWeightCellCellStencil.C](/uploads/a19d46b73eb6b0c30ae41c30bdcd9997/cellVolumeWeightCellCellStencil.C)
I've tested with the attached case and twoSimpleRotors. They run fine. I havn't tested other overset solvers.
Also please note that the pressure field is stil calculated in HOLE regions. I haven't found a reason for this. But at least no the velocity field is zero in these regions.
\## Reattaching the author to the issue ticket: @nicolasedh ##https://develop.openfoam.com/Development/openfoam/-/issues/770sampledSets do not operate if there are no fields2020-01-03T12:06:04ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsampledSets do not operate if there are no fieldsThey specifically test for no applicable fields and write
```No fields to sample```
For some sets it might be nice though to still have an output.They specifically test for no applicable fields and write
```No fields to sample```
For some sets it might be nice though to still have an output.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/1399Suggestion for improvement of Code development guide2021-08-27T14:40:15ZJohan RoenbySuggestion for improvement of Code development guideCommunity contributors who want to fix a bug or make an improvement to OpenFOAM will often have an older compiled version of the OpenFOAM-plus develop branch on their local computer. The proper workflow for such people would (as I unders...Community contributors who want to fix a bug or make an improvement to OpenFOAM will often have an older compiled version of the OpenFOAM-plus develop branch on their local computer. The proper workflow for such people would (as I understand it) be to git pull the latest OpenFOAM-plus, recompile it and then introduce their changes in a bug-fix/feature branch derived from there.
However, if API changes have occurred since their last git pull, the recompilation will fail due to outdated dep files etc. Having to wait for a full recompilation of everything every time I wanted to contribute has been a source of frustration for me until I discovered the -u/-update flag of the Allwmake script, which removes deprecated files and directories so the updating becomes much faster.
I therefore suggest to make contributors aware of this flag in the code development guide [here](https://develop.openfoam.com/Development/OpenFOAM-plus/wikis/page-code-development).Mark OLESENMark OLESENhttps://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çinhttps://develop.openfoam.com/Development/openfoam/-/issues/768redistributePar does not do DimensionedFields2021-07-06T12:29:16ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar does not do DimensionedFieldsMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1380Simplify output of the forces functionObject2020-11-07T16:14:52ZAdminSimplify output of the forces functionObject### Functionality to add/problem to solve
The output produced by the `forces` function object is much more complex than what it could be.
For each time step the output line is as
`0.65004 \t(4.966426e-01 1.252274e+00 -3.007485e-0...### Functionality to add/problem to solve
The output produced by the `forces` function object is much more complex than what it could be.
For each time step the output line is as
`0.65004 \t(4.966426e-01 1.252274e+00 -3.007485e-04)\t(4.246068e-01 1.273820e+00 2.141011e-17)\t(7.203576e-02 -2.154636e-02 -3.007485e-04)`
Here `\t` is a tab.
Also, two separate files are created, one for the forces and one for the moments.
### Proposal
Simply having 10 values separated by spaces or tabs (consistently!) would make it much easier to open the text file with e.g. numpy or pandas, without sacrificing much.
Combining both forces and moments into single file is also reasonable.
A switch could be added to allow falling back to the old output format.
\## Reattaching the author to the issue ticket: @timofeymukha ##v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1347rhoMax/rhoMin defined but not used in buoyantSimpleFoam2022-04-26T16:10:40ZAdminrhoMax/rhoMin defined but not used in buoyantSimpleFoamIn the solver `applications/solvers/heatTransfer/buoyantSimpleFoam`, the `rhoMax` and `rhoMin` variables are defined in `createFields.H`, but never used in this solver.
I noticed this today with v1806, but have checked and this also occu...In the solver `applications/solvers/heatTransfer/buoyantSimpleFoam`, the `rhoMax` and `rhoMin` variables are defined in `createFields.H`, but never used in this solver.
I noticed this today with v1806, but have checked and this also occurs in v1812 and v1906-rc1.
According to `git blame`, the commit 1a701d9eac55a49f22b983683826d3ead8a8c85b is when this was added, but the min-max restriction was not imposed into this solver, the same way it was in chtMultiRegionSimpleFoam: https://develop.openfoam.com/Development/OpenFOAM-plus/blob/1a701d9eac55a49f22b983683826d3ead8a8c85b/applications/solvers/heatTransfer/chtMultiRegionFoam/chtMultiRegionSimpleFoam/fluid/pEqn.H#L91
\## Reattaching the author to the issue ticket: @wyldckat ##v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/576ENH: improving postChannel2021-07-31T18:02:11ZAdminENH: improving postChannelHello!
postChannel is an old small utility that allows to collapse data from a turbulent channel flow LES or DNS into a single profile by averaging along x and z, which are statistically homogeneous directions. There is, however, a sign...Hello!
postChannel is an old small utility that allows to collapse data from a turbulent channel flow LES or DNS into a single profile by averaging along x and z, which are statistically homogeneous directions. There is, however, a significant downside: it is impossible to choose what fields are to be averaged. Instead, they are hardcoded, see
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/applications/utilities/postProcessing/miscellaneous/postChannel/collapse.H
A couple of years ago I have developed my version of the utility which allows one to provide a list of fields to be averaged. Also, it allows you to specify the names of the patches corresponding to the top and bottom walls, and the outputted 1d profiles will include the data averaged on the patches. This is relevant in some situations, for instance in Wall-Modelled LES, where nu_t at the wall is an important quantity. Here is the repo with my code.
https://bitbucket.org/lesituu/postchannelflow
I would like to know if there is interest in incorporating my enhancemnts into the main code. From my side this seems like a nice small enhancemnt, which can be used to test getting through the process of contributing some code.
Kind regards,
Timofey
\## Reattaching the author to the issue ticket: @timofeymukha ##Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1361createPatch does not update fields in v19062022-04-26T16:10:39ZAdmincreatePatch does not update fields in v1906when using createPatch to merge patches, the mesh is updated but the accompanying mesh fields are not. This causes crashes with running other utilities, which complain that patches are missing or that number of faces on patches do not ma...when using createPatch to merge patches, the mesh is updated but the accompanying mesh fields are not. This causes crashes with running other utilities, which complain that patches are missing or that number of faces on patches do not match. The field data also cannot be plotted, as it's missing/incomplete on the patches in question.
This is easy and quick to reproduce on the motorbike tutorial. Just put the attached createPatchDict in /system, and run the attached Allrun. snappyHexMesh write the layers fields, which createPatch doesn't update, and then redistributePar fails due to a missing patch.
[Allrun](/uploads/caae2587d08e5ceb8f99c3deacfbe3e1/Allrun)[createPatchDict](/uploads/acb1c63a321d3da71d448d90dcc0a216/createPatchDict)
EDIT: mapFields does not handle this either. command:
**mapFields -noFunctionObjects -parallelSource -parallelTarget -consistent .**
\#\# Reattaching the author to the issue ticket: @aerogt3 \#\#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/1353topoSet: No warning when using inconsistent setup2019-07-03T04:56:26ZPrashant SonakartopoSet: No warning when using inconsistent setup### Functionality to add/problem to solve
When setup is inconsistent, e.g. type cellSet, while source e.g. boxToFace, there is no warning/ error.
The cellSet is created with faces as labels. This should be checked for consistency.
@mark### Functionality to add/problem to solve
When setup is inconsistent, e.g. type cellSet, while source e.g. boxToFace, there is no warning/ error.
The cellSet is created with faces as labels. This should be checked for consistency.
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/1340low limit of cut-off frequency ignored in surfaceNoise2020-03-09T06:15:06ZAdminlow limit of cut-off frequency ignored in surfaceNoisesurfaceNoise ignores the fl when writting the 1/3-data of SPL and PSD. That means the data of 1/3 SPL and PSDlower than fl are still written to files. The problem can be reproduced using the vortexShed tutorials.
Link to EP:
https://...surfaceNoise ignores the fl when writting the 1/3-data of SPL and PSD. That means the data of 1/3 SPL and PSDlower than fl are still written to files. The problem can be reproduced using the vortexShed tutorials.
Link to EP:
https://exchange.openfoam.com/node/1038
Son.
\## Reattaching the author to the issue ticket: @SonVo ##v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/606paraFoam does not always re-read faceSets/cellSets2021-07-15T19:55:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam does not always re-read faceSets/cellSets- case with sets
- enable 'With Sets'
- switch off caching (though not sure if relevant)
- select some sets
All ok. But now change time (to time without sets) and change back.
- Refresh (since caching switched off)
- Update GUI -> gui sh...- case with sets
- enable 'With Sets'
- switch off caching (though not sure if relevant)
- select some sets
All ok. But now change time (to time without sets) and change back.
- Refresh (since caching switched off)
- Update GUI -> gui shows sets again
- Filters->Extract Block : does not show the sets being present
The only way to actually get the sets back is to deselect one of the sets, apply and re-select.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/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/1126function object properties can only handle a single output2018-12-14T18:18:56ZMark OLESENfunction object properties can only handle a single outputthe sampled surfaces function object can contain several surfaces, but when it only has a single property to save the information. Eg,
Input:
```
plane0
{
type surfaces;
...
surfaces
(
planeA { ... }
...the sampled surfaces function object can contain several surfaces, but when it only has a single property to save the information. Eg,
Input:
```
plane0
{
type surfaces;
...
surfaces
(
planeA { ... }
planeB { ... }
);
```
uniform/functionObjects/functionObjectProperties
```
plane0
{
U
{
file "<case>/postProcessing/plane0/0.03/U_planeB.vtk";
}
}
```
possibly relevant for #1091 @andyv1906