Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-02-12T21:24:05Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2320snappyHexMesh addLayer extrudes nearby patches2024-02-12T21:24:05ZJunting ChensnappyHexMesh addLayer extrudes nearby patches
Hello, I have been trying to use the addLayer function in my external flow studies. At the moment, I don't have very good control of layer generation near feature edges. So instead of generating layers on all walls, I find that only hav...
Hello, I have been trying to use the addLayer function in my external flow studies. At the moment, I don't have very good control of layer generation near feature edges. So instead of generating layers on all walls, I find that only having layers on bottom surfaces is pretty easy to be done (which means generated layers do not run into each other).
Now I am trying to extend the usage of layer generation in my studies - I would like to use layers on the elevated horizontal surfaces. If you look at the image below, I meshed a box sitting in the domain with layers on the ground and top patch of the box. The box sides and top are created as two different boundaries.
One issue I found is that the layer generation on the top patch of the box extruded the side patches (green lines). Is this behavior intended? Or is there a way to avoid the side patches to be extruded?
![image](/uploads/57c514b0c55c3dc165bc053666a92759/image.png)
My add layer dictionary looks like this:
```
addLayersControls
{
relativeSizes yes;
thicknessModel firstAndRelativeFinal;
firstLayerThickness 0.10;
finalLayerThickness 0.80;
minThickness 0.1; //Minimum overall thickness of all layers, below which surface is not extruded
nGrow 0; //Close to the features and patches where the layers are not grown, the layer growth can be delayed.
// Value gives number of layers of cells where point extrusion is cancelled. With default value 0 points are extruded directly next to the feature.
featureAngle 160; //Angle above which surface is not extruded
nSmoothSurfaceNormals 3; //Number of smoothing iterations of surface normals
nSmoothThickness 10; //Smooth layer thickness over surface patches
minMedialAxisAngle 90; //Angle used to pick up medial axis points
nSmoothNormals 5; //Number of smoothing iterations of interior mesh movement direction
nBufferCellsNoExtrude 3; //Create buffer region for new layer terminations, i.e. gradually step down number of layers. Set to less than 0 to terminate layer in one go
nLayerIter 30; //Overall max number of layer addition iterations
nRelaxIter 5;
nRelaxedIter 20; //Number of relaxation steps (where relaxed mesh quality parameters are used)
mergePatchFacesAngle 130; //Merging multiple faces into one big face generally helps with layer addition.
//Default
maxFaceThicknessRatio 0.5; //Face thickness ratio above which surface is not extruded, useful for warped cells
maxThicknessToMedialRatio 0.3; //Will reduce the layer growth where ratio of thickness to medial distance is large (typically in narrow cavities)
slipFeatureAngle 30; //Allow the sliding of points on the patch without the layer grown if angle to the patch extrusion direction is larger.
layerTerminationAngle -180; // Do not extrude around sharp edge if not both faces are extruded. Set to -180 always attempt extrusion
layers
{
g-inner
{
nSurfaceLayers 5;
}
g-outer
{
nSurfaceLayers 5;
}
w-study-roof
{
nSurfaceLayers 5;
}
}
// Advanced settings
meshShrinker displacementMotionSolver;
solver displacementLaplacian;
displacementLaplacianCoeffs
{
diffusivity quadratic inverseDistance 1(wall);
}
// Additional reporting: if there are just a few faces where there
// are mesh errors (after adding the layers) print their face centres.
// This helps in tracking down problematic mesh areas.
additionalReporting true;
}
```https://develop.openfoam.com/Development/openfoam/-/issues/2321problem with converting chemkin file into OpenFoam format2022-01-17T16:44:08ZAmir Rezaproblem with converting chemkin file into OpenFoam formathi guys, I hope that you are doing well
I stuck in converting my mechanisms from Chemkin format into OpenFoam format.
You can find my 3 chemkin files in attachment.
When I use chemkintofoam comand to convert the files to openFOAM format...hi guys, I hope that you are doing well
I stuck in converting my mechanisms from Chemkin format into OpenFoam format.
You can find my 3 chemkin files in attachment.
When I use chemkintofoam comand to convert the files to openFOAM format, I get the error:
--> FOAM FATAL IO ERROR:
"ill defined primitiveEntry starting at keyword 'N2' on line 1 and ending at line 50"
file: trans_chemkin.dat at line 50.
From function void Foam:rimitiveEntry::readEntry(const Foam::dictionary&, Foam::Istream&)
in file db/dictionary/primitiveEntry/primitiveEntryIO.C at line 168.
I tried different tricks but no one works till now
Does any body any solution for that?
Thanks in advance guys
[C2H4_DNS_41Spec_.zip](/uploads/3c67a5587aa976742304e179f30e935e/C2H4_DNS_41Spec_.zip)https://develop.openfoam.com/Development/openfoam/-/issues/2322bad variable use for lib configuration2022-01-11T17:02:31ZMark OLESENbad variable use for lib configurationsnuck in with 4a064645 as noted by @Mortesinssnuck in with 4a064645 as noted by @MortesinsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2323BUG: mapFieldsPar does not like old-time fields & does not write uniform/ dir...2022-01-17T11:01:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: mapFieldsPar does not like old-time fields & does not write uniform/ directory<!--
*** 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 re...<!--
*** 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 -->
mapFieldsPar does not map old-time fields. Also does not write uniform/ directory (but should it?)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- copy pimpleFoam/RAS/pitzDaily
- change ddtScheme to backward;
- change 'stopAt' to 'writeNow'
- run for one iteration in parallel
- map results back to original:
```
mpirun -np 2 mapFieldsPar -parallel ../pitzDaily_junk -sourceTime latestTime
```
This seems to generate some sigFpe or illegal values in k, epsilon.
### Example case
See above
<!--
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
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
### 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
-->
- was thinking it might be the _0 field being auto-created but not initialised. Then when mapping _0 it would load this auto-generated field and crash. However this does not seem to be the case.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2324BUG: MappedFile: different fieldTable names are not possible in parallel or r...2022-04-08T14:50:49ZKutalmış BerçinBUG: MappedFile: different fieldTable names are not possible in parallel or restart runs<!--
*** 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 re...<!--
*** 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
In MappedFile.C, `fieldTableName_` is written outside the `Coeffs` block when `MappedFile` writes out its metadata, say for `decomposePar`/`redistributePar` executions.
This does not cause any issues when `fieldTableName_` does not differ from the `entryName`, which is the default value.
However, when the simulation is being run in parallel or is being restarted, `fieldTable` entry is not being read by the caller, but the default value only. Therefore, any parallel or restart run in such configuration becomes problematic.
```
os.writeEntryIfDifferent
(
"fieldTable",
this->name(),
fieldTableName_
);
os.beginBlock(word(this->name() + "Coeffs"));
//--> fieldTableName_ should be written herein.
writeEntries(os);
os.endBlock();
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
base0 = base
base1 = develop
api = 2112
patch = 0
HEAD = 34e226dfe3
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.3
opts = linux64ClangDPInt32Opt
### 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 tested potential-fix patch (FYI: @mark ): [0001-BUG-MappedFile-ensure-correct-fieldTableName-can-be-.patch](/uploads/605abe4f52315864cd4ddee9c79e227c/0001-BUG-MappedFile-ensure-correct-fieldTableName-can-be-.patch)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2325Extension to comfort library -> operative Temperature calculation2022-01-18T15:44:06ZTobias HolzmannExtension to comfort library -> operative Temperature calculation### Functionality to add/problem to solve
Hey everybody, I updated the comfort library to accommodate the calculation of the operative temperature.
This is actually very simple as it is the arithmetic mean value of the air temperature o...### Functionality to add/problem to solve
Hey everybody, I updated the comfort library to accommodate the calculation of the operative temperature.
This is actually very simple as it is the arithmetic mean value of the air temperature of each cell and the mean radiative temperature of each cell.
There are two options now:
a) No radiation model in use.
b) Radiation model in use
For a) is already working as the user either specify a single value (in the FO dictionary) or a constant radiation temperature is derived from all walls given inside the geometry (its the mean temperature of all walls followed by the VDI2078). Hence, the patch added is sufficient to calculate the operative temperature
For b) I will go to implement the black body radiation calculation based on the G field as the operative temperature is a hypothesis based on a black body room. So while a user specifies the radiation model, each cell can be evaluated for the black body radiation temperature and hence the operative temperature can be directly calculated (not given in this patch but will follow).
### Target audience
Civil and Pharma-Industries.
### Proposal
Simply use the patch given (simply a few lines added)
### What does success look like, and how can we measure that?
Difficult.
### Links / references
EN ISO 7730
ASHRAE-55
VDI2078
[comfort.C](/uploads/024f07f065fc9436e1683c629855879f/comfort.C)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2326Outdated links to Doxygen2022-01-14T14:34:46ZGerasimos ChourdakisOutdated links to DoxygenA few months ago, the documentation was moved:
```diff
- https://www.openfoam.com/documentation/cpp-guide/html/
+ https://www.openfoam.com/documentation/guides/latest/doc/
```
However, the links (also in v2112) are still pointing to th...A few months ago, the documentation was moved:
```diff
- https://www.openfoam.com/documentation/cpp-guide/html/
+ https://www.openfoam.com/documentation/guides/latest/doc/
```
However, the links (also in v2112) are still pointing to the old one, in these files:
- https://develop.openfoam.com/Development/openfoam/-/blob/master/etc/controlDict#L29
- https://develop.openfoam.com/Development/openfoam/-/blob/master/tutorials/incompressible/pimpleFoam/LES/decayIsoTurb/README.md#L13
- https://develop.openfoam.com/Development/openfoam/-/blob/master/tutorials/incompressible/simpleFoam/turbulentFlatPlate/README.md#L16
- https://develop.openfoam.com/Development/openfoam/-/blob/master/tutorials/verificationAndValidation/schemes/divergenceExample/README#L17
This issue could also be read as "the automatic redirection of the website does not work for specific pages", as the link to, e.g., [postProcess_8C.html](https://www.openfoam.com/documentation/cpp-guide/html/postProcess_8C.html) just redirects to the main page.
By the way, awesome feature of providing a `-doc` flag, as in `postProcess -doc`!
(I am not sure if I could have even directly contributed code here, as this is a trivial fix)https://develop.openfoam.com/Development/openfoam/-/issues/2327fixedJump bc does not work for T2022-12-23T15:00:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfixedJump bc does not work for T<!--
*** 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 re...<!--
*** 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 -->
fixedjump bc does not work for solving T
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
See attached case. Allrun. Check temperature across cyclic, cyclicAMI.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Jump in he (which is what is solved for) is determined from jump instead of T+jump.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
[TJunctionFan.tgz](/uploads/bb2fcb741f75a4df3fc2fa906ab40ef1/TJunctionFan.tgz)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2328Mismatch between user and physical time when adapting the time precision2022-01-21T12:33:30ZIvor CliffordMismatch between user and physical time when adapting the time precision<!--
*** 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 re...<!--
*** 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
I am developing a new solver in which I derive from Foam::Time and override the virtual functions Foam::TimeState::userTimeToTime, etc. While doing this, I noticed that OpenFOAM unexpectedly increases the write precision, which seems to be due to mismatches between user- and physical time in OpenFOAM's time classes. See the proposed source of problem below.
### Steps to reproduce
This bug is not related to any specific usage of the code.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
- Operating system : Ubuntu 20.04
- Hardware info : Intel 64 bit
- Compiler : Gcc 8.2
### 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
-->
After some debugging, I think I found the issue. At [Time.C:1287](../9a2a22a03/src/OpenFOAM/db/Time/Time.C#L1287)
```c
// Tolerance used when testing time equivalence
const scalar timeTol =
max(min(pow(10.0, -precision_), 0.1*deltaT_), SMALL);
```
Here the physical time is used to define the tolerance for increasing the time precision, but a few lines down (1302) this is compared against the user time. This mismatch causes the precision to unexpectedly increase.
A second issue I noted is that, on line 1292, userDeltaT is determined using the function `timeToUserTime`. This is only correct if the user time is a linear function of the physical time. It would be better to calculate this as:
```c
const scalar userDeltaT = timeToUserTime(value()) - timeToUserTime(value() - deltaT_);
```Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2329BUG: turbulentDigitalFilterInlet: Forward-stepwise option is inoperative2022-06-07T20:17:09ZKutalmış BerçinBUG: turbulentDigitalFilterInlet: Forward-stepwise option is inoperative<!--
*** 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 re...<!--
*** 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
In `turbulentDigitalFilterInletFvPatchVectorField.C`, the following assignment operation is inoperative:
```
for (direction dir = 0; dir < pTraits<vector>::nComponents; ++dir)
{
U.component(dir) =
U0_.component(dir)*coeffs1FSM_[dir]
+ U.component(dir)*coeffs2FSM_[dir];
}
```
The LHS `U.component(dir) = ` is unassignable; therefore, the content of `U` has never been altered by the intended RHS operations.
For this reason, `DFM` was acting as a single-cell box rather than the `FSM` simplifications are in effect.
This situation should have adverse effects on integral scale syntheses (which is luckily not considerably important), and should not have any effect on Reynolds stresses or mean quantities.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
base0 = base
base1 = develop
api = 2112
patch = 0
HEAD = befbcfce24
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.3
opts = linux64ClangDPInt32Opt
### 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
-->
```
for (direction dir = 0; dir < pTraits<vector>::nComponents; ++dir)
{
U.replace
(
dir,
U0.component(dir)*coeffs1FSM_[dir] + U.component(dir)*coeffs2FSM_[dir]
);
}
```v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2330Bug in new implicit Conjugate heat transfer Solver2022-03-30T10:43:17ZFeng ZhuBug in new implicit Conjugate heat transfer Solver<!--
*** 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 re...<!--
*** 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
I am highly appreciate the implicit coupled patch which has been released in v2112.
I also understand it is more than a boundary condition since in conjugate heat transfer solver, if it detects implicit patch, it will solve all regions in one matrix. This leads a very fast convergence. This is a desirable solver which we have been chasing many years in OF. However, I think I found a suspcious bug in this new solver.
In the coupled patch, it will calculate a source term to balance the enthalpy jump between different region in coupled patch in following code.
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/TurbulenceModels/compressible/turbulentFluidThermoModels/derivedFvPatchFields/turbulentTemperatureRadCoupledMixed/turbulentTemperatureRadCoupledMixedFvPatchScalarField.C#L545
However, if you compare the result of new implicit coupled CHT solver with original segregated solver. In steady state CHT, When solution reach convergence , the solid temperature would be less than segregated solver. In fact, the segregated solver has good temperature correlation with other commercial software. I highly think this source term affects the results. I know if I remove this source to keep it as zero, the temperature will get a wierd results. However, if I do a trick in steady state solver, like setup all the Cp in solid region same as fluid, then I can get a perfect result with similar leverl temperature as segregated CHT solver and other commercial software. Also, if you check the final results wall heat flux, in implicit solver, some solid region not reach the wall heat flux balance. Example, in tutorial CpuCabinet case, Fin. The problem is theoratically, in steady state, the Cp should not affect the final results. Therefore, I think use this formula source to balance enthalpy jump is a problem.
Could you please check it?
Cheers,
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Just use implicit CHT solver
<!-- How one can reproduce the issue - this is very important -->
### Example case
even for tutorial CpuCabinet.
<!--
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?
gives lower temperature and imbalance wall heat flux.
<!-- What actually happens -->
### What is the expected *correct* behavior?
similary level temperatuer as before, and balanced heat flux
<!-- 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 : v2112
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
- 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
-->Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/2331snappyHexMesh consistent parallel v.s. serial refinement2022-11-28T15:04:20ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh consistent parallel v.s. serial refinement### Functionality to add/problem to solve
When running snappyHexMesh in parallel it might not give the exact same result as running non-parallel
### Proposal
Run serial and parallel side-by-side. Make sure refinement is exactly the sa...### Functionality to add/problem to solve
When running snappyHexMesh in parallel it might not give the exact same result as running non-parallel
### Proposal
Run serial and parallel side-by-side. Make sure refinement is exactly the same.
E.g. Tutorial `mesh/snappyHexMesh/gap_detection` and have `random` decomposition.
See also https://exchange.openfoam.com/node/1691.
### What does success look like, and how can we measure that?
Better parallel consistent behaviour. There might still be areas which are not exactly the same just due to e.g. the truncation errors in calculating the face- and cell-centres (different point ordering or orientation of face on processor patch, different ordering of faces in cell)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2332reduce communication for globalIndex gather operations2022-02-11T19:03:12ZMark OLESENreduce communication for globalIndex gather operations- add in mpiGatherOp() to complement the gatherOp() static method
- populate globalIndex on master only: avoid gather/scatter list expense- add in mpiGatherOp() to complement the gatherOp() static method
- populate globalIndex on master only: avoid gather/scatter list expenseMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2334STYLE: volFieldValue: prints empty lines2022-01-24T21:55:20ZKutalmış BerçinSTYLE: volFieldValue: prints empty lines<!--
*** 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 re...<!--
*** 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 -->
In `$FOAM_TUTORIALS/incompressible/pisoFoam/RAS/cavity`, prior to the first time-step, many empty lines are being printed.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cd $FOAM_TUTORIALS/incompressible/pisoFoam/RAS/cavity
./Allrun
```
Inspect `log.pisoFoam` prior to `Time = 0.005`.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
base0 = base
base1 = develop
api = 2112
patch = 0
HEAD = 0d3e84eb10
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.3
opts = linux64ClangDPInt32Opt
### 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
-->
The culprit is the [volFieldValue.C#L284](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/functionObjects/field/fieldValues/volFieldValue/volFieldValue.C#L284). Reconsidering it should resolve the issue.
@markv2206https://develop.openfoam.com/Development/openfoam/-/issues/2339Docs: Debian 11.2 compile Patch Release OpenFOAM-9-202111222024-01-09T12:07:03ZPhilipDocs: Debian 11.2 compile Patch Release OpenFOAM-9-20211122Hello, maintaining documentation is challenging as code and host infrastructure advances, so you might appreciate feedback from someone looking at the documentation with fresh eyes. Here are some documentation issues I encountered while ...Hello, maintaining documentation is challenging as code and host infrastructure advances, so you might appreciate feedback from someone looking at the documentation with fresh eyes. Here are some documentation issues I encountered while compiling Patch Release OpenFOAM-9-20211122 on current Debian stable 11.2.
1. Good news -- currently Debian stable repository provides paraview 5.9.0-2 and libscotch 6.1 and libptscotch-6.1, so this might simplify the Third Party install process and instructions.
In particular the Debian comments in https://openfoam.org/download/source/third-party-software/ appear to be obsolete.
2. The documentation leaves me wondering whether compiling the third party tools are essential if newer libscotch and paraview are installed.
Running ./Allwmake does compile libscotch, perhaps an older version 6.0.9. It's possible that one wants exactly that version; if so it would be helpful to say so.
3. In the case that the user uses the repository paraview, it's not clear
a) Whether it is a concern that the following environment variables are set incorrectly,
b) Whether they are needed
c) Where (in/by which script) they are being created:
`ParaView_GL=mesa
ParaView_MAJOR=5.6
ParaView_VERSION=5.6.3
ParaView_DIR=/.../openfoam/ThirdParty-9/platforms/linux64Gcc/ParaView-5.6.3`
4. The documentation is clear about how to compile the official release. It is clear about compiling the dev version. It is not as clear about the patch releases. It appears to me that compiling the patch releases is most similar to compiling the dev version, with changes to directory names. No doubt this is perfectly clear for all to whom it is obvious.
5. In some projects, non-experts might be recommended to use the better tested official release unless a patch release addresses their problems. In other projects, the patch release is considered better than the first release. The OpenFOAM.org website structurally appears to favor the official release, guiding one to https://openfoam.org/download/9-source/ , and not clearly referring to the patch release, which appears like a news item in a link in the right margin. This together with (4) may give the impression that the patch releases are of lesser interest.
6. This might be out of scope here, but the documentation at openfoam.com, https://develop.openfoam.com/Development/openfoam/-/wikis/modules/visualization#do-i-really-need-the-paraview-plugins
suggests using "paraFoam -vtk"; the openfoam.org release of paraFoam does not appear to have that option -vtk; perhaps the .com release has that option.https://develop.openfoam.com/Development/openfoam/-/issues/2340AMI patch addressing fails, solver crashes when using cellZone created via to...2022-01-27T18:17:03ZAaronAMI patch addressing fails, solver crashes when using cellZone created via topoSetI have a rather strange issue, and I have tried every workaround I can think of with no success.
When running AMI + mesh motion, I'm able create isoSurfaces at run time, including limiting them to a specific cellZone via the "zone" entr...I have a rather strange issue, and I have tried every workaround I can think of with no success.
When running AMI + mesh motion, I'm able create isoSurfaces at run time, including limiting them to a specific cellZone via the "zone" entry. However, the AMI patch addressing crashes **if the cellZone I choose was generated via topoSet** - in my case using searchable surfaceToCell. logFiles:
[log.FAIL_production_pimpleFoam](/uploads/5fcb503a3e1e4aef27dcfa41a6045a66/log.FAIL_production_pimpleFoam)
[log.FAIL_tutorial_pimpleFoam](/uploads/626ccf1356e670d249897f48d676ebed/log.FAIL_tutorial_pimpleFoam)
Luckily, the issue can be easily reproduced with the rotatingFanInRoom tutorial. Steps:
1. run Allrun.pre
2. topoSet -time constant -constant -dict system/topoSetTest, using attached STL and topoSetDict [topoSetTest](/uploads/b50961d196f2a6053f0669f29c0f54c2/topoSetTest)[searchableStl.stl](/uploads/6679d91d573ad0df56bd3d033ca3dc18/searchableStl.stl)
3. check mesh to verify the new cellZone exists and has cells
```
Checking basic cellZone addressing...
CellZone Cells Points VolumeBoundingBox
rotatingZone 26544 35177 1.043 (-3.789551 1.210449 2.256408) (-2.210449 2.789551 2.8)
**fluid_test** **1154** 1725 1.169422 (-4.411605 1.29768 1.205809) (-1.691286 2.813284 1.512392)
```
4. Solve using the attached controlDict (or add the lines below to controlDict.functions) [controlDict](/uploads/40e9bb83130cf924a1acf3475f5826a8/controlDict)
5. Of note is that using the other cell zone, created by snappy, works fine.
```
runTimeObj_isoQ
{
timeStart 0;
type surfaces;
libs (sampling);
executeControl timeStep;
executeInterval 1;
writeControl timeStep;
surfaceFormat vtk;
writeInterval 1;
fields (U p);
surfaces
{
qIsoSurf
{
type isoSurface;
interpolate true;
store true;
isoField p;
isoValue 0;
zone fluid_test;
}
}
}
```https://develop.openfoam.com/Development/openfoam/-/issues/2341waves distorted with overCompressibleInterDyMFoam2022-11-11T20:33:37ZGrzegorzwaves distorted with overCompressibleInterDyMFoam<!--
*** 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 re...<!--
*** 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 compressible variant of the overset multiphase solver overCompressibleInterDyMFoam strongly distorts waves propagating through the domain. The incompressible solver overInterDyMFoam does not show this behavior.
![wave-elevation](/uploads/aff28480d0a62424a3121b2a45043590/wave-elevation.png)
### Steps to reproduce
1. Generate an "empty" overset grid where no body is present within the overset region. The empty overset region is nested in the background region, for example:
![grid](/uploads/08a2edb861dd12ec939bbf57382a9723/grid.png)
2. Setup the wave simulation using the constant/waveProperties dict, and wave generation boundary conditions waveAlpha and waveVelocity.
3. Simulate using the overInterDyMFoam and overCompressibleInterDyMFoam solvers for comparison.
### Example case
[bug_report.tgz](/uploads/41bd1747153295e0bdd9254694712081/bug_report.tgz)
### What is the current *bug* behaviour?
The wave field is distorted and does not resemble the expected wave profile when compared to something like Stokes 5th order theory.
### What is the expected *correct* behavior?
The wave field should be the same as with the incompressible solver and similar to the expected wave profile.
### 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 : v2106
Operating system : ubuntu
Compiler : gcc
-->
- OpenFOAM version : v2106
- Operating system : ubuntu
- Compiler : gcc
### 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2342volAverage volume output2022-01-31T08:36:25ZGabriel AxtmannvolAverage volume output
Volume output of a changing cellZone,for example a moving piston would be nice
Volume output of a changing cellZone,for example a moving piston would be nicehttps://develop.openfoam.com/Development/openfoam/-/issues/2343bug in atmPlantCanopyUSource2022-05-06T10:02:08ZNima Samkhanianibug in atmPlantCanopyUSourceThe current explicit implementation of source term leads to numerical divergence,
writing the source terms in the implicit format will solve the issue, a new implementation of the source term with a sample test case is attached
[atmPlan...The current explicit implementation of source term leads to numerical divergence,
writing the source terms in the implicit format will solve the issue, a new implementation of the source term with a sample test case is attached
[atmPlantCanopyUSource.zip](/uploads/5c992f90db1fe1542d8cca08aed19d22/atmPlantCanopyUSource.zip)
[test-case.zip](/uploads/8c9bfe352a0ca89c64f37a007f8fdc4d/test-case.zip)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2344Thermal resistance layer(s) not accounted for in turbulentTemperatureRadCoupl...2022-04-14T12:24:14ZLieven VerveckenThermal resistance layer(s) not accounted for in turbulentTemperatureRadCoupledMixedFvPatchScalarField
### Summary
The thermal resistance layers are not properly taken into account in the turbulentTemperatureRadCoupledMixed boundary condition (possibly the same problem in other boundary conditions as well).
### Steps to reproduce
Add ...
### Summary
The thermal resistance layers are not properly taken into account in the turbulentTemperatureRadCoupledMixed boundary condition (possibly the same problem in other boundary conditions as well).
### Steps to reproduce
Add a thermal resistance, either as contactLayer or as contactLayers, to a multi-region heat heat transfer case.
### Example case
Any multi-region tutorial will do.
### What is the current *bug* behaviour?
The temperatures do not change when adding the resistance layer(s).
### What is the expected *correct* behavior?
~~A temperature difference between the two regions at the interface.~~
A change in temperatures of the interface and regions
### Environment information
- OpenFOAM version : v2112
- Operating system : CentOS
- Compiler : gcc
### Possible fixes
Possible fix attached as patch file (only tested in non-implicit mode). It was set up based on the v2012 version of the code.[turbulentTemperatureRadCoupledMixedFvPatchScalarField.patch](/uploads/80d9c93935f449426bf423c69adc2ed5/turbulentTemperatureRadCoupledMixedFvPatchScalarField.patch)