Development issueshttps://develop.openfoam.com/groups/Development/-/issues2016-07-14T02:43:14Zhttps://develop.openfoam.com/Development/openfoam/-/issues/182Opposite displacement in linearMotion class ( solidBodyMotionFunction)2016-07-14T02:43:14ZAdminOpposite displacement in linearMotion class ( solidBodyMotionFunction)Since commit, 6a5d5e903e68f288261ae60a410305f8fbd26f96 , ("septernion: Changed definition of the forward transformation for consistency with spatialTransform") , the transformation() function in linearMotion.C:69 calculates the displac...Since commit, 6a5d5e903e68f288261ae60a410305f8fbd26f96 , ("septernion: Changed definition of the forward transformation for consistency with spatialTransform") , the transformation() function in linearMotion.C:69 calculates the displacement vector of the septernion as: (-velocity_*t) and therefore, the displacement direction is inverted.
Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1230optionally suppress cell, proc, patch ids for foamToVTK2019-03-22T08:02:06ZMark OLESENoptionally suppress cell, proc, patch ids for foamToVTKcross-reference EP718
@SonESIcross-reference EP718
@SonESIMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2222opt-switch option does not parse value2024-01-10T08:58:32ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comopt-switch option does not parse value```
opt-switch maxThreadFileBufferSize=1
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFO...```
opt-switch maxThreadFileBufferSize=1
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2107 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : ad8e5540a3-20210929 OPENFOAM=2107 version=com
Arch : "LSB;label=32;scalar=64"
Exec : simpleFoam -parallel -fileHandler collated -opt-switch maxThreadFileBufferSize=5e9
Date : Sep 29 2021
Time : 17:43:09
Host : linux-bymj
PID : 26907
I/O : collated [threaded] (maxThreadFileBufferSize = 1).
Requires buffer large enough to collect all data or thread support
enabled in MPI. If MPI thread support cannot be enabled, deactivate
threading by setting maxThreadFileBufferSize to 0 in
OpenFOAM etc/controlDict
Case : /home/mattijs/OpenFOAM/OpenFOAM-plus/work/develop/openfoam/tutorials/incompressible/simpleFoam/pitzDaily
nProcs : 2
Hosts :
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1903orientation information in blockMesh VTK output2020-10-29T08:14:21ZMark OLESENorientation information in blockMesh VTK outputcomment raised via linkedIn, where the person seemed to have incorrectly oriented their blocks and was very confused that the three grid parameters did not correspond to global x/y/z.
Fairly easy to extract this information from the blo...comment raised via linkedIn, where the person seemed to have incorrectly oriented their blocks and was very confused that the three grid parameters did not correspond to global x/y/z.
Fairly easy to extract this information from the blocks and save as fields with `-write-vtk`.
![orientation](/uploads/759c7227a15fb40833040c5f0f2a00c5/orientation.png)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/126oscillatingACMI tutorial reports open cells2016-06-16T13:17:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comoscillatingACMI tutorial reports open cellsThis is solved by commit 90ba6113b597880dd3200bd37284627302bf9cc7 from OpenFOAM-dev
This is solved by commit 90ba6113b597880dd3200bd37284627302bf9cc7 from OpenFOAM-dev
https://develop.openfoam.com/Development/openfoam/-/issues/2492oscillatingBox tutorial does not run anymore2022-06-15T16:53:51ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comoscillatingBox tutorial does not run anymore<!--
*** 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 -->
meshPhi is of incorrect size
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `tutorials/multiphase/interFoam/laminar/oscillatingBox`
### 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
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
```
Selected 798 cells for refinement out of 2400.
[3]
[3]
[3] --> FOAM FATAL ERROR: (openfoam-2202 patch=220310)
[3] Old and current points sizes must be the same. Old points:601 Current points:1735
[3]
[3] From bool Foam::fvGeometryScheme::setMeshPhi() const
[3] in file fvMesh/fvGeometryScheme/fvGeometryScheme/fvGeometryScheme.C at line 56.
[3]
FOAM parallel run aborting
```
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : 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 : v2202
- 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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2526oscillatingRotatingMotion for pointDisplacement field does not decompose if n...2022-08-18T10:37:11ZCristóbal IbáñezoscillatingRotatingMotion for pointDisplacement field does not decompose if not written differently<!--
*** 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 -->
Boundary condition `type solidBodyMotionDisplacement;` with `solidBodyMotionFunction oscillatingRotatingMotion;` for `pointDisplacement` field runs fine in serial but needs to be written differently if the case wants to be decomposed.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Decomposing the tutorial case `$FOAM_TUTORIALS/mesh/moveDynamicMesh/relativeMotion/box2D_moveDynamicMesh` I get the following error when decomposing the field:
```
Processor 0: field transfer
--> FOAM FATAL IO ERROR: (openfoam-2206)
Entry 'solidBodyMotionFunction' not found in dictionary "/scratch/cibanez/relativeMotion/box2D_moveDynamicMesh/0/pointDisplacement.boundaryField.wing2.oscillatingRotatingMotionCoeffs"
file: 0/pointDisplacement.boundaryField.wing2.oscillatingRotatingMotionCoeffs at line 56 to 59.
From bool Foam::dictionary::readEntry(const Foam::word&, T&, Foam::keyType::option, bool) const [with T = Foam::word]
in file /prog/OpenFOAM/OpenFOAM-v2206/src/OpenFOAM/lnInclude/dictionaryTemplates.C at line 322.
FOAM exiting
```
<!--
### Example case
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
The current BC in `pointDisplacement` runs in serial
```
wing2
{
// Make wing2 rotate around its centre
type solidBodyMotionDisplacement;
solidBodyMotionFunction oscillatingRotatingMotion;
oscillatingRotatingMotionCoeffs
{
origin (-0.41 0 0);
axis (0 0 1);
omega 10; // rad/s, 1rad/s=9.5rpm
amplitude (0 0 10); // max amplitude (degrees)
}
}
```
but it needs to be written as follows to be able to decompose the boundary field
```
wing2
{
// Make wing2 rotate around its centre
type solidBodyMotionDisplacement;
solidBodyMotionFunction oscillatingRotatingMotion;
oscillatingRotatingMotionCoeffs
{
solidBodyMotionFunction oscillatingRotatingMotion; // This line added inside the coeffs
origin (-0.41 0 0);
axis (0 0 1);
omega 10; // rad/s, 1rad/s=9.5rpm
amplitude (0 0 10); // max amplitude (degrees)
}
}
```
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It should decompose as it's written in the tutorial.
<!--
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206 | 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
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2215OS Error: libPVblockMeshReader_SM.so: undefined symbol2021-09-21T09:15:50ZSunag R AOS Error: libPVblockMeshReader_SM.so: undefined symbol
### What is the current *bug* behaviour?
Dear All,
I am working with OpenFOAM v5 and I am trying to automate the simulations based on input request provided to flask.
For this purpose, I have created a python file for flask and have ...
### What is the current *bug* behaviour?
Dear All,
I am working with OpenFOAM v5 and I am trying to automate the simulations based on input request provided to flask.
For this purpose, I have created a python file for flask and have provided the OpenFOAM function which needs to run by using pvpython. Manually, only with python it will run perfectly without any error.
But, with flask when I run the python file, I am getting this below error:
**OSError: /opt/openfoam5/platforms/linux64GccDPInt32Opt/lib/paraview-5.4/libPVblockMeshReader_SM.so: undefined symbol: _ZN12pqRenderView16staticMetaObjectE**
How to overcome this error.?
### Relevant logs and/or images
I tried looking at similar post where the solution was mentioned as to work with LD_Preload as in link provided:
[LD_Preload](https://discourse.paraview.org/t/not-able-to-load-openfoam-paraview-reader-pvfoamreader-when-using-pvbatch-or-pvpython/248/21)
**LD_PRELOAD=/opt/OpenFOAM/paraviewopenfoam54/lib/paraview-5.4/libvtkpqCore-pv5.4.1.so.1 /opt/OpenFOAM/paraviewopenfoam54/bin/pvpython**
But it gives the following error from LD_Preload:
**ERROR: ld.so: object '/opt/paraviewopenfoam54/lib/paraview-5.4/libvtkpqCore-pv5.4.1.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.**
### Environment information
- OpenFOAM version : v5
- Operating system : ubuntu 18.04
- Hardware info :
- Compiler :Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/794OSspecific highResLastModified uses wrong struct field2023-12-07T19:03:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comOSspecific highResLastModified uses wrong struct fieldhighResLastModified uses stat(3) system call. It should use st_mtim, not st_atim.highResLastModified uses stat(3) system call. It should use st_mtim, not st_atim.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/534OStringStream rewind probably not behaving as expected2017-07-18T15:01:50ZMark OLESENOStringStream rewind probably not behaving as expectedThe rewind only repositions the output pointer, but does not truncate the output buffer.
Eg,
OStringStream os;
os << "1234567890";
os.rewind();
os << "abc";
produces "abc4567890" as output, not "abc" as may be expected....The rewind only repositions the output pointer, but does not truncate the output buffer.
Eg,
OStringStream os;
os << "1234567890";
os.rewind();
os << "abc";
produces "abc4567890" as output, not "abc" as may be expected.
Suggested recourse, provide explicit `reset()` method to reposition output pointer and buffer.
@andyv1712Mark OLESENMark OLESENhttps://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/2495Out-of-source install possible?2022-06-14T07:59:01ZVictor EijkhoutOut-of-source install possible?Is it possible to install OpenFOAM not-in-the-source-directory, or at least so that it copies all generated files to a prefix directory? The `Allwmake` command claims to accept a directory argument but I don't see what it does.Is it possible to install OpenFOAM not-in-the-source-directory, or at least so that it copies all generated files to a prefix directory? The `Allwmake` command claims to accept a directory argument but I don't see what it does.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2003output face areas (normals) for raw format2021-11-25T16:16:45ZMark OLESENoutput face areas (normals) for raw formatthe raw surface writer simply outputs x/y/z values and we lose geometric information such as the area of the face and its normal. Support an output flag for adding these.
cross-ref EP 1446the raw surface writer simply outputs x/y/z values and we lose geometric information such as the area of the face and its normal. Support an output flag for adding these.
cross-ref EP 1446Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2218output for FatalIOError missing line output2021-10-07T06:44:54ZMark OLESENoutput for FatalIOError missing line outputbroken by @mark, noticed by @Mattijs - will be fixed by @markbroken by @mark, noticed by @Mattijs - will be fixed by @markMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/923overPimpleDyMFoam does not satisfy the mass conservation betwee inlet and outlet2020-03-13T13:44:37ZAdminoverPimpleDyMFoam does not satisfy the mass conservation betwee inlet and outletHello,
I have a very simple test case. It is a 2D cylinder bounded by two fixed wall (top and bottom) and pressure inlet and outlet. The flow is laminar. When starting to move the cylinder periodically (the fluid is initially at rest) ...Hello,
I have a very simple test case. It is a 2D cylinder bounded by two fixed wall (top and bottom) and pressure inlet and outlet. The flow is laminar. When starting to move the cylinder periodically (the fluid is initially at rest) in direction of the inlet and outlet i realized by monitoring the mass fluxes at the inlet and the outlet that they are not equal in magnitude. So i was wondering if I have something wrong in the setup or there is an issue in the pressure equation (which should guarantee the mass conservation.
Please find attached the case. I made an Allrun command. Maybe someone can give me a hint what's going wrong. It was testes with the newest version 1806[OcilatingCylinderinFluidAtRestSend.tar.gz](/uploads/2beea06449f9cd405a84095a96190177/OcilatingCylinderinFluidAtRestSend.tar.gz)
\## Reattaching the author to the issue ticket: @HappyKiter ##https://develop.openfoam.com/Development/openfoam/-/issues/1366overPimpleDyMFoam froze using trackingInverseDistance in OpenFoam-v19062021-07-07T08:00:20ZAdminoverPimpleDyMFoam froze using trackingInverseDistance in OpenFoam-v1906I was trying to use the trackingInverseDistance method in OpenFoam-v1906 with overPimpleDyMFoam solver. The solver could be executed and the simulation ran for about 40000 time steps before it froze without any warning or error. While th...I was trying to use the trackingInverseDistance method in OpenFoam-v1906 with overPimpleDyMFoam solver. The solver could be executed and the simulation ran for about 40000 time steps before it froze without any warning or error. While the simulation could be completed successfully if the oversetInterpolation method is changed to inverseDistance. For your convenience, a truncated version of the log file is attached.[log](/uploads/6ea2ce54e9666ebd9adcb51f0d73bb88/log)
\#\# Reattaching the author to the issue ticket: @enhao.wang \#\#https://develop.openfoam.com/Development/openfoam/-/issues/689overPimpleDyMFoam with pressure reference2018-06-08T23:51:12ZAdminoverPimpleDyMFoam with pressure referenceWhile running the tutorial case simpleRotor I noticed an issue with the pressure reference for closed domains. It is clearly visible which point is chosen as the reference point. A velocity which should not exist appears in that corner. ...While running the tutorial case simpleRotor I noticed an issue with the pressure reference for closed domains. It is clearly visible which point is chosen as the reference point. A velocity which should not exist appears in that corner. Also the pressure fluctuates like crazy. Turning on adjustPhi or oversetAdjustPhi did not help. Tested with v1706 and v1712.https://develop.openfoam.com/Development/openfoam/-/issues/750overRhoPimpleDyMFoam only with psi thermo2018-06-08T23:43:43ZMatej FormanoverRhoPimpleDyMFoam only with psi thermoThe overRhoPimpleDyMFoam solver is set only with psi thermo.
Is there any particular reason for that?
Would be great to construct fluid thermo type.The overRhoPimpleDyMFoam solver is set only with psi thermo.
Is there any particular reason for that?
Would be great to construct fluid thermo type.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/803Overset bugs2018-04-25T09:13:01ZAdminOverset bugsI'm using 68185c76 on Debian GNU/Linux 8 (jessie). I believe I found some problems with the overset mesh implementation.
1. dynamicOversetFvMesh.C:96
Pstream::exchange<labelList, label>(remoteFaceCells, sendCells);
Neither remoteFa...I'm using 68185c76 on Debian GNU/Linux 8 (jessie). I believe I found some problems with the overset mesh implementation.
1. dynamicOversetFvMesh.C:96
Pstream::exchange<labelList, label>(remoteFaceCells, sendCells);
Neither remoteFaceCells nor sendCells are used after this exchange. I can't see its purpose. Results are not affected when I comment it out.
2. Parallelisation problem. The overSimpleFoam tutorial (aerofoil) converges in serial, but fails to converge in parallel. May be related to above. Mind you, this may be a red herring, because I get this warning:
--> FOAM Warning :
From function bool Foam::oversetPolyPatch::master() const
in file oversetPolyPatch/oversetPolyPatch.C at line 149
The master overset patch is not the first patch. Generally the first patch should be an overset patch to guarantee consistent operation.
-Davidhttps://develop.openfoam.com/Development/openfoam/-/issues/1636overset : (bug?) whole background domain switch to "wall" (cellType=2) if an ...2021-07-06T17:25:13ZKevin Siauoverset : (bug?) whole background domain switch to "wall" (cellType=2) if an overset wall get very close to a background wallHi,
I am doing some tests to see if the overset method could be used to simulate the closing of a valve. My test case is a simple background domain with an inlet/outlet (compressible) with a restriction supposed to be closed by a moving...Hi,
I am doing some tests to see if the overset method could be used to simulate the closing of a valve. My test case is a simple background domain with an inlet/outlet (compressible) with a restriction supposed to be closed by a moving wall present in the overset "region". The movement is done via displacementLaplacian.
My problem is that when the moving overset wall get close to the background wall, the entire background domain is switched to cellType=2 (wall/hole) and it never switch back to "normal". See the attached video illustrating the problem.
oversetInterpolation methods:
* cellWeighted : not really tested as too slow and does not mark the cells inside the moving wall as wall.
* inverseDistance and trackedInverseDistance : both show same behaviour. the second one was used for the attached video.
* leastSquares : the problem appears earlier than inverseDistance. Also in the gap, cells in the overset "region" are flagged as hole/wall even if, in my opinion, they should not (before contact, see last image below).
I tested under v1806, v1812 and v1912 (release versions). The problem does not appears in v1806 but appears in v1812 and v1912 (I could not test v1906 as it is not installed on our cluster).
I don't know if it is a bug or if I am doing something not supported (wall contact) but happens to work in v1806.
The videos was done with moveDynamicMesh in sequential. The mesh is (really) coarse outside the overlapping region in order to speed-up tests. The test case can be provided if needed.
comparison between versions for trackedInverseDistance :
![comp_overset_v1806_v1812_v1912](/uploads/53caa8b228484c727889c22f115fe325/comp_overset_v1806_v1812_v1912.mp4)
![comp_overset_1806_1912.0012](/uploads/1401ddc46645c45832294bd39cd3a17c/comp_overset_1806_1912.0012.png)
results for leastSquares in v1912, just before everything get flagged as hole/wall :
![overset_1912_leastSquares](/uploads/6eb4e44a5cc843fa27e77565ed2ed255/overset_1912_leastSquares.png)
Best regards