Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-09-07T08:42:52Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2416Wall on overset mesh causes p-U coupling issues2022-09-07T08:42:52ZJozsef NagyWall on overset mesh causes p-U coupling 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 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 want to inject liquid into a 2D gap.
![image](/uploads/874bb6ca76fd8c4db182fce6c1b876af/image.png)
I want to add a wall on an overset mesh, which is supposed to act as a blockage.
![image](/uploads/c25dd89c61c539c0e8307b7a78e417ed/image.png)
Due to the contraction of the thickness of the gap I would assume, that the velocity in the area of the overset mesh with the wall will be increased (due to continuity). However, this is not the case.
I found this issue: https://develop.openfoam.com/Development/openfoam/-/issues/2341
and assumed that this could be some overInterDyMFoam problem with mass conservation. I tested the same flow with overPimpleDyMFoam and the same happens.
### Steps to reproduce
I uploaded four case files in a zip file. All four can be run with the one master Allrun script in v2112 (also v2012) in 1-2 minutes on on core.
### Example case
[reproducingCases.zip](/uploads/94a362cd067221ac2860a1b089ba516b/reproducingCases.zip)
### What is the current *bug* behaviour?
Here you can see the velocity profile:
![image](/uploads/329c5e7aa1c8098b0b679a585e18f5a0/image.png)
First gap is the simulation without the overset mesh (no contraction of thickness) and overPimpleDyMFoam.
Second gap is the simulation with the overset mesh (small contraction of thickness) and overPimpleDyMFoam.
Third gap is the simulation without the overset mesh (no contraction of thickness) and overInterDyMFoam.
Fourth gap is the simulation with the overset mesh (small contraction of thickness) and overInterDyMFoam.
Without an overset mesh, the results look good and reasonable. The moment I merge an overset mesh to the background mesh, the velocity "dissipates" in the area of the overset mesh.
The pressure behaves also incorrectly
![image](/uploads/4c0dabbdbbee27f3082c1532d96f460b/image.png)
without the overset mesh the pressure drop is reasonable. With the overset mesh the pressure drop disappears in the area of the overset mesh.
### What is the expected *correct* behavior?
Increase of velocity in region of contraction.
### Relevant logs and/or images
See above.
### 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 (also v2012)
- Operating system : Ubuntu 18.04
- Hardware info : Intel CPU 6 cores (should not matter here)
- Compiler : GCC coming with OpenFOAM
### 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
-->
I am not sure. What i noticed is that I have to change the preconditioner between DILU and DIC depending whether I want to run the simulation with or without the overset mesh. In all cases the matrix solver is PBiCGStab though. Maybe this helps? I did try to fix this in the source code, but I am stuck. What I found is that the major impact is coming from pEqn.
In overPimpleDyMFoam the line:
U = cellMask*(HbyA - rAU*gradP);
In overInterDyMFoam the line:
U =
cellMask*
(
HbyA + rAU*fvc::reconstruct((phig - p_rghEqn.flux())/rAUf)
);
The multiplication with cellMask seems to introduce the errors. This might possibly be the source where the error comes out, possibly the cause is in some of the previous steps, where HbyA, rAU or phig are defined. This is where I am stuck.
### Final thoughts
Is this phenomenon
* my stupidity and ignorance (in this case I am sorry to waste you valuable time)
* a bug
* a feature
* something else
I am happy to support you with any help possibly, I know that you have a lot to do. Tell me, what I can test and I will execute the simulations and test.
Thank you!
Best regards,
JozsefSergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/2415solidFoam does not allow changing time steps2022-05-06T11:06:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsolidFoam does not allow changing time steps### Functionality to add/problem to solve
solidFoam does not support e.g. setTimeStep FO.
### Proposal
Define a 'Courant' number and include time-step changing. The problem is that `time.setDeltaT(..)` is not called so there is no ca...### Functionality to add/problem to solve
solidFoam does not support e.g. setTimeStep FO.
### Proposal
Define a 'Courant' number and include time-step changing. The problem is that `time.setDeltaT(..)` is not called so there is no call to `functionObjects_.adjustTimeStep()`.
### What does success look like, and how can we measure that?
Run with `setTimeStep` FOhttps://develop.openfoam.com/Development/openfoam/-/issues/2414report number of cells/faces capped by limitVelocity2022-04-25T11:49:45ZMark OLESENreport number of cells/faces capped by limitVelocitycf. EP1841
Also report relative (%) of cells/faces affected.cf. EP1841
Also report relative (%) of cells/faces affected.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2413Adjoint Smooth Sensitivities fails under WM_LABEL_SIZE=642024-01-11T18:58:45ZDiego PardoAdjoint Smooth Sensitivities fails under WM_LABEL_SIZE=64### Summary
Running the tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike
With OpenFOAM compiled with **label size 64** (instead of the default 32) leads to an MPI error.
The only modification ...### Summary
Running the tutorial: $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike
With OpenFOAM compiled with **label size 64** (instead of the default 32) leads to an MPI error.
The only modification to the tutorial is running in 2 processors rather than 20.
### Steps to reproduce
Using OpenFOAM compiled with label size 64 (`export WM_LABEL_SIZE=64`), run the following tutorial:
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/sensitivityMaps/motorBike
I used only a 2 processor hierarchical decomposition:
```
numberOfSubdomains 2;
method hierarchical;
coeffs
{
n (2 1 1);
}
```
### What is the current *bug* behaviour?
MPI Error. The job does not finish.
### What is the expected *correct* behavior?
Successful job with 64 label size
### Relevant logs and/or images
I have attached the full log file: [log.adjointOptimisationFoam](/uploads/f44e8d6d1a5a494482f28f41b4b4bf49/log.adjointOptimisationFoam)
### Environment information
- OpenFOAM version : v2112
- Operating system : centos 8
- Compiler : gcc 8.4.0
### Possible fixes
The issue is somehow related to the inter-processor communication happening in the processorFaPatch.C
By changing the sender call
```
void Foam::processorFaPatch::initGeometry()
{
if (Pstream::parRun())
{
OPstream toNeighbProc
(
Pstream::commsTypes::blocking,
neighbProcNo() // ,
// 3*(sizeof(label) + size()*sizeof(vector)) <- Use automatically computed message size
);
...
...
}
```
And changing the recipient call
```
void Foam::processorFaPatch::calcGeometry()
{
if (Pstream::parRun())
{
{
IPstream fromNeighbProc
(
Pstream::commsTypes::blocking,
neighbProcNo() //,
// 3*(sizeof(label) + size()*sizeof(vector)) <- Use automatically computed message size
);
...
...
}
```
Appears to fix the issue. However I think this is only hiding the issue.https://develop.openfoam.com/Development/openfoam/-/issues/2411MRF : divergent flow near interface when the rotating zone is unaligned2022-03-15T08:33:41ZHenrique GropelliMRF : divergent flow near interface when the rotating zone is unalignedHello!
When simulating a wind turbine with unaligned flow (turbine with tilt) I got a divergent flow near the interface of the non inertial zone and inertial zone.
![uy](/uploads/ef8a385359a1883f3f2776bece0d378d/uy.png)
I’m simulating in...Hello!
When simulating a wind turbine with unaligned flow (turbine with tilt) I got a divergent flow near the interface of the non inertial zone and inertial zone.
![uy](/uploads/ef8a385359a1883f3f2776bece0d378d/uy.png)
I’m simulating in a steady flow regime with MRF (multiple reference frame), when the turbine is aligned with the flow the flow is fully converged.
![tilt0yn](/uploads/cffe5439f6cea9432105bca5c544069b/tilt0yn.png)
I have set the patches excluding the blade patches as non rotating patches in MRFProperties.
I had tested in three different meshes with different refinements in the interface (57MM cells in “A” mesh, 62MM cells in “B” mesh, 97MM cells in “C” mesh) to better achieve an interface weight in AMI. But the three meshes diverged.
For a last attempt I simulated an unaligned flow in an aligned mesh, changing the velocity components, but diverged as before.
The mesh is a cylinder 15 diameters long and 5 diameters high. Inside the mesh is a mesh of 2 diameters long and 2 diameters high, which is the rotating zone.
I don't have a small example, this link contains the results and the mesh: https://drive.google.com/file/d/1RqzYC68v9YfBUidHXLHVgNwdBBvTcORP/view?usp=sharing
Openfoam v2006, gcc v8.3, centos.https://develop.openfoam.com/Development/openfoam/-/issues/2410snappyHexMesh : Layer addition on cyclic patch2022-03-14T14:39:26ZPrashant SonakarsnappyHexMesh : Layer addition on cyclic patchWhen adding layers on faces normal to cyclic patch, newly introduced patches doesn't seem to find correct 'BC' to handle cyclic.
Could this be handled?
[cavity.tgz](/uploads/152df3aad4a035177171bc2cf55eee51/cavity.tgz)
@MattijsWhen adding layers on faces normal to cyclic patch, newly introduced patches doesn't seem to find correct 'BC' to handle cyclic.
Could this be handled?
[cavity.tgz](/uploads/152df3aad4a035177171bc2cf55eee51/cavity.tgz)
@Mattijshttps://develop.openfoam.com/Development/openfoam/-/issues/2409atmBuoyancyTurbSource not working for RNGkEpsilon2023-12-18T08:37:25ZPetros AmpatzidisatmBuoyancyTurbSource not working for RNGkEpsilonTried to run the **atmForestStability** verification case with the RNGkEpsilon model. I got the following error:
`--> FOAM FATAL ERROR: (openfoam-2112) failed lookup of RNGkEpsilon:GbyNu (objectRegistry region0) available objects of typ...Tried to run the **atmForestStability** verification case with the RNGkEpsilon model. I got the following error:
`--> FOAM FATAL ERROR: (openfoam-2112) failed lookup of RNGkEpsilon:GbyNu (objectRegistry region0) available objects of type volScalarField::Internal: 20 (rhok ...)`
I think this is because **atmBuoyancyTurbSource** needs access to **GbyNu**.
In _kEpsilon.C_ line 248 `this->type() + ":GbyNu",` is missing from the respective _RNGkEpsilon.C_ file.
When this line is inserted in _RNGkEpsilon.C_ it seems to work.
I guess the same applies to the realizableKE.
Many thanksKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2407label nBufferLayers in dynamicRefineFvMesh produce no diffence2022-03-24T11:11:38ZAlberto ceschinlabel nBufferLayers in dynamicRefineFvMesh produce no diffence<!--
*** 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
There is no working option to increase buffer layers between refinement levels.
### Steps to reproduce
In tutorial multiphase/interFoam/RAS/motorBike , that is using dynamicRefineFvMesh, increasing label nBufferLayers from 1 to 2 or more does not bring any difference.
### 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
-->
With
`nBufferLayers 3;`
![Screenshot_from_2022-03-11_15-18-09](/uploads/300931c9ad400cafc513eca3e430af2b/Screenshot_from_2022-03-11_15-18-09.png)
### 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
- Operating system : Ubuntu 18https://develop.openfoam.com/Development/openfoam/-/issues/2406$:dict.entry in fvOptions-file2022-03-15T09:32:07ZJürgen Abraham$:dict.entry in fvOptions-fileI am using a caseSetupDict to store parameters for boundary conditions etc.
Now i wanted to extend this to my fvOptions files but noticed, that it is not working.
[fvOptions](/uploads/7a01947a3fb9115ff8934d6dfae58170/fvOptions)
[caseSet...I am using a caseSetupDict to store parameters for boundary conditions etc.
Now i wanted to extend this to my fvOptions files but noticed, that it is not working.
[fvOptions](/uploads/7a01947a3fb9115ff8934d6dfae58170/fvOptions)
[caseSetupDict](/uploads/c35542b3f2a89d17aa2d6f401029c742/caseSetupDict)https://develop.openfoam.com/Development/openfoam/-/issues/2405distributedTriSurfaceMesh used for refinement shell not consistent flipped2022-06-28T10:58:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdistributedTriSurfaceMesh used for refinement shell not consistent flipped<!--
*** 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 -->
In snappyHexMesh a distributedTriSurfaceMesh can be used as a closed refinement shell. This can lead to problems if it decides to orient the geometry and that decision is not the same on all processors.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Original geometry is too big. But have an STL shell surfaces and change its type from 'triSurfaceMesh' to 'distributedTriSurfaceMesh'. Change the decomposition method to a nonsense one (only 'hierarchical' really makes sense for meshing).
Depending on the case some of the processors (if they have zero faces of it) might decide not to orient it whereas others might. This can cause an inconsistent orientation.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
Error inside snappyHexMesh at startup (on some processors only) when it is orienting the shell surfaces.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :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
-->
Take consistent decision (flip/not-flip) on all processors, not just looking at own processor.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2404ENH: snappyHexMesh multi-pass layer addition2022-12-23T14:58:04ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: snappyHexMesh multi-pass layer addition### Functionality to add/problem to solve
Add layers in snappyHexMesh one-by-one.
### Target audience
Multi-layer generation on smooth surfaces
### Proposal
Calculate the wanted amount of layers and distribution of thickness. Add l...### Functionality to add/problem to solve
Add layers in snappyHexMesh one-by-one.
### Target audience
Multi-layer generation on smooth surfaces
### Proposal
Calculate the wanted amount of layers and distribution of thickness. Add layers one-by-one (still growing out from the bulk)
### What does success look like, and how can we measure that?
Optionally add layers one-by-one. Compare to adding layers in one go (the default).Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2403ENH: automatic leak closure2022-12-23T14:58:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: automatic leak closure### Functionality to add/problem to solve
snappyHexMesh has provision for specifying external, i.e. non-meshed locations. If any part of the resulting mesh connects an inside location to an outside one the meshing stops. It would be nic...### Functionality to add/problem to solve
snappyHexMesh has provision for specifying external, i.e. non-meshed locations. If any part of the resulting mesh connects an inside location to an outside one the meshing stops. It would be nice to automatically close 'small' gaps and continue instead.
### Proposal
A topological hole detection algorithm might be good enough. These walk on the initial mesh and attempt to close any 'leaks' in it. Another approach would be to actually 'correct' the input geometry but that would be much more problematic.
### What does success look like, and how can we measure that?
Initially just create a castellated, closed mesh. See how it behaves during snapping and layer generation.
### Links / references
"A 3D-Hole Closing Algorithm", Zouina Aktouf et alMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2401'faceToCell' duplicated 'etc/caseDicts/annotated/topoSetSourcesDict'2022-03-13T21:58:46ZBruno Santos'faceToCell' duplicated 'etc/caseDicts/annotated/topoSetSourcesDict'In the file `etc/caseDicts/annotated/topoSetSourcesDict`, within `faceSet_doc`:
```
//- Select based on cellSet
{
source cellToFace;
source faceToCell;
sets (c0 c1);
// or
set c0; ...In the file `etc/caseDicts/annotated/topoSetSourcesDict`, within `faceSet_doc`:
```
//- Select based on cellSet
{
source cellToFace;
source faceToCell;
sets (c0 c1);
// or
set c0; // Name of cellSet
option all; // All faces of cells
//option both; // Only faces with owner+neighbour in cellSet
}
```
The line with `faceToCell` should not be here.https://develop.openfoam.com/Development/openfoam/-/issues/2400kOmegaSST model with wrong omegaWallFunction2022-04-15T12:49:36ZSh NokOmegaSST model with wrong omegaWallFunctionThis reference, [https://turbmodels.larc.nasa.gov/sst.html](url), states that the boundary condition recommended in the original "Standard" Menter SST Two-Equation Model (SST) reference for omega at wall, is ![omega_wall_boundary_conditi...This reference, [https://turbmodels.larc.nasa.gov/sst.html](url), states that the boundary condition recommended in the original "Standard" Menter SST Two-Equation Model (SST) reference for omega at wall, is ![omega_wall_boundary_condition](/uploads/f3a558083b3f09dd640b0fe96051099a/omega_wall_boundary_condition.png) , which is 10 times higher than what is implemented in the omegaWallFunction boundary condition and used in tutorials. Below is the screenshot of part of the link provided, which mentions recommended
omega boundary condition.
![Boundary_Conditions](/uploads/2db5839def26e0247776a7564ea150b4/Boundary_Conditions.png)
It can be solved by setting beta1, 10 times lower than the default value; As is showed below.
![beta1_correction](/uploads/55ab5625a21a3e4c6f1df1e89ffa1337/beta1_correction.png)https://develop.openfoam.com/Development/openfoam/-/issues/2399Construct faMesh without data fails2022-03-16T18:05:29ZMark OLESENConstruct faMesh without data failsInteresting one while trying to apply the seeming simple idea (@Tobermory #2374) of enabling finite-area conversion by default.
The current try/catch approach seemed to work, but it is only slightly fault tolerant. It actually fails mis...Interesting one while trying to apply the seeming simple idea (@Tobermory #2374) of enabling finite-area conversion by default.
The current try/catch approach seemed to work, but it is only slightly fault tolerant. It actually fails miserably when there is no finiteArea. With the try/catch (currently incorrect, should also handle FatalIOError) it will block forever. Discarding the try/catch block reveals at least the first problem.
Construction of the faSchemes, faSolution uses an IOdictionary. Since these are global files, they are only read on the master. If missing, the read fails on the master. In the normal case, this signals a FatalError or FatalIOError and exit. The exit in this case is actually a Pstream exit, which shuts down the other processes and everything stop. However, with the try/catch block, the master throws an exception. The non-master processes are still waiting for input and everything blocks!Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2398chtMultiRegionSimpleFoam - of2112 does not catch analitical results where of2...2022-11-02T09:08:59ZMatteo QuirinochtMultiRegionSimpleFoam - of2112 does not catch analitical results where of2106 does<!--
*** 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 same test case if it is run with of2106 the analytical solution is obtained, if it is run with of2112 the analytical solution is not catched.
### Steps to reproduce
The case is shared in [this](https://github.com/matteoquirino/of2112-cht-possibleBug) repo. The test case is taken from [this](https://arc.aiaa.org/doi/10.2514/1.T6165) article. Just run "Allrun-serial" to launch the simulation. Try to run the simulation loading of2106 environment and then using of2112 environment. The solution given by of2016 is correct the one computed using of2112 is wrong by some degrees in temperature.
### Example case
The test case is taken from [this](https://arc.aiaa.org/doi/10.2514/1.T6165) article.
![Schermata_da_2022-03-08_09-48-15](/uploads/8f97013b290987e70dcf147faa7e6e0c/Schermata_da_2022-03-08_09-48-15.png)
h is the convective coefficient on the far right of the system, it is so low as it must represent vacuum. Lc and kc are set to 1e-6 m and 1e-4 W/m/K.
The case is very simple and fast.
### What is the current *bug* behaviour?
Analitical solution not catched by of2112 but catched by of2106. The one computed by of2112 is 330 K and 335 K whilst the correct one is 327 K 338 K.
### What is the expected *correct* behavior?
To catch the analytical solution.
### Relevant logs and/or images
Please see section above.
### 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 | v2106
- Operating system : ubuntu
- Hardware info :
- Compiler : precompiled versions of v2112 and v2106
### Possible fixesSergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/2397setConstraintTypes not working for FA fields2022-03-16T18:01:24ZMark OLESENsetConstraintTypes not working for FA fieldsmentioned in EP1825 - the grouping functionality of polyPatches is missing from finiteArea
Failure looks like this:
```
Reading pa
[3]
[3]
[3] --> FOAM FATAL IO ERROR: (openfoam-2106)
[3] Cannot find patchField entry for procBoundary3...mentioned in EP1825 - the grouping functionality of polyPatches is missing from finiteArea
Failure looks like this:
```
Reading pa
[3]
[3]
[3] --> FOAM FATAL IO ERROR: (openfoam-2106)
[3] Cannot find patchField entry for procBoundary3to0
[3]
[3] file: xxx/obliqueAirJet/main/processor3/0/ws_vibrationShell.boundaryField at line 11 to 19.
[3]
[3] From void Foam::GeometricField<Type, PatchField, GeoMesh>::Boundary::readField(const Foam::DimensionedField<TypeR, GeoMesh>&, const Foam::dictionary&) [with Type = double; PatchField = Foam::faPatchField; GeoMesh = Foam::areaMesh]
[3] in file .../src/OpenFOAM/lnInclude/GeometricBoundaryField.C at line 172.
[3]
FOAM parallel run exiting
[3]
Abort(1) on node 3 (rank 3 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 1) - process 3
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2396Handle manifold cell connections for conversion2022-03-31T04:50:50ZMark OLESENHandle manifold cell connections for conversionReported in EP1653 by @Chiara
As @andy and @Mattijs noted and provided the basic "repair", the problem arises from how additional faces are added into the mesh for AMI. Neither VTK nor Ensight can assemble polyhedral where the faces are...Reported in EP1653 by @Chiara
As @andy and @Mattijs noted and provided the basic "repair", the problem arises from how additional faces are added into the mesh for AMI. Neither VTK nor Ensight can assemble polyhedral where the faces are essentially duplicates of other ones.
The first course of action is filtering the mesh cells (for VTK and Ensight) to have unique connectivity.
However, even still exhibits problems with volPointInterpolation.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2395dynamic mesh (un)refinement: compatible with mesh motion2022-12-23T14:58:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdynamic mesh (un)refinement: compatible with mesh motion### Functionality to add/problem to solve
Add mesh-motion to dynamic mesh refinement/unrefinement
### Target audience
Moving mesh cases where dynamic mesh refinement/unrefinement limits the amount of mesh. E.g. interFoam cases.
### ...### Functionality to add/problem to solve
Add mesh-motion to dynamic mesh refinement/unrefinement
### Target audience
Moving mesh cases where dynamic mesh refinement/unrefinement limits the amount of mesh. E.g. interFoam cases.
### Proposal
Splice motion logic into dynamic mesh refinement/unrefinement
### What does success look like, and how can we measure that?
Have moving mesh case with e.g. interFoamMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2394Simulation With cyclicACMI Scale factors crash with mesh motion2022-12-23T14:59:31ZAmod KhardekarSimulation With cyclicACMI Scale factors crash with mesh motionOpenFOAM Version : 2012
OS : Ubuntu 20.04
GCC : gcc v6.3
Test case has been attached herewith to reproduce the error.
There are total 4 domains
1. Long rectangular volume with mesh motion
2. 1st Cube interfac...OpenFOAM Version : 2012
OS : Ubuntu 20.04
GCC : gcc v6.3
Test case has been attached herewith to reproduce the error.
There are total 4 domains
1. Long rectangular volume with mesh motion
2. 1st Cube interfacing with Domain 1
3. 2nd Cube interfacing Domain 2 and 4
4. 3rd Cube interfacing with Domain 3 and with outlet BC
cyclicACMI interfaces are used between Domain 1-2, 2-3 and 3-4.
Scale factors are used for cyclicACMI interface between 3-4.
Even for small change in scalefactor from 1 leads to divergence.
It has been tested with ideal gas, tabulatedEOS, SSTkW, KE models, small timesteps etc.
(TabulatedEOS from https://github.com/Yuusha0/tabulatedThermophysicalProperties)
Pressure goes outside of the bounds. If dynamicmeshDict is removed from constant folder case runs well.
I suspect there is some bug in scale factor module introduced in the v2012. I wanted to ask if this observation is expected as I dont know complete limitations of this new capability and if not is there any quick fix to this issue ?
[TestCase.zip](/uploads/07acdd5a07fe45c6dd48402a0ab5e77e/TestCase.zip)
Thanks
Amod KhardekarMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com