Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-01-17T16:44:08Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2321problem with converting chemkin file into OpenFoam format2022-01-17T16:44:08ZAmir Rezaproblem with converting chemkin file into OpenFoam formathi guys, I hope that you are doing well
I stuck in converting my mechanisms from Chemkin format into OpenFoam format.
You can find my 3 chemkin files in attachment.
When I use chemkintofoam comand to convert the files to openFOAM format...hi guys, I hope that you are doing well
I stuck in converting my mechanisms from Chemkin format into OpenFoam format.
You can find my 3 chemkin files in attachment.
When I use chemkintofoam comand to convert the files to openFOAM format, I get the error:
--> FOAM FATAL IO ERROR:
"ill defined primitiveEntry starting at keyword 'N2' on line 1 and ending at line 50"
file: trans_chemkin.dat at line 50.
From function void Foam:rimitiveEntry::readEntry(const Foam::dictionary&, Foam::Istream&)
in file db/dictionary/primitiveEntry/primitiveEntryIO.C at line 168.
I tried different tricks but no one works till now
Does any body any solution for that?
Thanks in advance guys
[C2H4_DNS_41Spec_.zip](/uploads/3c67a5587aa976742304e179f30e935e/C2H4_DNS_41Spec_.zip)https://develop.openfoam.com/Development/openfoam/-/issues/2323BUG: mapFieldsPar does not like old-time fields & does not write uniform/ dir...2022-01-17T11:01:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: mapFieldsPar does not like old-time fields & does not write uniform/ directory<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
mapFieldsPar does not map old-time fields. Also does not write uniform/ directory (but should it?)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- copy pimpleFoam/RAS/pitzDaily
- change ddtScheme to backward;
- change 'stopAt' to 'writeNow'
- run for one iteration in parallel
- map results back to original:
```
mpirun -np 2 mapFieldsPar -parallel ../pitzDaily_junk -sourceTime latestTime
```
This seems to generate some sigFpe or illegal values in k, epsilon.
### Example case
See above
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
- was thinking it might be the _0 field being auto-created but not initialised. Then when mapping _0 it would load this auto-generated field and crash. However this does not seem to be the case.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2311renaming the case-sensitive paths2022-01-12T08:58:30ZFoadrenaming the case-sensitive pathsFor some reason, OpenFOAM developers have case-sensitive paths in the codebase. As a result, it is difficult to port the software or to other OSes, such as macOS and/or Windows. For example, trying to `git clone` this repository on macOS...For some reason, OpenFOAM developers have case-sensitive paths in the codebase. As a result, it is difficult to port the software or to other OSes, such as macOS and/or Windows. For example, trying to `git clone` this repository on macOS results
<pre>
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:
'applications/test/Dictionary/Make/files'
'applications/test/dictionary/Make/files'
'applications/test/Dictionary/Make/options'
'applications/test/dictionary/Make/options'
'applications/test/Dictionary/Test-Dictionary.C'
'applications/test/dictionary/Test-dictionary.C'
'applications/test/Tensor2D/Make/files'
'applications/test/tensor2D/Make/files'
'applications/test/Tensor2D/Make/options'
'applications/test/tensor2D/Make/options'
'applications/test/Tensor2D/Test-Tensor2D.C'
'applications/test/tensor2D/Test-tensor2D.C'
'src/finiteVolume/finiteVolume/fvc/fvcDDt.C'
'src/finiteVolume/finiteVolume/fvc/fvcDdt.C'
'src/finiteVolume/finiteVolume/fvc/fvcDDt.H'
'src/finiteVolume/finiteVolume/fvc/fvcDdt.H'
'src/finiteVolume/finiteVolume/gradSchemes/LeastSquaresGrad/LeastSquaresGrad.C'
'src/finiteVolume/finiteVolume/gradSchemes/leastSquaresGrad/leastSquaresGrad.C'
'src/finiteVolume/finiteVolume/gradSchemes/LeastSquaresGrad/LeastSquaresGrad.H'
'src/finiteVolume/finiteVolume/gradSchemes/leastSquaresGrad/leastSquaresGrad.H'
'src/finiteVolume/finiteVolume/gradSchemes/LeastSquaresGrad/LeastSquaresGrads.C'
'src/finiteVolume/finiteVolume/gradSchemes/leastSquaresGrad/leastSquaresGrads.C'
'src/finiteVolume/finiteVolume/gradSchemes/LeastSquaresGrad/LeastSquaresVectors.C'
'src/finiteVolume/finiteVolume/gradSchemes/leastSquaresGrad/leastSquaresVectors.C'
'src/finiteVolume/finiteVolume/gradSchemes/LeastSquaresGrad/LeastSquaresVectors.H'
'src/finiteVolume/finiteVolume/gradSchemes/leastSquaresGrad/leastSquaresVectors.H'
'src/fvOptions/sources/derived/phaseLimitStabilization/PhaseLimitStabilization.C'
'src/fvOptions/sources/derived/phaseLimitStabilization/phaseLimitStabilization.C'
'src/fvOptions/sources/general/semiImplicitSource/SemiImplicitSource.C'
'src/fvOptions/sources/general/semiImplicitSource/semiImplicitSource.C'
'src/OpenFOAM/db/Time/instant/Instant.C'
'src/OpenFOAM/db/Time/instant/instant.C'
'src/OpenFOAM/db/Time/instant/Instant.H'
'src/OpenFOAM/db/Time/instant/instant.H'
'src/OpenFOAM/interpolations/patchToPatchInterpolation/PatchToPatchInterpolation.H'
'src/OpenFOAM/interpolations/patchToPatchInterpolation/patchToPatchInterpolation.H'
'src/OpenFOAM/interpolations/primitivePatchInterpolation/PrimitivePatchInterpolation.H'
'src/OpenFOAM/interpolations/primitivePatchInterpolation/primitivePatchInterpolation.H'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/LduMatrix.C'
'src/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrix.C'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/LduMatrix.H'
'src/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrix.H'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/LduMatrixATmul.C'
'src/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrixATmul.C'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/LduMatrixOperations.C'
'src/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrixOperations.C'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/LduMatrixPreconditioner.C'
'src/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrixPreconditioner.C'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/LduMatrixSmoother.C'
'src/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrixSmoother.C'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/LduMatrixSolver.C'
'src/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrixSolver.C'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/LduMatrixUpdateMatrixInterfaces.C'
'src/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrixUpdateMatrixInterfaces.C'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/SolverPerformance.C'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/solverPerformance.C'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/SolverPerformance.H'
'src/OpenFOAM/matrices/LduMatrix/LduMatrix/solverPerformance.H'
'src/OpenFOAM/matrices/LduMatrix/Preconditioners/DiagonalPreconditioner/DiagonalPreconditioner.C'
'src/OpenFOAM/matrices/lduMatrix/preconditioners/diagonalPreconditioner/diagonalPreconditioner.C'
'src/OpenFOAM/matrices/LduMatrix/Preconditioners/DiagonalPreconditioner/DiagonalPreconditioner.H'
'src/OpenFOAM/matrices/lduMatrix/preconditioners/diagonalPreconditioner/diagonalPreconditioner.H'
'src/OpenFOAM/matrices/LduMatrix/Preconditioners/NoPreconditioner/NoPreconditioner.C'
'src/OpenFOAM/matrices/lduMatrix/preconditioners/noPreconditioner/noPreconditioner.C'
'src/OpenFOAM/matrices/LduMatrix/Preconditioners/NoPreconditioner/NoPreconditioner.H'
'src/OpenFOAM/matrices/lduMatrix/preconditioners/noPreconditioner/noPreconditioner.H'
'src/OpenFOAM/matrices/LduMatrix/Solvers/DiagonalSolver/DiagonalSolver.C'
'src/OpenFOAM/matrices/lduMatrix/solvers/diagonalSolver/diagonalSolver.C'
'src/OpenFOAM/matrices/LduMatrix/Solvers/DiagonalSolver/DiagonalSolver.H'
'src/OpenFOAM/matrices/lduMatrix/solvers/diagonalSolver/diagonalSolver.H'
'src/OpenFOAM/matrices/LduMatrix/Solvers/SmoothSolver/SmoothSolver.C'
'src/OpenFOAM/matrices/lduMatrix/solvers/smoothSolver/smoothSolver.C'
'src/OpenFOAM/matrices/LduMatrix/Solvers/SmoothSolver/SmoothSolver.H'
'src/OpenFOAM/matrices/lduMatrix/solvers/smoothSolver/smoothSolver.H'
'src/OpenFOAM/meshes/MeshObject/MeshObject.C'
'src/OpenFOAM/meshes/MeshObject/meshObject.C'
'src/OpenFOAM/meshes/primitiveMesh/PrimitivePatch/PrimitivePatch.H'
'src/OpenFOAM/meshes/primitiveMesh/primitivePatch/primitivePatch.H'
'src/OpenFOAM/meshes/primitiveShapes/objectHit/PointHit.H'
'src/OpenFOAM/meshes/primitiveShapes/objectHit/pointHit.H'
'src/OpenFOAM/meshes/primitiveShapes/objectHit/PointIndexHit.H'
'src/OpenFOAM/meshes/primitiveShapes/objectHit/pointIndexHit.H'
'src/phaseSystemModels/multiphaseInter/phasesSystem/InterfaceCompositionModel/InterfaceCompositionModel.C'
'src/phaseSystemModels/multiphaseInter/phasesSystem/interfaceCompositionModel/interfaceCompositionModel.C'
'src/phaseSystemModels/multiphaseInter/phasesSystem/InterfaceCompositionModel/InterfaceCompositionModel.H'
'src/phaseSystemModels/multiphaseInter/phasesSystem/interfaceCompositionModel/interfaceCompositionModel.H'
'src/phaseSystemModels/reactingEuler/multiphaseSystem/interfacialCompositionModels/interfaceCompositionModels/InterfaceCompositionModel/InterfaceCompositionModel.C'
'src/phaseSystemModels/reactingEuler/multiphaseSystem/interfacialCompositionModels/interfaceCompositionModels/interfaceCompositionModel/interfaceCompositionModel.C'
'src/phaseSystemModels/reactingEuler/multiphaseSystem/interfacialCompositionModels/interfaceCompositionModels/InterfaceCompositionModel/InterfaceCompositionModel.H'
'src/phaseSystemModels/reactingEuler/multiphaseSystem/interfacialCompositionModels/interfaceCompositionModels/interfaceCompositionModel/interfaceCompositionModel.H'
'src/thermophysicalModels/chemistryModel/chemistryModel/BasicChemistryModel/BasicChemistryModel.C'
'src/thermophysicalModels/chemistryModel/chemistryModel/basicChemistryModel/basicChemistryModel.C'
'src/thermophysicalModels/chemistryModel/chemistryModel/BasicChemistryModel/BasicChemistryModel.H'
'src/thermophysicalModels/chemistryModel/chemistryModel/basicChemistryModel/basicChemistryModel.H'
'src/thermophysicalModels/chemistryModel/chemistryModel/BasicChemistryModel/BasicChemistryModelI.H'
'src/thermophysicalModels/chemistryModel/chemistryModel/basicChemistryModel/basicChemistryModelI.H'
'tutorials/combustion/PDRFoam/flamePropagationWithObstacles/0.orig/B.gz'
'tutorials/combustion/PDRFoam/flamePropagationWithObstacles/0.orig/b.gz'
'wmake/rules/General/CGAL'
'wmake/rules/General/cgal'
</pre>
It should be very easy to rename the conflicting directories and files maybe by adding an `_` to the end of some.https://develop.openfoam.com/Development/ThirdParty-common/-/issues/63build problems with Paraview-5.10 and gcc482021-12-31T13:28:05ZPrashant Sonakarbuild problems with Paraview-5.10 and gcc48Various problems noted (probably not to be fixed) and workarounds to get it compilingVarious problems noted (probably not to be fixed) and workarounds to get it compilinghttps://develop.openfoam.com/Development/openfoam/-/issues/2164Simulation hangs when sampling sets of type face.2021-12-20T12:18:01ZTom LauriksSimulation hangs when sampling sets of type face.I have an LES of a half open channel (empty atmospheric boundary layer). The domain is a cuboid. The mesh is built with blockMesh, without grading, and the cells are nearly uniform. I use the pimpleFoam solver. I'm using openfoam v2012. ...I have an LES of a half open channel (empty atmospheric boundary layer). The domain is a cuboid. The mesh is built with blockMesh, without grading, and the cells are nearly uniform. I use the pimpleFoam solver. I'm using openfoam v2012.
I'm trying to sample on a line in my domain, running from one side to the opposing side, somewhere though the middle of my domain and parallel with one of the coordinate axes. I'm using sets from libsampling.so. I'm trying to use the type face, which should sample at intersections of the specified line and mesh cell faces. As my mesh cells are evenly spaced, this is very convenient.
I've noticed that my simulation sometimes hangs and sometimes not. By hanging I mean, that the log file from calling pimpleFoam > log is created, and that the simulation doesn't stop, but simply gets stuck at a certain line in the log file. E.g. during the last simulation where I had this problem, the simulation stopped at the line containing "outlet":
```
Creating finite volume options from "constant/fvOptions"
No finite volume options present
Courant Number mean: 0.001365 max: 0.0013832
fieldAverage fieldAverage1:
Restarting averaging for fields:
U: starting averaging at time 0
turbulenceFields turbulenceFields1: storing fields:
turbulenceProperties:R
Reading set description:
buildings
inlet
outlet
```
I've furthermore noticed that when I adjust one of the coordinates of the line, then the simulation sometimes doesn't hang anymore and sometimes it still hangs.
This seems like a bug in the sampling application.https://develop.openfoam.com/Development/openfoam/-/issues/2309Overset cannot identify right acceptor and donor2021-12-18T12:18:58ZhaidongOverset cannot identify right acceptor and donorThe overset cannot run properly when the createBaffles utility was used. There comes a very large velocity abnormally around the baffle. I guess it was caused by the wrong acceptor cells chosen.
The first page is overset mesh. The yello...The overset cannot run properly when the createBaffles utility was used. There comes a very large velocity abnormally around the baffle. I guess it was caused by the wrong acceptor cells chosen.
The first page is overset mesh. The yellow bar is the baffle created by the createBaffles utility.
![图片1](/uploads/2115a92846a8e8efecb1c36e28b0a09f/图片1.png)
The second page is background mesh. It can be seen that the baffle wall is detected and marked as HOLE.
![图片2](/uploads/2d49333715e963dd47f61634b5b2667a/图片2.png)
However, the interpolation cell around baffle on overset grid cannot find any donors from background mesh.
![图片3](/uploads/980d7da527836386dd161b34f0c9e7f4/图片3.png)https://develop.openfoam.com/Development/openfoam/-/issues/2161Potential wrong behavior of particles in MPPICInterFoam when using MRF2021-12-17T14:59:00ZRiccardo RossiPotential wrong behavior of particles in MPPICInterFoam when using MRFI'm opening this ticket as a follow up to #1941 after running the same test with MPPICInterFoam as requested by @Sergio.
As you can see from the two video attached, the standard MPPICInterFoam solver behaves essentially in the same way ...I'm opening this ticket as a follow up to #1941 after running the same test with MPPICInterFoam as requested by @Sergio.
As you can see from the two video attached, the standard MPPICInterFoam solver behaves essentially in the same way as my custom solver, i.e. water phase is convected by relative velocity in the MRF region of the standard mixerVessel tutorial used here whereas the particles are not.
If one switches to drag force given by relative velocity in the MRF region as I did in my modified custom solver, then the particles behaves correctly when looking at the reference AMI based simulation, where the MRF region is replaced by the actually moving mesh.
Looking forward to hearing your thoughts.
[mixerVesselWater.avi](/uploads/af4eb236f4797d81f9ba941b91bd1587/mixerVesselWater.avi)
[mixerVesselParticles.wmv](/uploads/5a00e673f191b794fe67d1d0c6cca1b0/mixerVesselParticles.wmv)https://develop.openfoam.com/Development/openfoam/-/issues/2303Dynamic mesh capabilities for multiphase solvers2021-12-16T13:17:56ZBas NieuwboerDynamic mesh capabilities for multiphase solvers### Functionality to add/problem to solve
Merge request https://develop.openfoam.com/Development/openfoam/-/merge_requests/505 added the dynamic mesh capabilities to the following existing solvers: `buoyantBoussinesqPimpleFoam`, `buoyant...### Functionality to add/problem to solve
Merge request https://develop.openfoam.com/Development/openfoam/-/merge_requests/505 added the dynamic mesh capabilities to the following existing solvers: `buoyantBoussinesqPimpleFoam`, `buoyantPimpleFoam` and
`rhoCentralFoam`. I was wondering if it would it be possible to add these capabilities also to multi-phase solvers such as:
- driftFluxFoam
- twoPhaseEulerFoam
- multiphaseEulerFoam
I use the driftFluxFoam solver extensively for sand-water mixtures and the implementation of twoPhaseEulerFoam solver, would be a good example for using implementing the dynamic mesh capabilities in SedFoam.
### Target audience
Users who want to do multi-phase simulations with rotating geometries. For example mixing in the chemical industry. Or users who want to use adaptive mesh refinement for (compuational expensive) multi-phase simulations.
### Proposal
The foundation version added the dynamic mesh to the multiphaseEulerFoamsolver with an mixerVessel example case, which might be a good start point for both the coding and the verification?
https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/applications/solvers/multiphase/multiphaseEulerFoam/multiphaseEulerFoam/
https://github.com/OpenFOAM/OpenFOAM-dev/tree/master/tutorials/multiphase/multiphaseEulerFoam/laminar/mixerVesselAMI2D
If needed, I can provide a dynamic mesh case for the mixervessel for the driftFlux solver based on: https://develop.openfoam.com/Development/openfoam/-/blob/master/tutorials/multiphase/driftFluxFoam/RAS/mixerVessel2D/.
~"feature request" ~"integration: openfoam.org"https://develop.openfoam.com/Development/ThirdParty-common/-/issues/62Cgal/boost does not properly set -toolset parameter when using non gcc compiler.2021-12-15T18:39:06ZFelix LeClairCgal/boost does not properly set -toolset parameter when using non gcc compiler.When etc/bashrc has wm_compiler set to use the intel compiler suite (Icc), and wmake all | ./Allmake is called, cgal and boost do no have the -toolset variable set to pass -toolset=intel-linux to makeCGAL.
related to bootsrap.sh is tha...When etc/bashrc has wm_compiler set to use the intel compiler suite (Icc), and wmake all | ./Allmake is called, cgal and boost do no have the -toolset variable set to pass -toolset=intel-linux to makeCGAL.
related to bootsrap.sh is that it does not seem to pass 'openmpi yes ;' causing performance degradationshttps://develop.openfoam.com/Development/openfoam/-/issues/2265surfaceAlignedSBRStress mesh motion solver not working2021-12-14T23:08:59ZSaeedsaeed.salehi@chalmers.sesurfaceAlignedSBRStress mesh motion solver not working<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The surfaceAlignedSBRStressFvMotionSolver mesh motion solver seems quite interesting to me and fits my research area. However, it appears that it does not work. The simulation crashes at the very first iteration with following error:
`--> FOAM FATAL ERROR: (openfoam-2106)`\
` [cellDisplacement[0 1 -1 0 0 0 0] ] + [div(sigmaD)[0 -1 0 0 0 0 0] ]`
### Steps to reproduce
Replace the mesh motion solver in the SnakeRiverCanyon tutorial with surfaceAlignedSBRStress. Extra entities need to be added to the dynamicMeshDict. For instance one might add the following lines:
`surfaces ("AcrossRiver.stl");`\
`nNonOrthogonalCorr 4;`
Also, a scheme needs to be provided for the "div(sigmaD)" in the fvSchemes. Then, run the case with the moveDynamicMesh utility and you will see the error.
### Example case
The above-described reproduction test case is also attached.
[surfaceAlignedSBRStress.tar.gz](/uploads/ef13f393a7a0f973a7d59d56bfbedbb5/surfaceAlignedSBRStress.tar.gz)
### What is the current *bug* behaviour?
The surfaceAlignedSBRStress mesh motion solver is similar to the displacementSBRStress with an extra source term to make the close cells to an STL surface aligned to the surface. I am not sure what is wrong here. The implementation of the source term seems rather complex. But since there is a dimensionality check error, it could be that the formulation is somehow not correct. The error is thrown when the DEqn is to be constructed.
### What is the expected *correct* behavior?
The expected correct behavior is to run without error!!!
### Environment information
I checked this on v1912, v2006, v2012, and v2106. They all throw the same error.https://develop.openfoam.com/Development/openfoam/-/issues/2131refineFieldDirs tutorial produces warnings at iter62021-12-13T17:37:24ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comrefineFieldDirs tutorial produces warnings at iter6<!--
*** 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 -->
From iter5 to iter6 the refineMesh stars complaining
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```tutorials/mesh/refineMesh/refineFieldDirs```
Run step by step (remove the -overwrite). Going from 5 to 6 it will complain:
```
cellCuts : constructor from cellCutter
--> FOAM Warning :
From void Foam::cellCuts::setFromCellCutter(const Foam::cellLooper &, const List<Foam::refineCell> &)
in file meshCut/cellCuts/cellCuts.C at line 2435
Found loop on cell 1 that resulted in an unexpected bad cut.
Suggestions:
- Turn on the debug switch for 'cellCuts' to get geometry files that identify this cell.
- Also keep in mind to check the defined reference directions, as these are most likely the origin of the problem.
```
Switch on debug for more info
```
DebugSwitches
{
cellCuts 2;
}
```
### 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 : v2106
### Possible fixes
Since topo is not very complex and the cuts are still made ok maybe it is just a geometric tolerance?Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2295swirl bc does not handle cyclic being decomposed2021-12-10T19:57:14ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comswirl bc does not handle cyclic being decomposed### Functionality to add/problem to solve
swirl bc 'sits' on a cyclic patch. However the patch might get decomposed into a processorCyclic (if the owner and neighbour are not on the same processor). This looses the extra physics from th...### Functionality to add/problem to solve
swirl bc 'sits' on a cyclic patch. However the patch might get decomposed into a processorCyclic (if the owner and neighbour are not on the same processor). This looses the extra physics from the swirl/jump bc (since it has zero faces on the original patch). In addition the particular swirlVelocity bc expects at least one local face on the patch to be able to calculate the swirl axis.
### Proposal
Avoid by e.g. having decomposition constraints:
```
constraints
{
patches
{
//- Keep owner and neighbour on same processor for faces in patches
// (only makes sense for cyclic patches and cyclicAMI)
type preservePatches;
patches (cyclic);
}
}
```
Or maybe add constraint override to decomposePar so the bc type is now again swirl instead of processorCyclic. However now this patch might not be present on all processors or at a different index in the patch list.
@Prashant @markhttps://develop.openfoam.com/Development/openfoam/-/issues/2141Add support for user defined liquidProperties2021-12-10T13:12:14ZDanielAdd support for user defined liquidProperties### Functionality to add/problem to solve
Currently only hardcoded liquids can be used for modeling Lagrangian particles such as water and a few selected hydrocarbons.
This limits the possibility of modeling liquid injection for cases o...### Functionality to add/problem to solve
Currently only hardcoded liquids can be used for modeling Lagrangian particles such as water and a few selected hydrocarbons.
This limits the possibility of modeling liquid injection for cases other than liquid fuel combustion.
### Target audience
Users who want to model injecting ammonia for nitric oxide reduction.
### Proposal
Implement similar functionality to what is available through generic [liquid](https://github.com/OpenFOAM/OpenFOAM-dev/tree/master/src/thermophysicalModels/thermophysicalProperties/liquidProperties/liquid).
### Funding
I already have a working implementation and can provide the patch/merge reguest.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2272surface file reader for ftr and off files2021-12-10T13:06:38ZBas Nieuwboersurface file reader for ftr and off files<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
I've come across two issues with surface files:
- surfaceTransformPoints does not support ftr file.
- off files are read without reading the region (patch) information. While it seems to be present in the file.
Both these issues are non-essential for me, since I never use these file types. I've created this bug-report to let you know the inconsistency in the use of these files. Therefore a result of this report could be that it is not worth the time to look into this.
### Steps to reproduce
I found the issue in creating a tool, described in: In https://develop.openfoam.com/Development/openfoam/-/issues/2239#note_54832
The test.sh file in this post, illustrates both issues. @mark already commented on the issues in this post: https://develop.openfoam.com/Development/openfoam/-/issues/2239#note_54835
### 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
OpenFOAM version : v2106v2212https://develop.openfoam.com/Development/openfoam/-/issues/2259Decomposition method issue2021-12-09T16:44:05ZAshutosh MauryaDecomposition method issueI don't know whether it is a issue or limitation of hierarchical method. I ran the simulation on 12 processors to calculate force on a airfoil. The issue is with hierarchical decomposition method gives wrong result while scotch gives cor...I don't know whether it is a issue or limitation of hierarchical method. I ran the simulation on 12 processors to calculate force on a airfoil. The issue is with hierarchical decomposition method gives wrong result while scotch gives correct result.https://develop.openfoam.com/Development/openfoam/-/issues/2117codedFunctionObjects: Info stream in #codeRead is executed twice + Feature re...2021-12-09T16:43:11ZHendrik HetmanncodedFunctionObjects: Info stream in #codeRead is executed twice + Feature request: Info stream number of total cells to standard log.<!--
*** 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 -->
If an Info stream is executed in the #codeRead section of a codedFunctionObject, the line is shown twice. (I don't know if any variables might be assigned twice too?)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Put a line
`Info << "Test" << endl;`
into the #codeRead section of a codedFunctionObject and run the case.
### Example case
I attached a codedFunctionObject "addCellsInfo" to the example case. This is also sort of a feature request: It would be very neat to report the number of total cells in the mesh to standard log on mesh built-up. This would increase the information content of the logs and consequently make it possible to compare the performance between 2 runs just by analyzing their log files.
[pitzDaily_codedfObj.tar.gz](/uploads/8cf5416c96d1d238c5f91dc041faa46d/pitzDaily_codedfObj.tar.gz)
<!--
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 -->
### 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 : 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 and also in OF7
- Operating system : openSUSE
- 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
-->Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2225chtMultiRegionSimpleFoam - frozenFlow mode results in large errors2021-12-06T20:45:03ZKumar KrishnachtMultiRegionSimpleFoam - frozenFlow mode results in large errorsRunning chtMultiRegionSimpleFoam on a converged flow by activating the frozenFlow switch to calculate the heat transport results in fairly large deviations in the final temperatures as opposed to running the case in the "normal" (fully c...Running chtMultiRegionSimpleFoam on a converged flow by activating the frozenFlow switch to calculate the heat transport results in fairly large deviations in the final temperatures as opposed to running the case in the "normal" (fully coupled) mode.
Attached is a 2D case to illustrate the problem. It is a simple case of water flowing at high velocity through a narrow channel above a copper plate which is heated from below.
To reproduce the problem, please do the following steps:
(1) Run the case as it is. The case runs in fully coupled mode for 2000 iterations.
(2) Run the case for the first 1000 iterations by turning off the (h|e) solvers in the ./system/copper/fvSolution and ./system/water/fvSolution subdirectories, i.e, please activate the 'maxIter 0' statement.
(3) Now please turn on the frozenFlow keyword in the PIMPLE subdict and run for another 1000 iterations. In this case, deactivate the 'maxIter 0' statement in the respective fvSolution dicts.
We can see that the Temp. results obtained at the end of 2000 iterations in both cases are very different.
[ConjCopperWater.tar.gz](/uploads/9bbe5fd5dedce1ef301d0f0f8c86b96a/ConjCopperWater.tar.gz)
**Environment Information**
- OpenFOAM Version: v2106
- Operating System: Windows 10 (MinGW)
- Hardware Info: PC (HP Z240)https://develop.openfoam.com/Development/openfoam/-/issues/2156waveMethod called from inverseDistanceCellCellStencil returns error for empty...2021-11-19T15:20:54ZLouiswaveMethod called from inverseDistanceCellCellStencil returns error for empty source processors
### Summary
inverseDistanceCellCellStencil calls waveMethod::calculate(tgtMesh, srcMesh, tgtToSrcAddr) which then calls
FaceCellWave<meshToMeshData, meshToMeshData::trackData> calc
(
src,
...
### Summary
inverseDistanceCellCellStencil calls waveMethod::calculate(tgtMesh, srcMesh, tgtToSrcAddr) which then calls
FaceCellWave<meshToMeshData, meshToMeshData::trackData> calc
(
src,
changedFaces,
changedFacesInfo,
faceData,
cellData,
src.globalData().nTotalCells(), // max iterations
td
);
which will return an error when src.globalData().nTotalCells() is 0.
A solution is to add 1 (works for me) or maybe, more logical, make a max(1,src.globalData().nTotalCells())
### What is the current *bug* behaviour?
returns error
> Maximum number of iterations reached. Increase maxIter.
### What is the expected *correct* behavior?
overset runs
### Environment information
I think hierarchical is particularly sensible to this issue.
### Possible fixes
mentioned above
PS: I'm not sure I can get this error for the "standard" code, as I haven't tested if empty src is possible. I'm using a modified B-box inverseDistance scheme...Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/2260forceCoeffs FO: pitchAxis keyword has no effect2021-11-08T08:35:56Zs1291forceCoeffs FO: pitchAxis keyword has no effectWhen using the `forceCoeffs` function object, it seems that the `pitchAxis` keyword has no effect. It is always set to `coordSys_.e2()`
**How to reproduce**
* Example 1: Run the tutorial: `$FOAM_TUTORIALS/incompressible/simpleFoam/simpl...When using the `forceCoeffs` function object, it seems that the `pitchAxis` keyword has no effect. It is always set to `coordSys_.e2()`
**How to reproduce**
* Example 1: Run the tutorial: `$FOAM_TUTORIALS/incompressible/simpleFoam/simpleCar`
* Example 2: Run the tutorial: `$FOAM_TUTORIALS/compressible/sonicFoam/RAS/nacaAirfoil`
Set the `pitchAxis` to some vector , the output in `postProcessing` directory will ignore that and prints the `e2` vector instead.
Checking the source code of the FO, it appears that `pitchAxis` keyword is not read. So, the presence of this keyword in the tutorials dir is _misleading_.
Running:
```
grep -r 'pitchAxis' $FOAM_TUTORIALS
```
Returns 7 tutorials using that keyword.
**OpenFOAM version**
* OpenFOAM v2106 on Ubuntu 20.04