Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-07-06T12:29:16Zhttps://develop.openfoam.com/Development/openfoam/-/issues/768redistributePar does not do DimensionedFields2021-07-06T12:29:16ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar does not do DimensionedFieldsMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/789BUG: distributedTriSurfaceMesh written to processor*/0/triSurface/2021-07-06T12:34:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: distributedTriSurfaceMesh written to processor*/0/triSurface/Runnning with distributedTriSurfaceMesh:
- runParallel surfaceRedistributePar independent
- rmpirun -np 6 snappyHexMesh -overwrite -parallel
and at end of run I discovered triSurface/ inside the 0/ folders. Don't know which one did it.Runnning with distributedTriSurfaceMesh:
- runParallel surfaceRedistributePar independent
- rmpirun -np 6 snappyHexMesh -overwrite -parallel
and at end of run I discovered triSurface/ inside the 0/ folders. Don't know which one did it.https://develop.openfoam.com/Development/openfoam/-/issues/790BUG: singleCellFvMesh does not support disconnected regions (i.e. only does o...2021-07-06T12:34:35ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: singleCellFvMesh does not support disconnected regions (i.e. only does one cell)Not tested.Not tested.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/962BUG: user specified field not taken into account : vorticity2021-07-06T13:11:43ZPrashant SonakarBUG: user specified field not taken into account : vorticityUser specified velocity field is override by default "U"
can we use following instead?
```
fieldExpression(name, runTime, dict, dict.lookupOrDefault<word>("U","U"))
```
@andy @mark
cross ref : EP#761User specified velocity field is override by default "U"
can we use following instead?
```
fieldExpression(name, runTime, dict, dict.lookupOrDefault<word>("U","U"))
```
@andy @mark
cross ref : EP#761Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1615chtMultiregionFoam relaxation problem2021-07-06T17:09:26ZTj KimchtMultiregionFoam relaxation problemIn the Pimple mode with relaxation of p_rgh, the chtMultiregionFoam solver returns an error message of
"not stored. Use field.storePrevIter()"
I found the solver already includes a function call of storePrevIter().
So I think that it is ...In the Pimple mode with relaxation of p_rgh, the chtMultiregionFoam solver returns an error message of
"not stored. Use field.storePrevIter()"
I found the solver already includes a function call of storePrevIter().
So I think that it is out of my job.
The solver in v1906 is same as the v1912.
With the same fvSolution file, OF-7 runs good.
Could you please check the reason?
My recommendation is to update solutioncontrol classes in v1912 similar to those in OF-7Kutalmış BerçinKutalmış Berçinhttps://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/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/1755strange behaviour when comparing SixDoFRigidBodyMotion, RigidBodyDynamics and...2021-07-07T08:56:01ZGabriel Barajasbarajasg@unican.esstrange behaviour when comparing SixDoFRigidBodyMotion, RigidBodyDynamics and Overset libraries.Hi,
While working in new developments I have come up with an expected results when comparing the three main libraries for rigid body motions (**SixDoFRigidBodyMotion**, **RigidBodyDynamics** and **Overset**) with the tutorial provided i...Hi,
While working in new developments I have come up with an expected results when comparing the three main libraries for rigid body motions (**SixDoFRigidBodyMotion**, **RigidBodyDynamics** and **Overset**) with the tutorial provided in the oficial release.
Please, note that I assume that the **RigidBodyDynamics** gives the correct results, as it has been widely validated.
If I compare (for a sligthly modified version of the tutorial), the results using the **SixDoFRigidBodyMotion** library (in green), and the **RigidBodyDynamics** library (in red), I get the same results (as expected).
![image1](/uploads/7bf3aed75cee43fad50920df823f3774/image1.jpg)
![image2](/uploads/85f4a21dfba6fe134ec865094499892c/image2.jpg)
Then, If I compare (using the same case), the **RigidBodyDynamics** library (in green) against the **Overset** library (in red), I get this weird result in the YAW rotation.
![image3](/uploads/b632116d481366117c67f62f4f7d0d93/image3.jpg)
![image4](/uploads/379d82af50372f0dceb9fae13c608b38/image4.jpg)
If I vary the constraint in the displacement (along axis Z or along axis X), I get the same weird results in the YAW rotation.
![image5](/uploads/ff8fbeacb44873edd3925d5dc3b96c63/image5.jpg)
![image6](/uploads/c62b6515e0ec4ded29e84536e75cb897/image6.jpg)
Please, can you clarify me if it is working correctly the Overset library?
Regards,
Gabihttps://develop.openfoam.com/Development/openfoam/-/issues/1791Make overset and axisymmetric mesh work in combination2021-07-07T09:04:13ZMike WorthMake overset and axisymmetric mesh work in combination### Functionality to add/problem to solve
Currently an attempt to use both overset meshing and axisymmetric geometry doesn't work is a hole sits against the axis. The 'hole finding' algorithm sees a 'C-shape' rather than a topological h...### Functionality to add/problem to solve
Currently an attempt to use both overset meshing and axisymmetric geometry doesn't work is a hole sits against the axis. The 'hole finding' algorithm sees a 'C-shape' rather than a topological hole, so doesn't correctly classify it.
### Target audience
(Who will benefit from the changes?)
(What type of cases?)
Anyone using overset meshing to model axially moving axisymmetric cases. There are loads of applications, but some that jump to mind are valves, objects in tubes, moving probes in tanks etc.
### Proposal
(How are we going to solve the problem?)
Adjust the 'hole finding' algorithm to recognise axis type boundaries and apply the hole assignment to regions completely bounded by either mesh or axis.
### What does success look like, and how can we measure that?
(What are the success factors and acceptance criteria? e.g. test cases, error margins)
### Links / references
(Links to literature, supporting information)
### Funding
(Does the functionality already exist/is sponsorship available?)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/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/1844REVIEW: laplacianFoam2021-07-07T09:56:34ZKutalmış BerçinREVIEW: laplacianFoamKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/849overlay mesh does not appear to support scrapers (moving a wall across a sta...2021-07-07T10:42:04ZAdminoverlay mesh does not appear to support scrapers (moving a wall across a stationary wall witth zero gap)[overDriftFluxDyMFoam.tar.gz](/uploads/567afa8fa4fc989663a0122d298a0f99/overDriftFluxDyMFoam.tar.gz)[scraperDahl3D.tar.gz](/uploads/3cba3cd18fff616cded4023448e6973a/scraperDahl3D.tar.gz)
I have created a application from driftFluxFoam ex...[overDriftFluxDyMFoam.tar.gz](/uploads/567afa8fa4fc989663a0122d298a0f99/overDriftFluxDyMFoam.tar.gz)[scraperDahl3D.tar.gz](/uploads/3cba3cd18fff616cded4023448e6973a/scraperDahl3D.tar.gz)
I have created a application from driftFluxFoam extending its capability to include overlay dynamic meshes. It compiles and runs, although I can't claim to be expert enough in the basic physics to say if the .H file modifications, or the Solver options I chose are correct/good. By runs I mean the solutions don't immediately crash or give error messages, and the scraper mesh rotates as requested. However, it gives very high values, visible in paraFoam, for the alpha.sludge concentrations between the base of the rotating scraper and the floor of the tank. These concentrations should be zero as there should be a zero gap.
Might be a bug, might be my poor implementation of overDriftFluxDyMFoam, might be a limitation in the meshing that it doesn't support a moving wall scraping a stationary wall without a gap.
The overDriftFluxDyMFoam.tar.gz file includes a couple of extra rheologies (Casson, Herschel Bulkley). The scraperDahl3D.tar.gz file is a 3D version of the Dahl tutorial with a centred scraper added at the base of the box. A version without the scraper had no issues out to 3600 sim-seconds.
Running the scraper at lower speed caused much higher maximum values for alpha.sludge and the solution went to very short time intervals and then crashed after about 60 sim-seconds.
\## Reattaching the author to the issue ticket: @DenysW ##https://develop.openfoam.com/Development/openfoam/-/issues/1925block face orientation checks don't consider the curved edges2021-07-07T10:44:14ZHassan Kassemblock face orientation checks don't consider the curved edgesHello,
The extra check introduced by commit 3aa78f2bf treats the block in the same way as ``cellShape``. I reported before to the foundation fork, [here](https://bugs.openfoam.org/view.php?id=3349). A more robust check with an option to...Hello,
The extra check introduced by commit 3aa78f2bf treats the block in the same way as ``cellShape``. I reported before to the foundation fork, [here](https://bugs.openfoam.org/view.php?id=3349). A more robust check with an option to disabled it has been introduced by this [commit](https://github.com/OpenFOAM/OpenFOAM-dev/commit/471810313636980d142a995369815aa9d5db5dd8).
I understand that both forks are not the same and you do not merge everything to keep the backward compatibility as possible. But I think this is a critical issue and I hope you consider it.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1944alphaEqn is missing alphac term in MPPICInterFoam2021-07-07T10:46:38Zutkan CaliskanalphaEqn is missing alphac term in MPPICInterFoamalphac should be added in line 106 of alphaEqn.H in MPPICInterFoam solver.
There is another note to this solver with the usage of MULESCorr during simulations. I think alpha field is not correctly solved without MULESCorr. Without MULE...alphac should be added in line 106 of alphaEqn.H in MPPICInterFoam solver.
There is another note to this solver with the usage of MULESCorr during simulations. I think alpha field is not correctly solved without MULESCorr. Without MULESCorr, twoPhasePachuka tutorial crashes at about 0.9s. The issue can be reproduced on twoPhasePachuka case by commenting out MULESCorr in fvSolution, and changing maxCo and maxAlphaCo to 0.5.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1985snappyHexMesh : unwanted illimited refinement between curved triangulated sur...2021-07-07T10:54:24ZRenaud GabansnappyHexMesh : unwanted illimited refinement between curved triangulated surfaces<!--
*** 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
It has already been reported that snappyHexMesh creates small gaps between curved triangulated surfaces when the stl don't match exactly (https://develop.openfoam.com/Development/openfoam/-/issues/1528). It seems that it causes another problem when using the gapLevel refinement : these small gaps are seen as regions to be refined and since they are very small, the refinement will be "illimited" all around the curved interface.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
The issue can be reproduced by applying snappyHexMesh on a multiregions case with a curved interface between two regions and with the different regions specified by different stl files, and by putting a high enough maximum level of refinement into the gapLevel of either one of the regions.
<!-- How one can reproduce the issue - this is very important -->
### Example case
Here is a case that illustrates the problem. A fluid with curved faces is inside a cubic solid and the triangulations don't match.
![image](/uploads/188cca2d2f3c44d5c7e8b0f11c94db8d/image.png)
![image](/uploads/189c20dc1537e6e146324b48a291581a/image.png)
Then a maximum gap refinement of 4 is applied and we see the result on a clipped inside view :
![image](/uploads/af22186f155f817e8d63f013eae02c30/image.png)
The same with a maximum gap refinement of 5 :
![image](/uploads/a21582bf6fd53a9e8f59b660e3dada9c/image.png)
The same as the last one but with nCellZoneIter = -1 :
![image](/uploads/b9af3706fb6ef588ec488f6adce89f69/image.png)
<!--
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?
While looking for gaps during the procedure, snappyHexMesh will regard these unwanted gaps as actual ones and refine the surrounding cells further. Even though we can close the gaps with nCellZoneErodeIter = -1, the refinement still takes place before.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The interface should be refined just as any non-curved interface. Therefore, one should be able to set an arbitrary high maximum level of refinement and not end up with cells being refined up to this level.
<!-- What you should see instead -->
### Relevant logs and/or images
See above.
<!--
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 : v2012
Operating system : centos 7
<!--
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
-->
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/1989Feature: Mesh motion and adaptive mesh refinement2021-07-07T10:55:37ZAkash PatelFeature: Mesh motion and adaptive mesh refinement### Functionality to add/problem to solve
Enabling mesh motion to work along with adaptive mesh refinement
### Target audience
Beneficial in fluid structural interaction cases and moving mesh simulations.
### What does success look l...### Functionality to add/problem to solve
Enabling mesh motion to work along with adaptive mesh refinement
### Target audience
Beneficial in fluid structural interaction cases and moving mesh simulations.
### What does success look like, and how can we measure that?
I have done some work towards this with no apparent success. Motion engine doesn't recognize newly refined mesh points.
I looked at [this](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/dynamicFvMesh/dynamicRefineFvMesh/dynamicRefineFvMesh.C#L432) commented code and it tells me that someone in past has tried to work on this feature but it hasn't been enabled yet.
How challenging this has been (if the OpenFOAM team has already tried this) or would be to implement? Anyone can provide me with the level of effort it would require? I have not seen any solid efforts towards this in the community.
Thank you!https://develop.openfoam.com/Development/openfoam/-/issues/1990Possible bug in snappyHexMesh for large coordinates2021-07-07T10:56:02ZEden Furtak-ColePossible bug in snappyHexMesh for large coordinates<!--
*** 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 -->
For large coordinates, snappyHexMesh stops refinement after two levels.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
snappyHexMesh stops refinement in directions corresponding to large coordinates. This is a problem when working in geographic coordinates. In the attached casefile, will see that refinement is performed in the x and z directions, but stops after two levels in the y direction. I suspect that this is because the y coordinate is on the order of e+6, while the x direction is e+5, and z is close to zero. I don't know if this is a known issue, I have not found any information about it.
### 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
-->
[bad_mesh.tar.xz](/uploads/4e0c7967a2e068d2eda6e613b7333828/bad_mesh.tar.xz)
I attached a very small casefile. Run blockMesh and snappyHexMesh.
### What is the current *bug* behaviour?
<!-- What actually happens -->
No refinement in the y direction after two levels.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Refinement in all directions, regardless of coordinates.
### 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.
-->
![image](/uploads/d23fadba8294f683095cbb11fa945c58/image.png)
### 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 : 2006
- Operating system : CentOS 7
- Hardware info : Dell Precision 3630
- 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
-->
If the case is translated to the origin the problem goes away. This makes me think this is a bug, but I can't point to the part of the code that is causing this. snappyHexMesh finishes without errors.https://develop.openfoam.com/Development/openfoam/-/issues/1997Outer boundaries deformed during layer addition in snappyHexMesh2021-07-07T10:58:55ZChiara PesciOuter boundaries deformed during layer addition in snappyHexMesh<!--
*** 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 outer boundaries of a mesh are deformed when adding layers with snappyHexMesh. The issue occurs only when all the outer boundaries/patches belong to a single patch. If the outer block is composed by separated patches, i.e. inlet, outlet, front, etc., then the outer boundary is not deformed during the layer addition step.
### Steps to reproduce
Run the tutorial [airfoilWithLayers](https://develop.openfoam.com/Development/openfoam/-/tree/master/tutorials/mesh/snappyHexMesh/airfoilWithLayers) and check the outer patches.
### Example case
Attached you can find a modified version of the tutorial mentioned above to reproduced the two cases, one with single outer patch and one with separated patches from blockMesh.
[airfoilWithLayers_outerBoundary.tgz](/uploads/2b273eb3a3fb231bb4026b93c80210d3/airfoilWithLayers_outerBoundary.tgz)
### What is the current *bug* behaviour?
During the layer addition phase in snappyHexMesh the outer boundary is deformed together with the internal mesh; see attached figure.
This occurs only when the outer boundary is a single patch.
### What is the expected *correct* behavior?
The outer boundary should not be deformed; see the right picture in the figure attached.
### Relevant logs and/or images
![compare_snap](/uploads/86f6a025944b4d1e9c3e6abeef844eaf/compare_snap.png)
![compare_addLayers](/uploads/9296282ed4029b3ce858754d26aa93ca/compare_addLayers.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012
- Operating system : ubuntu
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2018'fourth' snGrad Scheme2021-07-07T11:01:22ZGuanyang Xue'fourth' snGrad Scheme### Functionality to add/problem to solve
Fourth-order snGrad scheme with non-orthogonal correction.
### Target audience
Fourth order gradient can be used in the removal of field decoupling.
Currently the workaround for the Laplacia...### Functionality to add/problem to solve
Fourth-order snGrad scheme with non-orthogonal correction.
### Target audience
Fourth order gradient can be used in the removal of field decoupling.
Currently the workaround for the Laplacian of a vector is:
1. Create a volTensorField using `fourth` grad scheme.
2. Apply `Gauss linear` div scheme to evaluate its laplacian.
The extra step can be avoided if `fourth` snGrad scheme is available.
### Proposal
For some reason it's available in the official user's guide but not implemented in both .com and .org version.
![Screen_Shot_2021-03-01_at_2.32.46_PM](/uploads/bbd8380782ea6afd043d343f404b2b91/Screen_Shot_2021-03-01_at_2.32.46_PM.png)
The code is already available in foam-extend:
https://sourceforge.net/p/foam-extend/foam-extend-4.1/ci/nextRelease/tree/src/finiteVolume/finiteVolume/snGradSchemes/fourthSnGrad/
so should be easy to add.
### What does success look like, and how can we measure that?
Applying Laplacian with 4th order snGrad directly like:
```
Gauss linear fourth;
```
The below screenshot is a 2D viscoelastic flow benchmark case
![fourth](/uploads/cfc13d1d0c88b335827ab7384dd368f1/fourth.png)
Left: `fourth` gradient then `Gauss linear` divergence workaround . Right: `Gauss linear corrected` laplacian scheme.
### Links / references
The paper below is a direct application of the fourth order scheme:(they use foam-extend in their paper)
https://www.sciencedirect.com/science/article/pii/S0045793018300045
A stable numerical implementation of integral viscoelastic models in the OpenFOAM® computational library, Araújo et al. 2018
![Screen_Shot_2021-03-01_at_3.23.12_PM](/uploads/b1baebea501d5d41179cbd56f1bf914a/Screen_Shot_2021-03-01_at_3.23.12_PM.png)
### FundingKutalmış BerçinKutalmış Berçin