Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-07-07T10:58:55Zhttps://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/2984Output format needs nl (function object mapFields)2023-11-03T16:07:50ZTobias HolzmannOutput format needs nl (function object mapFields)Hey all,
the mapFields function object requires a new line (nl or endl) at this code line:
https://develop.openfoam.com/Development/openfoam/-/blame/develop/src/functionObjects/field/mapFields/mapFieldsTemplates.C#L155
Thanks,
TobiHey all,
the mapFields function object requires a new line (nl or endl) at this code line:
https://develop.openfoam.com/Development/openfoam/-/blame/develop/src/functionObjects/field/mapFields/mapFieldsTemplates.C#L155
Thanks,
TobiKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2786Overcompensation of anisotropy in porous models (DarcyForchheimer and fixedCo...2023-07-20T08:24:49ZBernhard GschaiderOvercompensation of anisotropy in porous models (DarcyForchheimer and fixedCoeff)The porous media models add the porous resistance to the matrix of the velocity equation. To do this they have to reduce the resistance tensor to a scalar that is added to the diagonal of the matrix and compensate with an explicit source...The porous media models add the porous resistance to the matrix of the velocity equation. To do this they have to reduce the resistance tensor to a scalar that is added to the diagonal of the matrix and compensate with an explicit source term that models the rest of the resistance tensor. For an isotropic porosity (where the tensor is the identity tensor times a factor) no explicit correction should be necessary.
The current implementation uses the trace of the tensor. For an isotropic porosity (where all three diagonal elements have the same value) this is three times higher than the term that should be actually added. This leads to a significant (unnecessary) explicit correction. This is stable (high diagonal term) but may lead to slower convergence (high source term that works against the diagonal)
The attached patch fixes this by using the biggest diagonal element of the tensor as the implicit part
- for isotropic porosity the explicit correction is almost zero
- for anisotropic porosity the explicit correction for the direction with the greatest contribution is zero (assuming the isotropy is oriented along the cartesian coordinates). For the others there is a correction
Applying the patch doesn't change the results but increases the convergence (in the `compressible/rhoSimpleFoam/angledDuctExplicitFixedCoeff` tutorial applying the patch lowers the number of timesteps till convergence from 639 to 392)
PS: this behaviour has been in OpenFOAM at least since 1.5 and nobody complained so there is a chance that there is a reason for that factor 3 (but I doubt it)
[darcyImplicitCoeffFix.patch](/uploads/ff6265825d1f119e1295f7799194ed37/darcyImplicitCoeffFix.patch)Kutalmış 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/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/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/2204overset patch with setFields2021-09-09T15:48:19ZMatej Formanoverset patch with setFieldsI'm not sure, whether this is bug or a feature so I am going to call it an annoyance.
Let's imagine you have an overset patch, where you are using setFields utility to set alpha.water level.
At the same time you have empty BC oversetPa...I'm not sure, whether this is bug or a feature so I am going to call it an annoyance.
Let's imagine you have an overset patch, where you are using setFields utility to set alpha.water level.
At the same time you have empty BC oversetPatch of type overset (in boundary file and fields files as well).
When you are running setFields setting values on volumetric region, everything is fine,
once you start setting alpha on faces (e.g. to set a fixed value on inlets and outlets) you will receive an error saying oversetPatch needs value entry.
so the oversetPatch in alpha.water file looks like this:
`
oversetPatch
{
type overset;
value uniform 0;
}
`
It is not great nor terrible, but it's ugly.
OF v2106, ubuntu, arm64 standard out of box compilationhttps://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/606paraFoam does not always re-read faceSets/cellSets2021-07-15T19:55:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam does not always re-read faceSets/cellSets- case with sets
- enable 'With Sets'
- switch off caching (though not sure if relevant)
- select some sets
All ok. But now change time (to time without sets) and change back.
- Refresh (since caching switched off)
- Update GUI -> gui sh...- case with sets
- enable 'With Sets'
- switch off caching (though not sure if relevant)
- select some sets
All ok. But now change time (to time without sets) and change back.
- Refresh (since caching switched off)
- Update GUI -> gui shows sets again
- Filters->Extract Block : does not show the sets being present
The only way to actually get the sets back is to deselect one of the sets, apply and re-select.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1239paraFoam needs 0/ directory2020-03-13T14:42:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam needs 0/ directory### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
lid driven cavity
mv 0 0.orig
ln -s 0.001 0.orig
paraFoam now complains about no mesh.### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
lid driven cavity
mv 0 0.orig
ln -s 0.001 0.orig
paraFoam now complains about no mesh.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/915paraFoam starts up with 'Skip 0/ time' enabled2020-03-13T14:42:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam starts up with 'Skip 0/ time' enabled1) Do we still need this?
2) Why do we only select p,U,T and not all fields?1) Do we still need this?
2) Why do we only select p,U,T and not all fields?https://develop.openfoam.com/Development/openfoam/-/issues/3022parallel snappyHexMesh errors2023-11-06T21:38:33ZMadis Listakparallel snappyHexMesh errors### Summary
Module: OpenFabrics (openib) problem, can't run snappyHexMesh in parallel
### Steps to reproduce
I am running openFoam2306 OpenSuse15.5 rpm packages and "tutorials/mesh/snappyHexMesh/gap_detection/" example
and I get an er...### Summary
Module: OpenFabrics (openib) problem, can't run snappyHexMesh in parallel
### Steps to reproduce
I am running openFoam2306 OpenSuse15.5 rpm packages and "tutorials/mesh/snappyHexMesh/gap_detection/" example
and I get an error when I try to execute Allrun and do snappyHexMesh in parallel
[[53808,1],7]: A high-performance Open MPI point-to-point messaging module
was unable to find any relevant network interfaces:
Module: OpenFabrics (openib)
Host: (my computer name)
Caught signal 4 (Illegal instruction: illegal operand)
==== backtrace (tid: 16643) ====
0 0x0000000000016910 __funlockfile() ???:0
1 0x000000000082eb52 fi_getinfo() ???:0
2 0x0000000000828d17 fi_getinfo() ???:0
3 0x0000000000839707 fi_getinfo() ???:0
4 0x0000000000817833 fi_getinfo() ???:0
5 0x000000000005369b fi_getinfo() ???:0
6 0x00000000000048bb ompi_mtl_ofi_progress_no_inline() ???:0
7 0x00000000000a5190 ompi_mtl_base_select() ???:0
8 0x000000000000541a mca_pml_cm_cancel() ???:0
9 0x00000000000ad645 mca_pml_base_select() ???:0
10 0x000000000004c797 ompi_mpi_init() ???:0
11 0x000000000006cbc8 PMPI_Init_thread() ???:0
12 0x000000000000dc42 Foam::UPstream::init() ???:0
13 0x0000000000413feb Foam::argList::argList() ???:0
14 0x000000000001955d main() ???:0
15 0x000000000003524d __libc_start_main() ???:0
16 0x000000000001f9ca _start() /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/../sysdeps/x86_64/start.S:120
--------------------------------------------------------------------------
mpirun noticed that process rank 7 with PID 0 on node (my computer name) exited on signal 4 (Illegal instruction).
and snappyHexMesh is failing
Probably something is not installed or is not compiled correctly.https://develop.openfoam.com/Development/ThirdParty-common/-/issues/64Paraview:5.10.0: catalyst building issue2022-08-04T11:32:33ZPawan GhildiyalParaview:5.10.0: catalyst building issueHi ,
I am using latest release paraview as updated in sourceforge 5.10.0 release.
Build paraview successfully using mesa-llvm and it compiled well.
runTimepostprocessing : compiles well and work well. However catalyst
fail t...Hi ,
I am using latest release paraview as updated in sourceforge 5.10.0 release.
Build paraview successfully using mesa-llvm and it compiled well.
runTimepostprocessing : compiles well and work well. However catalyst
fail to compile with following error. (Note this issue is not there with Paraview-5.10.RC2)
![image](/uploads/b377779ef8b2fda54268a1761d94008a/image.png)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/52paraview building2021-04-17T08:04:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaview building@mark to pull in the requirements can we rephrase as something:
openSUSE
The easiest way of obtaining Paraview is to install the binary version:
```
sudo zypper install paraview-devel
```
Unfortunately this does not install enough to...@mark to pull in the requirements can we rephrase as something:
openSUSE
The easiest way of obtaining Paraview is to install the binary version:
```
sudo zypper install paraview-devel
```
Unfortunately this does not install enough to build our paraFoam reader. However installing above should pull in all the dependencies to build Paraview with our scripts.
If this does not work one can install the dependencies oneselves. The following subset may be enough:
sudo zypper install Mesa-libEGL-devel
sudo zypper install libqt5-qtbase-devel libqt5-qtsvg-devel libqt5-qttools-devel libqt5-qtx11extras
sudo zypper install libXt-devel
```https://develop.openfoam.com/Development/openfoam/-/issues/1016Paraview only reading cases with constant2019-12-11T12:31:11ZRoger AlmenarParaview only reading cases with constantHello,
I just came across an interesting case:
1) I create a blockMesh based on latestTime, hence mesh is located under results folder (like in 0.2/polyMesh).
2) I decompose that case. It creates the processorX folders, which contained 0...Hello,
I just came across an interesting case:
1) I create a blockMesh based on latestTime, hence mesh is located under results folder (like in 0.2/polyMesh).
2) I decompose that case. It creates the processorX folders, which contained 0.2/polyMesh but no constant/folders, as there is nothing there.
3) Paraview cannot read the case based on a "decomposed" input, because there are no processorX/constant folders.
The case is actually valid, just that it cannot be opened in Paraview.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/53Paraview- with python and openmpi>42020-07-09T15:11:49ZPrashant SonakarParaview- with python and openmpi>4Placeholder to resolve issues when building
- Paraview-5.6.3
- Python-2.7
- Openmpi-4.0.3
This fails with mp4py issue as reported in https://gitlab.kitware.com/vtk/vtk/-/issues/17544
We might need a patch for 5.6.3 version or upgrade t...Placeholder to resolve issues when building
- Paraview-5.6.3
- Python-2.7
- Openmpi-4.0.3
This fails with mp4py issue as reported in https://gitlab.kitware.com/vtk/vtk/-/issues/17544
We might need a patch for 5.6.3 version or upgrade to new Paraview ??
@mark @andyv2012https://develop.openfoam.com/Development/openfoam/-/issues/1767Particle erosion issue when injecting lagrangian particles into overset mesh.2021-08-22T19:03:50ZBrandon CoxParticle erosion issue when injecting lagrangian particles into overset mesh.<!--
*** 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 -->
Lagrangian particles fail to identify surfaces within the overset region when using overPimpleDyMFoam or overInterDyMFoam. Because surfaces are not recognized in the overset region, particle erosion cannot be recorded. The particles simply pass through the surfaces within the overset region.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Add Lagrangian particle functionality through the basicKinematicCloud library into overPimpleDyMFoam solver.
Copy the $FOAM_TUTORIAL/incompressible/overPimpleFoam/simpleRotor tutorial.
Add kinematicCloud file to constant directory.
- particles can be injected manually which requires adding another file to specify locations
Add particleErosion to the kinematicCloud file and specify the patch "hole"
Add g file to constant directory
add rhoInf variable to constant/transportProperties file
Run simulation.
### 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
-->
Here is the overPimpleDyMFoam solver with particles built in.
[overLaPimpleDyMFoam.gz](/uploads/82edbe2949d2ae99dde95caf114f3cdb/overLaPimpleDyMFoam.gz)
Below is the simpleRotor case with a basic kinematic cloud particles added.
[simpleRotorParticleErosion.gz](/uploads/226f3b1eb716ae770af6b43b6ad73c97/simpleRotorParticleErosion.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
As the particles approach the hole patch (the physical rotor), the particles pass through the rotor and don't register any impact with the erosion model.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The particles should rebound off the rotor and erosion should appear on the impacted cells.
### 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.
-->
This image shows a particle passing through the rotor without showing erosion. Erosion is shown on the outer walls to demonstrate that particle erosion is in place.
![simpleRotorErosion](/uploads/3c8f84e618ac7b537aa6ada503911021/simpleRotorErosion.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 : v1912
- 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/2945Particle Tracking for moving mesh can result in endless while iteration2024-01-30T09:48:52ZJan HartmannParticle Tracking for moving mesh can result in endless while iteration<!--
*** 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 am doing a lagrangian particle simulation together with a moving mesh method. After a certain amount of simulations steps one particle gets caught in the while loop within the function of trackToFace. I analyzed some output. The Tet Face of the particle stays constant and the step fraction does not change anymore within the loop. Therefore the while loop is never exited. The variable nBehind_ that shall prevent such a behaviour stays as zero so the condition within the loop never gets false. Nevertheless the particle tracking does not change anymore and the simulation freezes at this position. If i restart the simulation or add another condition that is a maximum iter counter i can resolve this problem. In the next time step the particle movement works properly again. The error occurs in version of2206 but since the functions are not changed it should also appear in the current version.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
This is a tough one since the dynamic mesh code uses some own written boundary condition for the patch that is moving. The error occurs after 10 hours of computation and a total of 1.8 million computed parcels. Since the error does not occur after restart from the previously saved time step it is difficult to reproduce it.
<!-- How one can reproduce the issue - this is very important -->
### Example case
Due to current development i can not simply upload the case and boundary condition.
<!--
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?
The simulation does not continue since it is trapped in this loop.
<!-- 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
- OpenFOAM version: v2206
- Operatin System: Ubuntu, CentOS
- Compiler: gcc
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
### Possible fixes
In my case an iter counter that exits the loop after a certain amount of iteration solve the problem.
<!--
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/2692Patch buckling using velocityLaplacian motionSolver on specified patches2023-01-31T20:21:30ZManuel ZeitlerPatch buckling using velocityLaplacian motionSolver on specified patches<!--
*** 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
If a rotating motion is enforced on only a few patches (not the whole object; used to "grow" the object during the simulation) using the motionSolver velocityLaplacian, some patches start to buckle in on themselves.
### Steps to reproduce
My test case can be found here: https://github.com/ZeitM/SurfaceBuckling
>There are also 2 png-files included, showing the problem
1. Clone the given repository
2. Execute using overInterDyMFoam
3. inspect the results in paraview (area of interest: the 2ircleSections defined as arc...)
### What is the current *bug* behaviour?
After a few timesteps the moving patches start to buckle in on themselves, resulting in a very jagged geometry. (Important: The problem is considered only if the patches buckle in on themselves, not if the mesh/geometry bends between two patches)
### What is the expected *correct* behavior?
It is expected that the patches don't buckle in on themselves and stay "straight"/stay as one flat plane.
### Environment information
OpenFOAM version : v2206https://develop.openfoam.com/Development/openfoam/-/issues/2191patchType does not survive operations2021-08-25T10:35:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compatchType does not survive operations### Functionality to add/problem to solve
Override a bc on a constraint patch type (e.g. cyclicAMI) using the `patchType` override. Now do any kind of operation. E.g. run laplacianFoam (calculates&writes fvc::grad). This will e.g. write...### Functionality to add/problem to solve
Override a bc on a constraint patch type (e.g. cyclicAMI) using the `patchType` override. Now do any kind of operation. E.g. run laplacianFoam (calculates&writes fvc::grad). This will e.g. write gradTx which will have again `type cyclicAMI`. We might want the default `calculated` instead (so preserve the `patchType` override)
@andy @Prashant @mark
### Proposal
Have additional keyword like `patchType`?