Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-06-15T10:14:20Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1728sampling/slicing with "crinkle cut"2020-06-15T10:14:20ZMark OLESENsampling/slicing with "crinkle cut"- question raised on cfd-online (https://www.cfd-online.com/Forums/openfoam-post-processing/227873-surface-vtk-crinkle-cut.html)
Might be of general interest.- question raised on cfd-online (https://www.cfd-online.com/Forums/openfoam-post-processing/227873-surface-vtk-crinkle-cut.html)
Might be of general interest.https://develop.openfoam.com/Development/openfoam/-/issues/1727vtkSurfaceWriter crash2020-11-26T16:26:06ZRiccardo RossivtkSurfaceWriter crashSometimes, in different scenarios of releases, grids and solvers, foam crashes during vtk writing of sampled surfaces with errors like:
[0] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[0] #1 Foam::sigFpe::sigHandler(int) at ??:...Sometimes, in different scenarios of releases, grids and solvers, foam crashes during vtk writing of sampled surfaces with errors like:
[0] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[0] #1 Foam::sigFpe::sigHandler(int) at ??:?
[0] #2 ? in "/lib64/libc.so.6"
[0] #3 void Foam::vtkSurfaceWriter::writeData<double>(Foam::Ostream&, Foam::Field<double> const&) at ??:?
[0] #4 Foam::vtkSurfaceWriter::write(Foam::fileName const&, Foam::fileName const&, Foam::Field<Foam::Vector<double> > const&, Foam::List<Foam::face> const&, Foam::word const&, Foam::Field<double> const&, bool, bool) const at ??:?
[0] #5 void Foam::sampledSurfaces::writeSurface<double>(Foam::Field<double> const&, int, Foam::word const&, Foam::fileName const&) at ??:?
[0] #6 void Foam::sampledSurfaces::sampleAndWrite<double>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[0] #7 void Foam::sampledSurfaces::sampleAndWrite<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> >(Foam::IOobjectList const&) at ??:?
[0] #8 Foam::sampledSurfaces::write() at ??:?
[0] #9 Foam::OutputFilterFunctionObject<Foam::sampledSurfaces>::execute(bool) at ??:?
[0] #10 Foam::functionObjectList::execute(bool) at ??:?
[0] #11 Foam::Time::run() const at ??:?
[0] #12 Foam::Time::loop() at ??:?
[0] #13 Foam::simpleControl::loop() at ??:?
[0] #14 ? at ??:?
[0] #15 __libc_start_main in "/lib64/libc.so.6"
[0] #16 ? at ??:?
In this case, the release is the v1606 and the solver is simpleFoam. The writing frequency was set to 10. The first set of cut planes was saved correctly at t=10 and the solver crashed when attempting to write at t=20.https://develop.openfoam.com/Development/openfoam/-/issues/1724vtkCloud/double free or corruption2021-07-07T09:55:27ZRiccardo RossivtkCloud/double free or corruptionI've been testing the vtkCloud with the simplifiedSiwek tutorials and then used the function object with a customized solver based on interFoam with an added kinematicCloud.
The solver itself runs fine with and without the vtkCloud for ...I've been testing the vtkCloud with the simplifiedSiwek tutorials and then used the function object with a customized solver based on interFoam with an added kinematicCloud.
The solver itself runs fine with and without the vtkCloud for postprocessing, but when I include the function object I get this at the end of the simulation (still running fine and saving all the vtkCloud files as expected including the last one):
*** Error in `interLPTFoam': double free or corruption (!prev): 0x0000000002d27c50 ***
followed by:
======= Backtrace: =========
/lib64/libc.so.6(+0x7c619)[0x7f8b123d0619]
interLPTFoam(_ZN4Foam4wordD1Ev+0x43)[0x5bf4c3]
/lib64/libc.so.6(__cxa_finalize+0x9a)[0x7f8b1238cdda]
/gpfs/work/rfd_prod1/processing/Wam/projects/centrifugalSeparator/solvers/interLPTFoam/platforms/linux64IccDPInt32OptBDW/lib/libinterLPTLagrangianIntermediate.so(+0x2f97c3)[0x7f8b1afe17c3]
and then long list of string of errors related to many libraries not even used by the solver.
Any idea/suggestion?https://develop.openfoam.com/Development/openfoam/-/issues/1723MRF & interFoam issues2021-07-07T09:54:58ZYannickMRF & interFoam issues<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When using a MRF in combination with interFoam while doing a two phase simulation there is the following issue:
A) The fluid inside the MRF-region gets the rotational velocity of the MRF even if there is no geometry inside. I tried to build the MRF-region with snappy and topoSet but the output is the same.
B) It's not possible to update the MRF-Omega while the simulation is running
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
1. Take the DTC-Hull template Case with interFoam (tutorials/multiphase/interFoam/RAS/DTCHull)
2. remove the hull geometry
3. edit the snappyHexMeshDict and add a cellzone for the MRF
4. add MRFProperties to constant and set the MRFRegion to the created cellzone, set omega to 100
<!-- How one can reproduce the issue - this is very important -->
### Example case
see attached case
[HullMRF.zip](/uploads/504189d0137a0353e72d9b363bc11787/HullMRF.zip)
<!--
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 -->
Fluid rotates inside the MRF region without physical reason. It is the same if there is a geometry inside the Region.
![Cylinder](/uploads/e1eb4e667db9e61afb24de139398bb81/Cylinder.png)
![CylinderRefine](/uploads/f9f11afe7020c0d12e26dea185bb96e8/CylinderRefine.png)
![CylinderRefineFromBelow](/uploads/d16ee5a51ce1d6cf89d218ebee84a698/CylinderRefineFromBelow.png)
### What is the expected *correct* behavior?
No roataional moving of the fluid caused to the MRF
<!-- 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
testet with : v1812 & v1912
ubuntu
<!--
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 :v1812 & v1912
- Operating system :ubuntu
- Hardware info :
- Compiler :
<!--
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
-->
### Update 10.06.2020
We did some additional testing on that case
Modifications made
- We relpaced the Cylinder trough a searchableBox in SnappyHexMesh
- no refinement on the cellZone MRFRegion
- turn off all feature snapping
- moved the box completely in the water domain
Mesh is undisturbed and has a good quality
Variations made
- multiple omegas
In the attached pictures we see a strange curl velocities at the edges of region.
![CylinderunterwaterEdgesUy](/uploads/80c97953a08d63047d8f5ba67d612f09/CylinderunterwaterEdgesUy.png)
![CylinderunterwaterEdgesUx](/uploads/cf40832e71929e2e23d71cbc0855eaa8/CylinderunterwaterEdgesUx.png)
The last picture is showing some glyphs at the beginnig of the MRF.
Can it be, that there is something going on with the correctBoundaryVelocity when a cell has two or more faces with the nonRotating region?
![FlowLines2](/uploads/c6cdbbd6b5012ec0f32d393d73f50a25/FlowLines2.png)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1710foamFormatConvert -overwrite option2020-05-20T16:06:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamFormatConvert -overwrite option### Functionality to add/problem to solve
If used with `-fileHandler collated` have option (-overwrite ?) to remove the original processor[0-9]* directories (since all information already inside the processorsDDD directory). For any oth...### Functionality to add/problem to solve
If used with `-fileHandler collated` have option (-overwrite ?) to remove the original processor[0-9]* directories (since all information already inside the processorsDDD directory). For any other action (e.g. ascii->binary) the foamFormatConvert overwrites the input file anyway.https://develop.openfoam.com/Development/openfoam/-/issues/1704issue with refineHexMesh running in parallel with cyclic boundary conditions2021-07-07T08:24:13Ztq1203issue with refineHexMesh running in parallel with cyclic boundary conditions<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
When the domain is split among processors such that cells on cyclic patches are not on the same processor, refineHexMesh cannot be used.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use cyclic boundary conditions and set decomposeParDict such that the cells which are on cyclic boundaries are not on the same processor.
Run refineHexMesh on a cellset.
Observe the error of the form
"Cannot find point in pts1 matching point ### coord:(## ## ##) in pts0 when using tolerance ##" in the refineHexMesh log file.
### 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
-->
If your domain is a cube, and the patches perpendicular to the x axis are cyclic, then you cannot split the domain into sections along the x direction (e.g. (4 1 1) in decompseParDict). It seems like you can however split the domain along the y or z direction, since the cells with the cyclic faces will be on the same processor (e.g. (1 4 1) in decompseParDict).
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It would be nice if there was either a usage warning in refineHexMesh with cyclic boundary conditions, or if the mesh splitting and cell face assignments could be worked out so that it was possible to use refineHexMesh in parallel with cyclic boundary conditions.
### 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.
-->
Here is a sample of the refineHexMesh log file
```
[3] Cannot find point in pts1 matching point 131 coord:(0.015625 0.5 -0.0166667) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:0 in pts1
[3] Compared coord: (0.015625 -0.5 -0.0166667) at index 0 with difference to point 1
[3] Cannot find point in pts1 matching point 132 coord:(0.046875 0.5 -0.0166667) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:0 in pts1
[3] Compared coord: (0.015625 -0.5 -0.0166667) at index 0 with difference to point 1.00049
[3] Compared coord: (0.046875 -0.5 -0.0166667) at index 1 with difference to point 1
[3] Cannot find point in pts1 matching point 15 coord:(0.015625 0.5 -0.05) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:1 in pts1
[3] Compared coord: (0.046875 -0.5 -0.0166667) at index 1 with difference to point 1.00104
[3] Compared coord: (0.015625 -0.5 -0.05) at index 2 with difference to point 1
[3] Cannot find point in pts1 matching point 133 coord:(0.046875 0.5 -0.05) in pts0 when using tolerance 2.28455e-06
[3] Searching started from:2 in pts1
[3] Compared coord: (0.015625 -0.5 -0.05) at index 2 with difference to point 1.00049
[3] Compared coord: (0.046875 -0.5 -0.05) at index 3 with difference to point 1
```
### 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 : v1806
OS: centos
### 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 now, if you keep the cyclic cells on the same processor it seems to work.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1687Linear algebra profiling in standard output2020-12-22T08:04:18ZSimone BnaLinear algebra profiling in standard outputHi,
after a discussion with @mark and Ivan Spisso @ivanspisso (chairman of the HPC technical committee), we think it can be useful for a user to see in the output some more information about the execution time of each preconditioner/s...Hi,
after a discussion with @mark and Ivan Spisso @ivanspisso (chairman of the HPC technical committee), we think it can be useful for a user to see in the output some more information about the execution time of each preconditioner/solver pair of the PISO/PIMPLE/SIMPLE loop and not only its total execution. This solution would show if there are rooms for improvements by changing the solver/preconditioner or tuning its parameters.
What I propose is something like this:
Time = 0.000625
Courant Number mean: 0.0135897 max: 0.241523
DILUPBiCGStab: Solving for Ux, Initial residual = 0.012631, Final residual = 0.00040317, No Iterations 5, Preconditioner time = 0.02 s, Solver time = 1.23 s
DILUPBiCGStab: Solving for Uy, Initial residual = 0.0295468, Final residual = 0.00096396, No Iterations 5, Preconditioner time = 0.02 s, Solver time = 1.25 s
DILUPBiCGStab: Solving for Uz, Initial residual = 0.109576, Final residual = 0.00700867, No Iterations 5, Preconditioner time = 0.02 s, Solver time = 1.24 s
petsc-cg: Solving for p, Initial residual = 0.538072, Final residual = 9.9628e-05, No Iterations 1164, Preconditioner time = 0.14 s, Solver time = 1.76 s
time step continuity errors : sum local = 8.47465e-10, global = -8.77385e-24, cumulative = -2.99506e-21
petsc-cg: Solving for p, Initial residual = 0.49318, Final residual = 9.97012e-05, No Iterations 1161, Preconditioner time = 0.13 s, Solver time = 2.24 s
time step continuity errors : sum local = 8.44322e-10, global = -2.7257e-22, cumulative = -3.26763e-21
ExecutionTime = 455.77 s ClockTime = 470 s
The idea is to add to each solver line, after the number of iterations, the time spent in the preconditioner and in the solver.
Since this solution has a higher overhead and has an impact on the standard output log, it can be "activated" optionally by the user.
I think that the profiling already implemented in OpenFOAM is more suited for a developer than a user, and it is not possible to see how much time is spent in each linear algebra solver. From the implementation point of view, Mark suggested to add two ClockTime values to the SolverPerformance class.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1683Overset, inverseDistance and wall contact, possible fix2021-11-19T15:19:03ZNicolas EdhOverset, inverseDistance and wall contact, possible fix### Summary
cellTypes isn't calculated correctly when walls are close or overlaps. This is a known issue. I'm proposing a fix below for inverseDistance.
### Steps to reproduce
Run the attached testcase with inverseDistance. Any other t...### Summary
cellTypes isn't calculated correctly when walls are close or overlaps. This is a known issue. I'm proposing a fix below for inverseDistance.
### Steps to reproduce
Run the attached testcase with inverseDistance. Any other tutorial is also fine just move overset meshes outside the domain.
### Example case
I’m attaching a small test case with two zones. The second zone is object that slides along the wall of the background mesh. This case works with my proposed fixes to inverseDistance. It also works with cellVolumeWeight but one has to copy cellTypes from a fixed inverseDistanceStencil to the first time step.
[wallcontact.tgz](/uploads/56c7f38dc21a0c3dda2abf907f850a7b/wallcontact.tgz)
### What is the current *bug* behaviour?
cellTypes isn't calculated correctly when walls are close or overlaps. This is a known issue, e.g. buggs [1636](https://develop.openfoam.com/Development/openfoam/issues/1636) or [1288](https://develop.openfoam.com/Development/openfoam/issues/1288).
### What is the expected *correct* behavior?
Something like the attached animation =)
[proof.avi](/uploads/9ddb09c777b3eda6ca42c0199b2b25e6/proof.avi)
Due to the coarseness of the mesh of the attached case a rather large part of where the walls intersect is cut out. I think this could be improved by a better selection of nDivs. Currently we select the number of divisions bases on sqrt(nCells) (2D). nCells is based on the entire mesh. A better choice would be sqrt(nCells) for each zone. Still this would not guarantee the same size of the voxels across processors. However for this type of case refining the mesh near the wall should be enough or manually setting nDivs.
### Environment information
OpenFOAM version : v1912
Operating system : any
Hardware info : Intel Xeon
Compiler : gcc
### Possible fixes
A first step to allowing wall contact is to make sure the cellCellStencils calculate cellTypes correctly. This is a proposed fix: [inverseDistanceCellCellStencil.C](/uploads/cf528a31bcb8523b8bcd21766d44f08a/inverseDistanceCellCellStencil.C)
There are three changes needed to inverseDistance in order for it to work and two more which I find convenient when debugging. I’m attaching a version with all five fixes.
* In markDonors we exclude primary donors that are HOLE. It’s better to include them. See attached figure of “allStencil_hole”. The near wall cells are considered HOLE. This will create a gap for walkFront to spill out from. When walkFront “spills out” we kill the entire background mesh.
There are two checks in markDonors;
`if (srcCelli != -1 && allCellTypes[srcCellMap[srcCelli]] != HOLE)`
That should be changed to
`if (srcCelli != -1)`
![badStencil_hole](/uploads/b9d48393d66b5241cd6d1fd53efe2de0/badStencil_hole.png)
* In createStencil, HOLE cells are excluded. Meaning if the primary donor is a HOLE we don’t even try to find suitable donors among its neighbours. We have two options here that both work,
1. Try to find donors and keep them even if they are all holes. It seems like nonsense but it will work. This is what’s done in cellVolumeWeight. In order to accomplish this just keep isValidDonor true for all cells. I.e. skip the loop right after it’s created.
2. The other option is to set the amount of interpolation to zero, i.e. set
cellInterpolationWeight to zero. For this to work, we still need to have isValidDonor true otherwise the cell will be removed by globalCellCells and set to HOLE.
After createStencil we need to set the “amount of interpolation to zero”. This option is what is included in the attaced file.
* In update(), right after allCellType_patch is written a check with cellTypes from the previous time step is performed. If cells have changed from HOLE to calculated they are set to interpolated. This check is no longer necessary for inverseDistance (but is what makes cellVolumeWeight work). In fact the check should be removed. The check can cause additional layers of interpolation cells which aren’t need nor wanted. This will happen for mesh courant numbers above one. To illustrate, imagine a cylinder which in one time step move say half its diameter. Half the cells where the cylinder was the prevous time step but isn’t now would be interpolated. Wolfdynamics has a nice illustration of this here: https://youtu.be/kVMA7_1YvH0?list=PLoI86R1JVvv_rDlODjff5LUWD4WX9G9vc&t=1218
* The fourth change isn’t necessary but makes debugging easier. The stencil is written out as an wavefront file. I would prefer if one file is written per region.
* I also find it use full to create a field with the size of the final stencil.
### Disclaimer
These patches just make inverseDistance behave with some sort of decency if walls between meshes are close. It’s not a guarantee that it will work. Mass won’t be preserved at all if there is a large change in volume. Change the movement to y direction instead in the test case. But I still think these patches should be included. There are many cases were only a moderate change in volume takes place when walls interact.
Secondly another solution is required for where walls intersect. The currently solution doesn’t crash and should be stable but an additional error will be introduced. For the cases I’ve tried this error is still smaller than the general mass preservation problem already present. I’ve been looking in to that with little success. At the moment I take note that overset in foam-extend is *exact* in terms of mass balance. For the same case (where no wall-to-wall interaction occurs) v1912 might have 5% error in mass while extend has an error in the order of the tolerance in the pressure equation. If there is interest I could file a different bug with my findings but I have no fix only indications to where the problem is.https://develop.openfoam.com/Development/openfoam/-/issues/1681SPDP : time precision2021-11-02T09:38:58ZPrashant SonakarSPDP : time precision### Functionality to add/problem to solve
The time is stored as scalar, which can accumulate truncation errors. This can show problems with follow-on applications e.g. noise
### Proposal
- Change storage of time as e.g. solveScalar an...### Functionality to add/problem to solve
The time is stored as scalar, which can accumulate truncation errors. This can show problems with follow-on applications e.g. noise
### Proposal
- Change storage of time as e.g. solveScalar and adjust API accordingly.
- look at interpolating times e.g. temporalInterpolate
### What does success look like, and how can we measure that?
- damBreak tutorial example with changes in controlDict writeControl = runTime, adjustableTimeStep=false
- run in SPDP or SP mode.
- till 0.3 folders are good, but later have fractions e.g. 0.349999
@andy @Mattijs https://develop.openfoam.com/Development/openfoam/-/issues/1677Support rigidBodyMotionState object in writeObjects2021-07-07T08:16:22ZJaap StolkSupport rigidBodyMotionState object in writeObjects### Functionality to add/problem to solve
To reduce the number of fields files written by openFoam, the normal writes can be disabled with a very large write interval and a custom "writeObjects" can be used instead. This makes it possib...### Functionality to add/problem to solve
To reduce the number of fields files written by openFoam, the normal writes can be disabled with a very large write interval and a custom "writeObjects" can be used instead. This makes it possible to specify exactly which field(s) need to be written to disk. For users interested in the rigidBodyMotionState this does not work because it is not an "Available objects in database".
### Target audience
Anyone wanting more control over which fields are written to disk, and needing the rigidBodyMotionState.
Note that re-staring a case from a saved data point requires the rigidBodyMotionState file.
It can also be used for transformations in paraFoam, to invert or match the object motion.
(as workaround, a user could try to recreate the missing rigidBodyMotionState files from the orientation information in the log.interFoam file. And maybe there are other workarounds.)
### Proposal
If it is a database object but it is not listed for some reason, make sure rigidBodyMotionState is listed when available.
If rigidBodyMotionState is not a "real" database object, it may be possible to add an option to "writeObjects" to enable writing of non-real-databse-objects, similar to how the normal write writes these files, and probably similar to how the "time" file is not listed but is written automatically.
I don't know how complex this is to add. During a normal write they are written and in the rigidBodyMotionState files header claim to be a database object.
### What does success look like, and how can we measure that?
The rigidBodyMotionState(.gz) file appearing in the processor0/0.1/uniform folders.
### example case
Using the normal write:
- start with the multiphase/interFoam/RAS/DTCHullMoving example
- change endTime to 0.2 and writeInterval to 0.1 (to speed up the test)
- Allrun
- there now is a processor0/0.1/uniform/rigidBodyMotionState file.
Using a custom write with just "U" and "points":
- copy the attached controlDict in the multiphase/interFoam/RAS/DTCHullMoving example
- Allrun
- processor0/0.1 folder now only contains the selected (U) file.
Including "rigidBodyMotionState" results in warning and no file:
- copy the attached controlDict in the multiphase/interFoam/RAS/DTCHullMoving example
- uncomment the rigidBodyMotionState line in controlDict
- Allrun
- log.interFoam contains a warning for rigidBodyMotionState, and lists the 56 objects available in the database.
### Links / references
example [controlDict](/uploads/d5a3043780580a578e69e4fa655d64d2/controlDict)
resulting warning: [log.interFoam_snippet](/uploads/d01e48fe4aee07ebd258f57adfc593b2/log.interFoam_snippet)
typical result object file: [rigidBodyMotionState](/uploads/7551e066077c035de70b75d519199051/rigidBodyMotionState)https://develop.openfoam.com/Development/openfoam/-/issues/1675fieldCoordinateSystemTransform fails to write "U:Transformed" field on a Wind...2022-07-28T04:30:32ZJustin GraupmanfieldCoordinateSystemTransform fails to write "U:Transformed" field on a Windows OS### Summary
fieldCoordinateSystemTransform function object attempts to write "U:Transformed" field on Windows OS even though the ":" character it not supported in file names. This results in the field not being written.
### Steps to r...### Summary
fieldCoordinateSystemTransform function object attempts to write "U:Transformed" field on Windows OS even though the ":" character it not supported in file names. This results in the field not being written.
### Steps to reproduce
This can be reproduced using a modified version of the simpleFoam pipeCyclic tutorial.
1. Open a OpenFOAM-MS-DOSPrompt.bat window
2. Navigate to the attached slightly modified pipeCyclic tutorial
3. Run simpleFoam
The log will show that the field is trying to be written, but it never shows up in the time directory.
`functionObjects::fieldCoordinateSystemTransform coordinateTransform writing field: U:Transformed`
### Example case
[pipeCyclic.zip](/uploads/3059de4c995aef7c3ea9153da8be9610/pipeCyclic.zip)
### What is the current *bug* behaviour?
The U:Transformed is not written like it should be due to the Windows OS not supporting the ":" character in a file name.
### What is the expected *correct* behavior?
U:Transformed needs to be written with a compatible file name.
### Environment information
- OpenFOAM version : v1912
- Operating system : Windows 10
- Hardware info : Intel
- Compiler : MinGW
- Prompt : OpenFOAM-MS-DOSPrompt.bat
### Possible fixes
The simplest fix in my opinion would be to add the ability to change the name of the written field in the fieldCoordinateSystemTransform function object using an option like...
fields ( (U U_Transformed) );Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1674add rotatedBoxToCell vector order check and warning.2022-04-26T16:10:00ZJaap Stolkadd rotatedBoxToCell vector order check and warning.### Functionality to add/problem to solve
In the rotatedBoxToCell cell selection, the box is defined using an origin and 3 vectors.
if the vectors are not in the correct left/right-hand order, the selection box will be inside-out and no...### Functionality to add/problem to solve
In the rotatedBoxToCell cell selection, the box is defined using an origin and 3 vectors.
if the vectors are not in the correct left/right-hand order, the selection box will be inside-out and not select any cells.
This problem is not easy to spot since no errors or warnings are generated for this situation.
### Proposal
If possible, add a check to the code and produce a warning if this situation is encountered.
And make the importance of the vector order more clear in the rotatedBoxToCell documentation.
### Note
I have since switched to using an external .STL file with a surfaceToCell for more complex selections, but decided to at least share my experience with the rotatedBoxToCell.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1672waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.2020-07-02T07:43:53ZJaap StolkwaveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.### Summary
<!-- Summarize the bug encountered concisely -->
waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.
### Steps to reproduce
in version v1912, copy the multiphase\interFoam\laminar\waves\waveMake...### Summary
<!-- Summarize the bug encountered concisely -->
waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.
### Steps to reproduce
in version v1912, copy the multiphase\interFoam\laminar\waves\waveMakerMultiPaddleFlap example.
- I have swapped X and Y of verices in system/blockMeshDict (attached) and adjusted the vertex order to keep the hex () definition CCW.
- I swapped the X and Y decomposition in system/decomposeParDict
- in 0.orig/pointDisplacement, I changed the normal vector to: n (0 1 0)
- then ran the case using the Allrun script.
### Example case
place the attached system/blockMeshDict in the v1912 multiphase\interFoam\laminar\waves\waveMakerMultiPaddleFlap example, and make the 2 additional modifications mentioned above.
### What is the current *bug* behaviour?
It results in a floatingpoint-error in Foam::waveMakerPointPatchVectorField::initialiseGeometry()
without any other errors or warnings logged. (see attached log.interFoam)
### What is the expected *correct* behavior?
The calculation should run as the original example, or produce an error message when the waveMaker normal vector is outside the supported range.
I tried to reproduce with minimal changes to an example case. In my original case I had the waveMaker boundary on the -Y side and swapping everything in my case in the x=y line resolved my crash, but now the postprocessing does not follow my other cases that have the waveMaker boundary on the -X side.
### Relevant logs and/or images
[blockMeshDict](/uploads/ecde43c3bda4ea4dbc9d45ab7a45423e/blockMeshDict)
[log.interFoam](/uploads/ac80e7fd15e51b2884e8eb6c2302b5b7/log.interFoam)
### Environment information
- OpenFOAM version : v1912 (compiled from source)
- Operating system : ubuntu
- Hardware info : 2x Intel(R) Xeon(R) E5-2690 2.9 GHz
- Hardware info : 1x AMD 1950X
- Compiler : gccv2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1652adding porous media in rotatine zone2022-04-26T16:10:39ZRoshanakadding porous media in rotatine zoneAdding feature of "Relative velocity Resistance formulation" which exists in Ansys-fluent for better prediction of source term when rotating region and porous zone are located in one zone. in Ansys-Fluent, the results, when you choose th...Adding feature of "Relative velocity Resistance formulation" which exists in Ansys-fluent for better prediction of source term when rotating region and porous zone are located in one zone. in Ansys-Fluent, the results, when you choose this option or not selecting it, are quite different.
it seems that Openfoam can only calculate porous source term based on absolute velocity. when it is calculated Darcy-Forchimmier source term based on absolute velocity, it seems that porous zone is fixed in position and not rotating(see attachment files)![Screenshot_from_2020-03-30_10-42-16](/uploads/993db2537153c78ad9347af3ff8f75ad/Screenshot_from_2020-03-30_10-42-16.png)![Screenshot_from_2020-03-30_10-42-32](/uploads/39025939c059c1eb36d8aa33dcaec335/Screenshot_from_2020-03-30_10-42-32.png)v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1645Re-open Issue: Gauss CoBlended scheme fails for div(phi,alpha) in interFoam2022-04-26T16:10:40ZLydia SchulzeRe-open Issue: Gauss CoBlended scheme fails for div(phi,alpha) in interFoam<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
Note:
I re-open this issue, as it is still relevant and not fixed in the latest version.
The issue was already described in #1236 for version v1812.
When using the scheme Gauss CoBlended for the term div(phi,alpha) in the solver interFoam, the simulation breaks up with the following error message: fvSchemes:
```div(phi,alpha) Gauss CoBlended 1. Minmod 2. upwind;```
logfile output:
`\--> FOAM FATAL ERROR: Operator + is undefined for unoriented and oriented types From function Foam::orientedType Foam::operator+(const Foam::orientedType&, const Foam::orientedType&) in file orientedType/orientedType.C at line 458.`
### Steps to reproduce
Use tutorial /multiphase/RAS/interFoam/damBreak. Change in fvSchemes:
```div(phi,alpha) Gauss CoBlended 1. Minmod 2. upwind;```
Run the case with Allrun.
### Example case
The damBreak tutorial (tutorials/multiphase/RAS/damBreak)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Run fails in first alpha-Subcycle.
See logfile output below.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Normal interFoam-running would be expected.
### 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.
-->
```Courant Number mean: 0 max: 0 Interface Courant Number mean: 0 max: 0 deltaT = 0.00119048 Time = 0.00119048 PIMPLE: iteration 1 smoothSolver: Solving for alpha.water, Initial residual = 0, Final residual = 0, No Iterations 0 Phase-1 volume fraction = 0.130194 Min(alpha.water) = 0 Max(alpha.water) = 1 --> FOAM FATAL ERROR: Operator + is undefined for unoriented and oriented types From function Foam::orientedType Foam::operator+(const Foam::orientedType&, const Foam::orientedType&) in file orientedType/orientedType.C at line 458.```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1912
- Operating system : centos
- Hardware info :
- 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
-->v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1639simpleFoam: non-realistic turbulence increase in the streamwise direction in ...2024-01-11T17:22:49ZLorenzo CozzisimpleFoam: non-realistic turbulence increase in the streamwise direction in a wall-bounded flowDear developers,
running a case of a wall bounded flow over a flat plate with simpleFoam I got really weird results, with turbulent kinetic energy and turbulence intensity increasing in the flow direction when they are supposed to lower...Dear developers,
running a case of a wall bounded flow over a flat plate with simpleFoam I got really weird results, with turbulent kinetic energy and turbulence intensity increasing in the flow direction when they are supposed to lower down because of the turbulence decay.
To ease the issue-solving procedure, I prepared an archive with my case folder ready to be used. Find the .tar file here: [https://www.dropbox.com/s/szkz4vymu92eev0/smooth-openFOAM-RANS-Re70k-CFDOnline.tar?dl=0](https://www.dropbox.com/s/szkz4vymu92eev0/smooth-openFOAM-RANS-Re70k-CFDOnline.tar?dl=0)v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1634Style formatting config needed (e.g. clang-format)2024-02-16T13:40:05ZGerasimos ChourdakisStyle formatting config needed (e.g. clang-format)### Functionality to add/problem to solve
Add a [clang-format](https://clang.llvm.org/docs/ClangFormat.html) or similar system config file in the code repository, so that contributions to the repository or derived projects can follow th...### Functionality to add/problem to solve
Add a [clang-format](https://clang.llvm.org/docs/ClangFormat.html) or similar system config file in the code repository, so that contributions to the repository or derived projects can follow the [Coding Style Guide](https://develop.openfoam.com/Development/openfoam/wikis/Coding-Style-Guide).
Clang-format is an established formatting tool and integration is already provided in many editors and IDEs, including [Emacs](https://clang.llvm.org/docs/ClangFormat.html#emacs-integration), [Vim](https://clang.llvm.org/docs/ClangFormat.html#vim-integration), and [CLion](https://clang.llvm.org/docs/ClangFormat.html#clion-integration).
### Target audience
- Regular developers of OpenFOAM
- External contributors to OpenFOAM
- Contributors to third-party OpenFOAM projects (e.g. function objects, such as the [preCICE OpenFOAM adapter](https://github.com/precice/openfoam-adapter))
### Proposal
1. Create a `.clang-format` file, e.g. in the root directory of the repository, or any other directory preferred for developers' tools.
- For example, with `clang-format -style=llvm -dump-config > .clang-format`
2. Define the preferred rules following the [Clang-Format Style Options](https://clang.llvm.org/docs/ClangFormatStyleOptions.html). Beware that the rules may depend on the Clang-Format version.
### What does success look like, and how can we measure that?
Running `clang-format -i FILES` should reformat the source files `FILES` to follow the coding style guidelines.
### Links / references
- [Clang-Format Style Options](https://clang.llvm.org/docs/ClangFormatStyleOptions.html)
- [OpenFOAM Coding Style Guide](https://develop.openfoam.com/Development/openfoam/wikis/Coding-Style-Guide)
### Funding
I am not aware of existing functionality regarding this. However, it may have been already developed by other developers.https://develop.openfoam.com/Development/openfoam/-/issues/1633Overset performance degradation (re-opened)2020-03-20T09:30:34ZRiccardo RossiOverset performance degradation (re-opened)I'm reopening this topic as preliminary testing with our model using the latest v1912 release shows the same issues.
In the following I'll present the results from testing based from what we learned from the previous discussion in #1183...I'm reopening this topic as preliminary testing with our model using the latest v1912 release shows the same issues.
In the following I'll present the results from testing based from what we learned from the previous discussion in #1183 using with tutorials from the official release (twoSimpleRotors and boatAndPropeller) and our test case (surfboard maneuvering).
The v1912 will be also compared to v1706 as the old release so far is the only one able to run our model with no issues.https://develop.openfoam.com/Development/openfoam/-/issues/1631Writing fields with layer information makes snappyHexMesh crash in motorbike ...2021-10-29T20:19:32ZRiccardo RossiWriting fields with layer information makes snappyHexMesh crash in motorbike tutorial (reopen)I've just tried to test the issue reported in #1420 with the v1912 and it's still there:
`
Writing fields with layer information:
nSurfaceLayers : actual number of layers
thickness : overall layer thickness
[0] #0 [1...I've just tried to test the issue reported in #1420 with the v1912 and it's still there:
`
Writing fields with layer information:
nSurfaceLayers : actual number of layers
thickness : overall layer thickness
[0] #0 [1] #0 [2] #0 [3] #0 [4] #0 [5] #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at at ??:?
`https://develop.openfoam.com/Development/openfoam/-/issues/1616CrankNicolson ddtScheme isn't working with MPPICInterFoam2022-04-26T16:10:39ZLinus KCrankNicolson ddtScheme isn't working with MPPICInterFoam### Summary
MPPICInterFoam isn't working when using the CrankNicolson ddtScheme. After my own project didnt work, I tried the "twoPhasePachuka" tutorial case with the same result. After the first time step it crashes, showing the error ...### Summary
MPPICInterFoam isn't working when using the CrankNicolson ddtScheme. After my own project didnt work, I tried the "twoPhasePachuka" tutorial case with the same result. After the first time step it crashes, showing the error message attached further down.
### Steps to reproduce
Take the "twoPhasePachuka" tutorial case.
In file fvSchemes, change the ddtScheme to CrankNicolson:
```
ddtSchemes
{
default CrankNicolson 0.1;
}
```
In file fvSolution, change the number of AlphaSubCycles to 1:
```
solvers
{
"alpha.water.*"
{
nAlphaCorr 2;
nAlphaSubCycles 1;
cAlpha 1;
```
### Relevant logs and/or images
```
--> FOAM FATAL ERROR:
tmp<N4Foam14GeometricFieldIdNS_13fvsPatchFieldENS_11surfaceMeshEEE> deallocated
From function const T& Foam::tmp<T>::cref() const [with T = Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>]
in file /OpenFOAM/v1812/OpenFOAM-v1812/src/OpenFOAM/lnInclude/tmpI.H at line 230.
FOAM aborting
```
### Environment information
OpenFOAM version : v1812v2206Kutalmış BerçinKutalmış Berçin