Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-07-06T16:36:42Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1512Porting OpenFOAM to Windows2021-07-06T16:36:42ZAdminPorting OpenFOAM to WindowsHello,
Yesterday I have opened an [issue about OpenFOAM filenames in Windows](https://github.com/blueCFD/Core/issues/136) in BlueCFD project. Bruno, told me to open an issue here as well. This might be a potential solution to the probl...Hello,
Yesterday I have opened an [issue about OpenFOAM filenames in Windows](https://github.com/blueCFD/Core/issues/136) in BlueCFD project. Bruno, told me to open an issue here as well. This might be a potential solution to the problem of file naming in Windows (case insensitive).
In summary:
* Windows 10 now offers an optional case-sensitive file system, just like Linux and other UNIX-like operating systems. But this could be enabled on per-directory basis.
* Newer C++ compilers that support C++17, have `__has_include` feature for conditional including.
\## Reattaching the author to the issue ticket: @samir1291 ##https://develop.openfoam.com/Development/openfoam/-/issues/1790Position interpolation in tabulated6DoFMotion does not give expected result2020-08-04T15:08:53ZMike WorthPosition interpolation in tabulated6DoFMotion does not give expected result<!--
*** 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
When the position of a dynamic mesh is calculated using tabulated6DoFMotion, the result is neither intuitive nor smooth. I don't know enough about the purported method to know if it's a bug or just not a very suitable algorithm.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
With at least 4 defined steps, define a motion that moves, pauses and returns. Example below:
<!-- How one can reproduce the issue - this is very important -->
### Example case
dynamicMeshDict:
```
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1912 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object dynamicMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
dynamicFvMesh dynamicOversetFvMesh;
dynamicOversetFvMeshCoeffs
{
// layerRelax 0.3;
}
solver multiSolidBodyMotionSolver;
multiSolidBodyMotionSolverCoeffs
{
movingZone
{
solidBodyMotionFunction tabulated6DoFMotion;
tabulated6DoFMotionCoeffs
{
CofG (0.001 0.001 0.001);
timeDataFileName "constant/dipMotion.dat";
}
}
}
// ************************************************************************* //
```
Dipmotion.dat:
```4 //number of data points in the file
//Position formatting is not important. File is based on the character sequence only.
//Vectors are not relative. Each vector is total displacement and total rotation.
(
//(time_point ( (linear displacement vector) (rotation vector) ) )
//(seconds ( (following unit system, usually meters) (radians) ) )
(0 ( (0 0 0) (0 0 0) ) )
(4.19042 ( (0 -0.159236 0) (0 0 0) ) )
(5.19042 ( (0 -0.159236 0) (0 0 0) ) )
(38.141 ( (0 0.05 0) (0 0 0) ) )
)
```
<!--
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?
Instead of pausing between the middle two times (as would be expected from linear interpolation), there is a rapid further movement. See below for a graph where I've re-implemented the interpolateSplineXY.C algorithm to investigate what it returns:
![image](/uploads/5067c1cff761d69a58c1dca81dc50108/image.png)
<!-- What actually happens -->
### What is the expected *correct* behavior?
Interpolation should either be linear (which would potentially cause problems with derivative values being high/undefined), or should approximate to linear with rounded corners of some kind.
<!-- 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 : 1912 & 2006
- Operating system : Ubuntu 18.04
- Hardware info :
- Compiler :
### Possible fixes
Either use a different interpolation method here, or adjust what values the existing one returns:
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/dynamicMesh/motionSolvers/displacement/solidBody/solidBodyMotionFunctions/tabulated6DoFMotion/tabulated6DoFMotion.C#L93
<!--
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/2230Possibility to test scaling on the LUMI supercomputer2022-10-04T12:25:05ZTimofey MukhaPossibility to test scaling on the LUMI supercomputerDear all,
I am working with a group that will get pilot access to the CPU partition of the new Finnish supercomputer called LUMI, starting 18th of Oct. Some info about the machine can be found here: https://www.lumi-supercomputer.eu/may...Dear all,
I am working with a group that will get pilot access to the CPU partition of the new Finnish supercomputer called LUMI, starting 18th of Oct. Some info about the machine can be found here: https://www.lumi-supercomputer.eu/may-we-introduce-lumi/
It will be a pretty bare-bone environment, but if I manage to get OF compiled, there is a possibility to run scaling tests of OpenFOAM solvers. So, while **I can't promise anything**, I would like to open a discussion regarding what tests would be good to run. Even better would be if we already have some cases prepared. Perhaps the HPC committee has input?https://develop.openfoam.com/Development/openfoam/-/issues/342possible allocation issues in fluxSummary2018-05-29T05:39:49ZMark OLESENpossible allocation issues in fluxSummary@andy@andyVersion v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/761(Possible) BUG: foamToVTK - FOAM FATAL ERROR - in channel395DFSEM of OpenFOAM...2019-12-09T22:18:10ZKutalmış Berçin(Possible) BUG: foamToVTK - FOAM FATAL ERROR - in channel395DFSEM of OpenFOAM v1712Hi,
Please consider the following MWE:
* The case is mostly based on the tutorial: `pimpleFoam/LES/channel395DFSEM`
* The minimum case set-up and complete error message can be found in the attachment: [bug.tar.gz](/uploads/c555d176a57...Hi,
Please consider the following MWE:
* The case is mostly based on the tutorial: `pimpleFoam/LES/channel395DFSEM`
* The minimum case set-up and complete error message can be found in the attachment: [bug.tar.gz](/uploads/c555d176a573193065d4e56b38e57cce/bug.tar.gz)
* Operating system: Red Hat Enterprise Linux Server release 6.3 (Santiago)
* OpenFOAM version: 1712
* nProcs: 16
Subsequent to the job completion, I successfully executed `reconstructPar -latestTime`. Then executing `foamToVTK -latestTime` returned the error below (the complete error message file is in the attachment):
> --> FOAM FATAL ERROR:
> Not implemented
>
> From function virtual Foam::label Foam::cyclicPolyPatch::neighbPatchID() const
> in file faMesh/faPatches/constraint/cyclic/cyclicFaPatch.C at line 286.
>
> FOAM aborting
>
> #0 Foam::error::printStack(Foam::Ostream&) in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #1 Foam::error::abort() in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #2 Foam::cyclicPolyPatch::neighbPatchID() const in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libfiniteArea.so"
> #3 Foam::cyclicPolyPatch::neighbPatch() const in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #4 Foam::cyclicPolyPatch::calcGeometry(Foam::PstreamBuffers&) in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #5 Foam::polyBoundaryMesh::calcGeometry() in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #6 Foam::polyMesh::polyMesh(Foam::IOobject const&) in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
> #7 Foam::fvMesh::fvMesh(Foam::IOobject const&) in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so"
> #8 ? in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/bin/foamToVTK"
> #9 __libc_start_main in "/lib64/libc.so.6"
> #10 ? in "/scratch/kb8e10/OpenFOAM/OpenFOAM-v1712/platforms/linux64GccDPInt32Opt/bin/foamToVTK"
> Aborted (core dumped)
When I executed the same command `foamToVTK -latestTime` with **OF1706** onto the same case, the error disappeared (I attached its response into the tar.gz as well).
I can also provide further information that you think necessary.
Kind regardshttps://develop.openfoam.com/Development/openfoam/-/issues/2069Possible bug in Fuchs-Knudsen evaporation model2021-12-09T20:12:57ZCarlos Peña-MonferrerPossible bug in Fuchs-Knudsen evaporation model<!--
*** 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 -->
Fuchs-Knudsen evaporation model instantly evaporates the active liquid phase. There is apparently a missing variable, particle surface area, in the calculation of the mass transfer according to the reference paper (Eq. 20 in https://doi.org/10.1016/j.jaerosci.2016.12.001). I made some calculation tests adding the particle surface area and then the model gives reasonable results.
### 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 : v2012
- Operating system : N/A
- Hardware info : N/A
- Compiler : N/A
### 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
-->
Adding particle surface area to the calculation on line 257 on
$FOAM_SRC/lagrangian/intermediate/submodels/Reacting/PhaseChangeModel/LiquidEvapFuchsKnudsen/LiquidEvapFuchsKnudsen.C
```
- // mass flux [kg/s]
- const scalar Ni = (rhog*Sherwood*Dab*Cm/d)*log((1 - YeInf)/(1 - YeSurf));
- // mass transfer [kg]
- dMassPC[lid] += Ni*dt;
+ // mass flux [kg/m2/s]
+ const scalar Ni = (rhog*Sherwood*Dab*Cm/d)*log((1 - YeInf)/(1 - YeSurf));
+ // mass transfer [kg]
+ dMassPC[lid] += Ni*areaS*dt;
```
I passed `areaS` to the `calculate` function as `this->areaS(d)`.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1761possible bug in `pressureDirectedInletOutletVelocity` BC2020-09-06T10:25:43ZArashpossible bug in `pressureDirectedInletOutletVelocity` BC<!--
*** 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
`pressureDirectedInletOutletVelocity` is a mixed BC. Yet, I'm not sure if [this](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v1912/src/finiteVolume/fields/fvPatchFields/derived/pressureDirectedInletOutletVelocity/pressureDirectedInletOutletVelocityFvPatchVectorField.C#L205) operator is assigning the correct value. I didn't dig in the code, yet, `pvf` must be either a `refValue` or `refGrad` and in either case, this expression doesn't satisfy the following properties stated [here](https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-outlet-pressure-inlet-outlet.html):
>- Flow out of the domain: assigns a zero gradient condition
>- Flow into the domain: assigns a velocity based on the flux in the patch-normal direction [or in this case the `inletDir`]
### What is the expected *correct* behavior?
It should be something like [this](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v1912/src/finiteVolume/fields/fvPatchFields/derived/pressureInletOutletVelocity/pressureInletOutletVelocityFvPatchVectorField.C#L212) from the `pressureInletOutletVelocity`v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1349possible build issue with non-MPI vtk and runTimePostProcessing2019-07-02T09:40:17ZMark OLESENpossible build issue with non-MPI vtk and runTimePostProcessingFlagged by @PawanFlagged by @PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1100Possible Deprecation of turbulentInlet Boundary Condition2019-12-18T16:20:29ZKutalmış BerçinPossible Deprecation of turbulentInlet Boundary ConditionHi,
**turbulentInlet** boundary condition generates fluctuating velocity fields by superimposing (pseudo-)random number sets (scaled by a given turbulence intensity) onto a reference (mean) velocity field.
https://www.openfoam.com/docu...Hi,
**turbulentInlet** boundary condition generates fluctuating velocity fields by superimposing (pseudo-)random number sets (scaled by a given turbulence intensity) onto a reference (mean) velocity field.
https://www.openfoam.com/documentation/cpp-guide/html/classFoam_1_1turbulentInletFvPatchField.html
Although this approach was proposed in the literature as the first turbulence inflow method, numerous studies quantified its ineffectiveness (refs can be provided if need be). Unfortunately, turbulence is fully deterministic and involving various spatial/temporal coherent structures, yet is random in a sense that its stochastic development cannot be predicted, again due to its acute sensitivity to initial/boundary conditions.
For example, in detail, for turbulentInlet the energy of generated time-series is equally distributed over the whole wavenumber range, that means the spectrum is approximately a horizontal line. Therefore, due to a lack of energy in the low wave number range, the pseudo turbulence is immediately damped to zero when enters into a CFD domain, and the result is virtually identical with a laminar inflow.
For these reasons, I kindly suggest a discussion as to this module's deprecation since customers/developers/users could be misled by its name and offerings.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/302Possible documentation mismatch for IDDESdelta2016-11-17T16:42:25ZRoger AlmenarPossible documentation mismatch for IDDESdeltaIn the file OpenFOAM-plus/.../IDDESDelta/IDDESDelta.C , the IDDESdelta seems to be calculated based on face2face distance, in the direction normal to the wall.
However, in the H file it is mentioned: IDDESDelta used by the IDDES (im...In the file OpenFOAM-plus/.../IDDESDelta/IDDESDelta.C , the IDDESdelta seems to be calculated based on face2face distance, in the direction normal to the wall.
However, in the H file it is mentioned: IDDESDelta used by the IDDES (improved low Re Spalart-Allmaras DES model) The min and max delta are calculated using the double distance of the min or max from the face centre to the cell centre.
Could we check if there is a mismatch between the documentation and the code?https://develop.openfoam.com/Development/openfoam/-/issues/1630Possible inconsistency in documentation2020-06-12T17:35:40ZMathieu OlivierPossible inconsistency in documentationThis is not a critical issue, but I feel it deserves some attention.
In file src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions/omegaWallFunctions/omegaWallFunction/omegaWallFunctionFvPatchScalarField.H, it is stat...This is not a critical issue, but I feel it deserves some attention.
In file src/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions/omegaWallFunctions/omegaWallFunction/omegaWallFunctionFvPatchScalarField.H, it is stated in the documentation (at the beginning of the file) that the default value of the "blended" switch is set to "false". However, by looking at the constructors in omegaWallFunctionFvPatchScalarField.C, it seems that the default value is rather set to "true". Am I missing something?
Thank you!
Mathieu Olivierv2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1155possible issues with conversion from gmsh2021-07-06T15:15:28ZMark OLESENpossible issues with conversion from gmshMentioned in the cfd-online forum https://www.cfd-online.com/Forums/openfoam-meshing/213553-meshing-error-bad-token-could-not-get-word.html by user Dewi Madden.
- could be an OpenFOAM parsing issue,
- or a syntax change in gmsh format
-...Mentioned in the cfd-online forum https://www.cfd-online.com/Forums/openfoam-meshing/213553-meshing-error-bad-token-could-not-get-word.html by user Dewi Madden.
- could be an OpenFOAM parsing issue,
- or a syntax change in gmsh format
- bad input,
- other
Diagnosis awaiting a file or two...Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/908Possible issue with reactionI.H2018-06-26T12:36:39ZMark OLESENPossible issue with reactionI.HCompile problem fedora28 reported
https://www.cfd-online.com/Forums/openfoam-installation/203125-openfoam-1712-build-error.htmlCompile problem fedora28 reported
https://www.cfd-online.com/Forums/openfoam-installation/203125-openfoam-1712-build-error.htmlMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2006Possible memory leak in setFields with surfaceToCell2021-04-08T13:48:31ZNikola MajksnerPossible memory leak in setFields with surfaceToCell
### Summary
When running setField with surfaceToCell I believe there is a memory leak. With the provided case the .obj file size is around 226 MB and setFields uses 31 GB of RAM at it's peak. Furthermore, I have tried with the file tha...
### Summary
When running setField with surfaceToCell I believe there is a memory leak. With the provided case the .obj file size is around 226 MB and setFields uses 31 GB of RAM at it's peak. Furthermore, I have tried with the file that is 770 MB and with that one RAM usage is around 215 GB at it's peak. I couldn't use the larger file as it was crashing due to not enough RAM memory.
### Steps to reproduce
Run attached case and observe memory usage when setFields command is executed
### Example case
As the case is 46 MB because of the bit larger .obj file I cannot attach it here so here is the link.
https://drive.google.com/file/d/1B4XMstiTWINkHkeTwDrl4PeJNg_wH-FC/view?usp=sharing
### What is the current *bug* behaviour?
It uses too much RAM memory.
### What is the expected *correct* behaviour?
To use way less RAM memory
### Environment information
- OpenFOAM version : v2012
- Operating system : ubuntu/docker
- Hardware info : AMD EPYC 7401P 24-Core Processor with 256 GB of RAM
- Compiler : gcchttps://develop.openfoam.com/Development/openfoam/-/issues/1402Possible mistake in omega calculation in pyrolysisChemistryModel.C2019-08-22T15:17:45ZAdminPossible mistake in omega calculation in pyrolysisChemistryModel.CHi,
I was trying to use solidChemistry and pyrolysisChemistryModel in a solver, and I was getting weird results or runtime errors (undefined behavior) for a simple case where reactions took place in a solid medium! When I tracked down t...Hi,
I was trying to use solidChemistry and pyrolysisChemistryModel in a solver, and I was getting weird results or runtime errors (undefined behavior) for a simple case where reactions took place in a solid medium! When I tracked down the runtime error, I found that the problem arises from the line 267 of pyrolysisChemistryModel.C, where we have
const scalar exp = R.lhs()[si].exponent;
where we get strange values for the "exp" variable! If you take a look at the whole block of this code:
const label Nl = R.lhs().size();
for (label s=0; s<Nl; s++)
{
label si = R.lhs()[s].index;
const scalar exp = R.lhs()[si].exponent; // This is line 267, the problematic line IMO
kf *=
pow(c1[si]/Ys0_[si][celli], exp)
*(Ys0_[si][celli]);
}
return kf;
I believe the "si" at line 267, should be replaced by "s", so the new code should be:
const scalar exp = R.lhs()[s].exponent;
I tried this and it solved the problem in my code! Because as far as I understand, "s" is the species index in the R.lhs() (left hand side of the reaction) and "si" is the species index in the species list! In case it is not clear or it is not convincing, please take a look at the following reaction file as an example:
species
(
A
B
C
);
gaseousSpecies
(
D
E
F
);
reactions
{
reaction1
{
type irreversibleArrheniusSolidReaction;
reaction "B = C";
A 1.5e14;
beta 0;
Ta 23653.7493709109;
Tcrit 500;
}
}
So in this case, to calculate the omega of the reaction, "s" will be 0 but "si" will be 1! Therefore, trying to read R.lhs()[si].exponent leads to undefined behavior, because R.lhs() has a size of 1!
I tried to explain the problem as clear as I could, so sorry for the long post, and please let me know if there is still something missing.
Best regards,
Mortezahttps://develop.openfoam.com/Development/openfoam/-/issues/746Possible Redundancy in Comments of the Tutorial: channel395DFSEM2019-12-09T22:18:10ZKutalmış BerçinPossible Redundancy in Comments of the Tutorial: channel395DFSEMHi,
Please consider: `tutorials/incompressible/pimpleFoam/LES/channel395DFSEM`
Therein, `0/U` has the following comment for `nu`:
```
// Re = 395, L = pi, utau = 1, nu = pi/395 = 7.9534e-3
```
Yet in `constant/transportProperties` ...Hi,
Please consider: `tutorials/incompressible/pimpleFoam/LES/channel395DFSEM`
Therein, `0/U` has the following comment for `nu`:
```
// Re = 395, L = pi, utau = 1, nu = pi/395 = 7.9534e-3
```
Yet in `constant/transportProperties` another comment for `nu` states:
```
// Re_tau = u_tau L / nu
// Re_tau = 395
// L = half channel height = 1
// Ubulk/u_tau = 17.55
// U_bulk = 17.55 -> u_tau = 1
// -> nu = 1*1/395 = 2.532e-3
```
AFAIK, the second comment reflects the generally accepted value of the half channel height for this particular plane channel flow although its value can be anything. Considering the computation uses the value of `nu = 2.532e-3`, I believe that discarding the first comment may be useful.
Kind regardshttps://develop.openfoam.com/Development/openfoam/-/issues/2579possible regression in noise utility2022-09-09T10:14:37ZMark OLESENpossible regression in noise utilityReported by @Prashant - appears to block when reading the ensight surfaces.
Perhaps related to changes from #2535 or #2532. Possible suspect may be handling of `undef` value.Reported by @Prashant - appears to block when reading the ensight surfaces.
Perhaps related to changes from #2535 or #2532. Possible suspect may be handling of `undef` value.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1269possible regression in uniformFixedValuePointPatch?2019-04-08T15:04:14ZMark OLESENpossible regression in uniformFixedValuePointPatch?In tutorials/basic/overLaplacianDyMFoam/heatTransfer I'm getting some very odd output which I think could be related to this commit: 0987898f5c1678
I initially thought it might be related to the generic point patches since reconstructPa...In tutorials/basic/overLaplacianDyMFoam/heatTransfer I'm getting some very odd output which I think could be related to this commit: 0987898f5c1678
I initially thought it might be related to the generic point patches since reconstructPar was failing when fill-nan is set. The values it reconstructs for the pointDisplacement right1 boundary are scalars, not vectors.
Backtracking some more, it seems that the original decomposed fields are a bit *odd*.
In 1812:
processor0/0/pointDisplacement.right1
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue constant (0 0 0);
}
In develop:
processor0/0/pointDisplacement.right1
right1
{
type uniformFixedValue;
uniformValue ( 0 0 0 );
}
At later times this looks different again. Eg, processor0/0.5/pointDisplacement.right1
1812:
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue constant (0 0 0);
}
develop:
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue nonuniform 0();
}
When this is reconstructed, the generic point patch process the entries quite badly. Even the output for `value` does not look correct.
@PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1927Possible typo in solidProperties.C variable name definition2020-11-26T01:16:19ZRobin KnowlesPossible typo in solidProperties.C variable name definition<!--
*** 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
Possible typo in the solidProperties.C in the `Hf` variable name
### 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 : v2006
### Possible fixes
```diff
.../solidProperties/solidProperties/solidProperties.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidProperties.C b/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidPr
operties.C
index 3c12e9733f..9ae8cd1bc9 100644
--- a/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidProperties.C
+++ b/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidProperties.C
@@ -77,7 +77,7 @@ void Foam::solidProperties::readIfPresent(const dictionary& dict)
dict.readIfPresent("rho", rho_);
dict.readIfPresent("Cp", Cp_);
dict.readIfPresentCompat("kappa", {{"K", 1612}}, kappa_);
- dict.readIfPresent("Hf_", Hf_);
+ dict.readIfPresent("Hf", Hf_);
dict.readIfPresent("emissivity", emissivity_);
dict.readIfPresent("W", W_);
}
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2168Possible variable name conflict in friction models for liquid film2022-12-23T14:45:59ZChiara PesciPossible variable name conflict in friction models for liquid film### Summary
In the liquidFilm model, when computing the wall shear stress with DarcyWeisbach model, the same variable name `Cf` is used as for the modelling of the shear stress at the liquid/gas interface.
### Steps to reproduce
Pleas...### Summary
In the liquidFilm model, when computing the wall shear stress with DarcyWeisbach model, the same variable name `Cf` is used as for the modelling of the shear stress at the liquid/gas interface.
### Steps to reproduce
Please refer to the two variable definitions:
- shear stress at the liquid/gas interface in [$FOAM_SRC/regionFaModels/liquidFilm/subModels/kinematic/filmTurbulenceModel/laminar/laminar.C](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/regionFaModels/liquidFilm/subModels/kinematic/filmTurbulenceModel/laminar/laminar.C#L55)
- wall shear stress (solid/liquid film interface) in [$FOAM_SRC/regionFaModels/liquidFilm/subModels/kinematic/filmTurbulenceModel/filmTurbulenceModel/filmTurbulenceModel.C](https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/regionFaModels/liquidFilm/subModels/kinematic/filmTurbulenceModel/filmTurbulenceModel/filmTurbulenceModel.C#L128)
### Example case
Please refer to the tutorial [$FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/pitzDailyWithSprinkles](https://develop.openfoam.com/Development/openfoam/-/tree/develop/tutorials/lagrangian/kinematicParcelFoam/pitzDailyWithSprinkles), with the following modification for 0/U.base:
```
laminarCoeffs
{
friction DarcyWeisbach; // Wall friction model
Cf 0; // Gas friction or Cf for DarcyWeisbach model
}
```
### What is the current *bug* behaviour?
The entry `Cf` seems to be used both for the computation of the gas friction and in the DarcyWeisbach wall friction model.
### What is the expected *correct* behavior?
Change one of the two variable names, either for the gas friction or in the DarcyWeisbach model to avoid the naming conflict.
### 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|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : develop
- Operating system : ubuntu
- Compiler : gcc
### Possible fixes
Change the name for the variable `Cf` in the DarcyWeisbach model.
<!--
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
-->v2206Sergio FerrarisSergio Ferraris