Development issueshttps://develop.openfoam.com/groups/Development/-/issues2018-03-06T10:49:12Zhttps://develop.openfoam.com/Development/openfoam/-/issues/748mapToSurface template substitution problem2018-03-06T10:49:12ZAdminmapToSurface template substitution problemThe finiteArea mapToSurface function won't accept boundaryField() input complaining of 'template argument deduction/substitution failed'.
`Us.internalField() = vsm.mapToSurface(U.boundaryField());`
`no matching function for call to ‘Fo...The finiteArea mapToSurface function won't accept boundaryField() input complaining of 'template argument deduction/substitution failed'.
`Us.internalField() = vsm.mapToSurface(U.boundaryField());`
`no matching function for call to ‘Foam::volSurfaceMapping::mapToSurface(const Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary&)’`
`note: candidate: template<class Type> Foam::tmp<Foam::Field<Type> > Foam::volSurfaceMapping::mapToSurface(const typename Foam::GeometricField<Type, Foam::fvPatchField, Foam::volMesh>::Boundary&) const
tmp<Field<Type>> mapToSurface`https://develop.openfoam.com/Development/openfoam/-/issues/563markup for pstream token types is fragile2017-08-10T12:57:02ZMark OLESENmarkup for pstream token types is fragileThis seems to be the root of the issue I encountered while adding in dictionary macros. The additional `MACRO` enumeration value (placed immediately after `WORD`) means that the indices of the subsequent `tokenType` enumerations increase...This seems to be the root of the issue I encountered while adding in dictionary macros. The additional `MACRO` enumeration value (placed immediately after `WORD`) means that the indices of the subsequent `tokenType` enumerations increase by one. This made `DOUBLE_SCALAR` receive a value of 9.
In `UOPstream::write(double)` this enumeration value is written as a character, which unfortunately corresponds to Tab and thus gets swallowed as a whitespace character. After this, the receiving end hasn't much chance.
I think that we should be invoking `writeToBuffer(char)` directly instead of using things like `write(char(token::DOUBLE_SCALAR))` - should be more reliable.
@Mattijsv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1653MarshakRadiation bc not mapped correctly2020-04-08T05:54:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMarshakRadiation bc not mapped correctly<!--
*** 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 -->
MarshakRadiation bc not mapped correctly. You can see this e.g. in redistributePar of a case with radiation and marshakRadiation bcs.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any case with marshakRadiation bcs:
```
mpirun redistributePar -parallel -decompose
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1747mask handling in ensight surface reader2020-06-25T10:08:18ZMark OLESENmask handling in ensight surface readerNoted by @Prashant in testing, seems to fail if the geometry name _does not_ contain any `*` chars.Noted by @Prashant in testing, seems to fail if the geometry name _does not_ contain any `*` chars.v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/428mass conservation problem in interCondensingEvaporatingFoam2017-04-18T13:40:34ZAdminmass conservation problem in interCondensingEvaporatingFoamDear OF Developers,
I am working with interCondensingEvaporatingFoam solver. I have encountered a possibly very important problem.
I am calculating flow with a phase change in-between heated plates. Domain has one inlet, one outlet, and...Dear OF Developers,
I am working with interCondensingEvaporatingFoam solver. I have encountered a possibly very important problem.
I am calculating flow with a phase change in-between heated plates. Domain has one inlet, one outlet, and a body limited by two heated plates.
At the inlet the liquid enters the domain, is heated, partially evaporates and leaves the domain via outlet.
The problem is that the mass is not conserved. There is approximately 6x larger mass flow of the liquid/vapor mixture at the outlet that at the inlet.
Please see the attached picture, which shows some filed values and integrated 'u_x*rho' over the inlet and outlet patch (u_x in normal to the inlet/outlet, so it gives mass flow).
![mass_conservation_problem](/uploads/392619e49f0b4f2972c607e84143be8f/mass_conservation_problem.png)
upper row of the figure shows the data for the inlet; the value "U_x_times_rho_inlet" in the table on the right corresponds to inlet mass flow
lower row of the figure shows the data for the outlet; the value "U_x_times_rho_outlet" in the table on the right corresponds to outlet mass flow
Regards
Jimhttps://develop.openfoam.com/Development/openfoam/-/issues/3066masterUncollatedFileOperation compilation error on 23122024-01-20T15:12:18ZMatej FormanmasterUncollatedFileOperation compilation error on 2312### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int3...### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int32IO.o
make: *** [/Volumes/ofdisk/OpenFOAM-v2312/build/darwin64ClangDPInt32Opt/src/OpenFOAM/global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.o] Error 1
make: *** Waiting for unfinished jobs....
Done logging to 'log.darwin64ClangDPInt32Opt'
``
my prefs.sh:
`
export projectDir="/Volumes/OFdisk/OpenFOAM-v2312"
export FOAM_CONFIG_ETC=etc-darwin
export WM_COMPILER_TYPE=system
export WM_COMPILER=Clang
export WM_PRECISION_OPTION=DP
export WM_LABEL_SIZE=32
export WM_COMPILE_OPTION=Opt
export WM_MPLIB=SYSTEMOPENMPI
export SCOTCH_VERSION=scotch-system
export fftw_version=fftw-system
export boost_version=boost-system
export cgal_version=cgal-system
export SCOTCH_ARCH_PATH=/usr/local/Cellar/scotch/7.0.4 ## 6.1.1 # run brew info scotch
export FFTW_ARCH_PATH=/usr/local/Cellar/fftw/3.3.10_1
export MPI_ARCH_PATH=/usr/local/Cellar/open-mpi/4.1.5
export BOOST_ARCH_PATH=/usr/local/Cellar/boost/1.82.0_1
export CGAL_ARCH_PATH=/usr/local/Cellar/cgal/5.6
export LDFLAGS="-L/usr/local/opt/readline/lib"
export CPPFLAGS="-I/usr/local/opt/readline/include"
export CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include"
export FOAM_EXTRA_CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include -DBOOST_MATH_DISABLE_FLOAT128"
export VTK_DIR="/usr/local/Cellar/vtk/9.2.5_1" # for runTimePostprocessing FO
export CMAKE_INCLUDE_PATH="/usr/local/Cellar/flex/2.6.4_2/include"
export CMAKE_LIBRARY_PATH="/usr/local/Cellar/flex/2.6.4_2/lib"
`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2368masterUncollated with #include inside decomposeParDict hangs2022-02-24T16:31:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commasterUncollated with #include inside decomposeParDict hangs<!--
*** 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 -->
#include a file in the decomposeParDict. Now any parallel run will hang when run with -fileHandler masterUncollated.
See https://exchange.openfoam.com/node/1828
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any case. See above.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Hangs. Stuck in some gatherList when parsing the dictionary (on the master).
### 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
-->
decomposeParDict is special - it gets read during startup to read any roots and the number of processors. At this point the dictionary reading is not yet 'set up' so it should disable any parallel communication. The #include statement in the decomposeParDict triggers parallel communication.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/200maxDeltaxyz changes missed in turbulence model upgrade2019-12-09T22:04:10ZAdminmaxDeltaxyz changes missed in turbulence model upgradeThe maxDeltaxyz LES delta behaviour was updated in version 2.3.x to correct excessive lengths being calculated at changes in mesh refinement, e.g. the 2:1 levels generated by snappyHexMesh. These changes were not included when moving to...The maxDeltaxyz LES delta behaviour was updated in version 2.3.x to correct excessive lengths being calculated at changes in mesh refinement, e.g. the 2:1 levels generated by snappyHexMesh. These changes were not included when moving to the templated turbulence structureVersion v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1171maxDeltaxyzCubeRootLESDelta doubly registers 'hmax'2021-12-09T20:12:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commaxDeltaxyzCubeRootLESDelta doubly registers 'hmax'maxDeltaxyzCubeRootLESDelta constructs three LESdelta. Each of them uses the same name (and tries to register it).
Run any case with debug flag
```
regIOobject 2;
```maxDeltaxyzCubeRootLESDelta constructs three LESdelta. Each of them uses the same name (and tries to register it).
Run any case with debug flag
```
regIOobject 2;
```v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2699Max droplet volume calculation misses a factor of \pi2023-03-22T17:02:47ZKonstantinos MissiosMax droplet volume calculation misses a factor of \piIn the regionSizeDistribution function object
[Here](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/functionObjects/field/regionSizeDistribution/regionSizeDistribution.C#L100),the calculation of the max droplet diam...In the regionSizeDistribution function object
[Here](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/functionObjects/field/regionSizeDistribution/regionSizeDistribution.C#L100),the calculation of the max droplet diameter misses a factor of \pi.
Instead of
`maxDropletVol = 1.0/6.0*pow3(maxDiam_);`
it should be something like
`maxDropletVol = 1.0/6.0*mathematical::pi*pow3(maxDiam_);`Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2577maxIter with PPCR,PPCG not working in parallel2022-09-07T14:33:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commaxIter with PPCR,PPCG not working in parallel<!--
*** 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 -->
Sometimes using coarsest level inside GAMG with PPCR or PPCG in combination with maxIter gives a crash. Issue seems to be the combination of
- maxIter
- parallel running
- PPCR,PPCG (i.e. any linear solver using non-blocking reductions)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Set up pressure solver to use PPCR or PPCG. Set maxIter to a very low level, e.g. 1. Run parallel.
### 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?
Crashes with `stack-smashing' error on some machines.
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : any version with PPCR,PPCG
### 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
-->
Make sure to clean up outstanding non-blocking request before exiting the solver loop inside PPCR,PPCG. This happens for 'normal' exits (convergence reached) but not for `maxIter` exits.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1266May need independent MPI initialize/finalize2019-04-11T14:39:59ZMark OLESENMay need independent MPI initialize/finalizeAs discussed with @Mattijs, but also of interest for @sbna
When Pstream initializes MPI, it checks for a previous initialization of MPI and skips if not required. It then also skips attaching transfer buffers. On finalize, it does simil...As discussed with @Mattijs, but also of interest for @sbna
When Pstream initializes MPI, it checks for a previous initialization of MPI and skips if not required. It then also skips attaching transfer buffers. On finalize, it does similar checks.
This means that MPI initialization outside of OpenFOAM will result in the buffers not being setup.
Exiting OpenFOAM will finalize MPI, even if OpenFOAM was not the one who initialized it.
Need the following:
- if an external app initialized, still initialize our buffers
- only finalize if OpenFOAM was also the one initializing, but always clean up our buffers if we created then.
Open question: when MPI was initialized elsewhere, are there any potential conflict when calling freePstreamCommunicator?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/53MD2014: feature request: placeholder2016-05-06T11:56:35ZPrashant SonakarMD2014: feature request: placeholderPlaceholder for feature requested on exchange platform: ID 90
Definition by sampledSurface for fluxSummary
@MattijsPlaceholder for feature requested on exchange platform: ID 90
Definition by sampledSurface for fluxSummary
@MattijsAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/509meanMomentumEnergyAndNMols.H bug?2017-06-29T20:38:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commeanMomentumEnergyAndNMols.H bug?src/lagrangian/molecularDynamics/molecule/mdTools/meanMomentumEnergyAndNMols.H:85
const vector& molOmega(inv(molMoI) & mol().pi());src/lagrangian/molecularDynamics/molecule/mdTools/meanMomentumEnergyAndNMols.H:85
const vector& molOmega(inv(molMoI) & mol().pi());Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/677Medium loop- failures - 21.12.20172018-06-12T04:01:04ZPrashant SonakarMedium loop- failures - 21.12.2017Cases in :
/home/alex2/prashant/OpenFOAM/OpenFOAM-plus.develop/tutorials/
- compressible/sonicFoam/RAS/nacaAirfoil - solver failed
- multiphase/reactingTwoPhaseEulerFoam/laminar/steamInjection - solver failed
- multiphase/compressibleInt...Cases in :
/home/alex2/prashant/OpenFOAM/OpenFOAM-plus.develop/tutorials/
- compressible/sonicFoam/RAS/nacaAirfoil - solver failed
- multiphase/reactingTwoPhaseEulerFoam/laminar/steamInjection - solver failed
- multiphase/compressibleInterDyMFoam/laminar/sphereDrop -solver failed
- multiphase/interFoam/laminar/vofToLagrangian/eulerianInjection -solver failed
@andy @Mattijs @Sergio @markhttps://develop.openfoam.com/Development/openfoam/-/issues/867Medium Test - 12.06.20182019-12-09T22:18:11ZPrashant SonakarMedium Test - 12.06.2018All cases could be accessed at: /home/alex4/prashant/SUPPORT/ESI/MEDIUM_TEST/tutorials_1806
- [x] DNS/dnsFoam/boxTurb16 - solver crash
- [x] IO/fileHandler/machineA/fileHandler - re-verify if we need `cp -r` while copying constant, line ...All cases could be accessed at: /home/alex4/prashant/SUPPORT/ESI/MEDIUM_TEST/tutorials_1806
- [x] DNS/dnsFoam/boxTurb16 - solver crash
- [x] IO/fileHandler/machineA/fileHandler - re-verify if we need `cp -r` while copying constant, line 36; 90 of Allrun
- [x] combustion/PDRFoam/flamePropagationWithObstacles - solver crash
- [x] mesh/foamyHexMesh/mixerVessel - solver crash
- [x] compressible/rhoSimpleFoam/gasMixing/injectorPipe - solver crash
- [x] compressible/sonicFoam/RAS/nacaAirfoil - solver crash
- [x] incompressible/pimpleFoam/LES/vortexShed - surface noise failed 'expected word error'
- [x] multiphase/compressibleInterFoam/laminar/climbingRod - solver failure
- [x] multiphase/driftFluxFoam/RAS/dahl - solver failure
- [x] multiphase/reactingTwoPhaseEulerFoam/RAS/LBend - solver failure
- [x] multiphase/compressibleInterFoam/laminar/depthCharge2D - solver failure
- [x] multiphase/interFoam/RAS/DTCHullMoving - solver failure
- [ ] ~~multiphase/interFoam/RAS/DTCHullWave - decomposePar failure 'missing entry value'~~ REMOVED
- [x] multiphase/interFoam/RAS/motorBike - rename solver in controlDict_nextWrite
- [x] multiphase/interFoam/laminar/vofToLagrangian/lagrangian* - both cases replace combustionModel type noCombustion to none
@andy @Mattijs @Sergio @markv1806https://develop.openfoam.com/Development/openfoam/-/issues/1082Medium Test Loop : v18122020-01-06T06:11:19ZPrashant SonakarMedium Test Loop : v1812As of 19 Nov
- [ ] combustion/reactingFoam/RAS/SandiaD_LTS - Solver failure
- [x] combustion/fireFoam/LES/compartmentFire - Please fix decomposition for panel and main domain
- [ ] mesh/foamyHexMesh/mixerVessel - Solver failure
- [ ] mu...As of 19 Nov
- [ ] combustion/reactingFoam/RAS/SandiaD_LTS - Solver failure
- [x] combustion/fireFoam/LES/compartmentFire - Please fix decomposition for panel and main domain
- [ ] mesh/foamyHexMesh/mixerVessel - Solver failure
- [ ] multiphase/overInterDyMFoam/boatAndPropeller - Solver failure
@Developmentv1812https://develop.openfoam.com/Development/openfoam/-/issues/1264Memory leak2020-06-19T20:59:31ZAdminMemory leaksuspecting a memory leak in openfoam-dev when compiled on a cluster using gcc 4.9.3 and openmpi 1.8.6
```
==39345== LEAK SUMMARY:
==39345== definitely lost: 0 bytes in 0 blocks
==39345== indirectly lost: 0 bytes in 0 blocks
==39345...suspecting a memory leak in openfoam-dev when compiled on a cluster using gcc 4.9.3 and openmpi 1.8.6
```
==39345== LEAK SUMMARY:
==39345== definitely lost: 0 bytes in 0 blocks
==39345== indirectly lost: 0 bytes in 0 blocks
==39345== possibly lost: 538 bytes in 12 blocks
==39345== still reachable: 2,056 bytes in 3 blocks
==39345== suppressed: 0 bytes in 0 blocks
==39345== Reachable blocks (those to which a pointer was found) are not shown.
==39345== To see them, rerun with: --leak-check=full --show-reachable=yes
==39345==
==39345== For counts of detected and suppressed errors, rerun with: -v
==39345== ERROR SUMMARY: 12 errors from 12 contexts (suppressed: 8 from 6)
```
\## Reattaching the author to the issue ticket: @mmahmed ##https://develop.openfoam.com/Development/openfoam/-/issues/2511memory leak from forces FO2022-06-23T10:32:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commemory leak from forces FO<!--
*** 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 -->
Run mixerVesselAMI2D-topologyChange under valgrind (with 'endTime writeNow') produces memory error from forces functionObject.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
See above
### 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
-->
See above
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : 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 : v2204
- Operating system :
- 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
-->
[processor0.log](/uploads/06d4839288fc5b4b143f0d4e92b70dc8/processor0.log)
@kutiAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/650mergeMeshes does not issue warning when it merges two grids having patches wi...2018-11-29T23:04:07ZKutalmış BerçinmergeMeshes does not issue warning when it merges two grids having patches with the same name**Problem description**
Say, the user has two different grids which contains the following patches with these names:
*Grid 1:*
7( inlet outlet left right top bottom sameNamePatch)
*Grid 2:*
2( obstacle sameNamePatch)
The below comm...**Problem description**
Say, the user has two different grids which contains the following patches with these names:
*Grid 1:*
7( inlet outlet left right top bottom sameNamePatch)
*Grid 2:*
2( obstacle sameNamePatch)
The below command (OpenFOAM v1706) is then executed.
> mergeMeshes Grid1Path Grid2Path -overwrite
No warning messages were issued. Now, *merged grid* containing:
8( inlet outlet left right top bottom obstacle sameNamePatch)
Despite topologically different patches, *sameNamePatch* patches from the both grids were combined only based on their names. At times, this might be useful. Yet, IMHO, it might also be error-prone leaving the user unwarned about what has happened.