Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-07-06T10:54:54Zhttps://develop.openfoam.com/Development/openfoam/-/issues/356movingCone tutorial leaks memory in cuttingPlane2021-07-06T10:54:54ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commovingCone tutorial leaks memory in cuttingPlaneAttached output from
valgrind --leak-check=full --show-reachable=yes
[log.pimpleDyMFoam](/uploads/30fe839ab542c1f8866ec7867680490e/log.pimpleDyMFoam)Attached output from
valgrind --leak-check=full --show-reachable=yes
[log.pimpleDyMFoam](/uploads/30fe839ab542c1f8866ec7867680490e/log.pimpleDyMFoam)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1170moving mesh restart2020-01-08T14:29:23ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commoving mesh restartmesh flux field "meshPhi" does not get re-read if running in a region.mesh flux field "meshPhi" does not get re-read if running in a region.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/649movingWallVelocity allows non-zero input in case of static mesh2020-01-03T12:00:36ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commovingWallVelocity allows non-zero input in case of static meshIn case of non-moving the only value that makes sense is (0 0 0). Can we enforce this as per noSlip? Or do we re-interpret the value as a relative, additional motion in which case the moving() functionality should account for that.In case of non-moving the only value that makes sense is (0 0 0). Can we enforce this as per noSlip? Or do we re-interpret the value as a relative, additional motion in which case the moving() functionality should account for that.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/581mpi issue with new wave boundary implementation (previously ihfoam)2017-09-08T10:27:03ZAdminmpi issue with new wave boundary implementation (previously ihfoam)I noticed an issue with a case using the new wave boundary implementation in the interfoam solver v1706.
The simulation unexpectedly aborts before normal completion:
*mpirun noticed that process rank 6 with PID 0 on node nav08 exited on ...I noticed an issue with a case using the new wave boundary implementation in the interfoam solver v1706.
The simulation unexpectedly aborts before normal completion:
*mpirun noticed that process rank 6 with PID 0 on node nav08 exited on signal 8 (Floating point exception).*
The bug is probably related with MPI since running the same case in serial mode does not provoke this error.
[waves_mpi_problem.zip](/uploads/d5f07cb1830cf4effb2c37d1b8e49cc1/waves_mpi_problem.zip)https://develop.openfoam.com/Development/openfoam/-/issues/173mpirun bug in new OF1606+2016-07-04T12:34:45ZAdminmpirun bug in new OF1606+Hello,
I have a bug parallel running "even using Allrun in tutorials" any case.
the error goes as
opal_shmem_base_select failed
--> Returned value -1 instead of OPAL_SUCCESS
which mpirun gives
/opt/OpenFOAM/ThirdParty-v1606+/p...Hello,
I have a bug parallel running "even using Allrun in tutorials" any case.
the error goes as
opal_shmem_base_select failed
--> Returned value -1 instead of OPAL_SUCCESS
which mpirun gives
/opt/OpenFOAM/ThirdParty-v1606+/platforms/linux64Gcc/openmpi-1.10.2/bin/mpirun
ldd /opt/OpenFOAM/ThirdParty-v1606+/platforms/linux64Gcc/openmpi-1.10.2/bin/mpirun showes all dependencies are well
I have the same problem in several different machines.
Thanks https://develop.openfoam.com/Development/openfoam/-/issues/2459mpirunDebug2022-05-07T08:44:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commpirunDebug### Functionality to add/problem to solve
mpirunDebug passes through arguments but does not protect "### Functionality to add/problem to solve
mpirunDebug passes through arguments but does not protect "Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/933mpirun on less than decomposed number of processors does not give error message2020-01-03T14:21:29ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commpirun on less than decomposed number of processors does not give error messageE.g. decompose into 8 with a non-standard decomposeParDict but run checkMesh on 6 (as set by system/decomposeParDict). This bypasses the argList check on incorrect number of processors so now gives sigsegv from processorPolyPatch trying ...E.g. decompose into 8 with a non-standard decomposeParDict but run checkMesh on 6 (as set by system/decomposeParDict). This bypasses the argList check on incorrect number of processors so now gives sigsegv from processorPolyPatch trying to send to non-existing neighbouring processors.https://develop.openfoam.com/Development/openfoam/-/issues/3092MPI_Send MPI_ERR_COUNT: invalid count argument 140 million cells (bug)2024-01-29T18:57:45ZIlya ElizarovMPI_Send MPI_ERR_COUNT: invalid count argument 140 million cells (bug)### Summary
I have encountered a problem with MPI_Send routine while running a 140 million cells case on the cluster: Virgo cluster at GSI Helmholtz Centre for Heavy Ion Research https://hpc.gsi.de/virgo/
I'm using chtMultiRegionSimple...### Summary
I have encountered a problem with MPI_Send routine while running a 140 million cells case on the cluster: Virgo cluster at GSI Helmholtz Centre for Heavy Ion Research https://hpc.gsi.de/virgo/
I'm using chtMultiRegionSimpleFoam to solve a heat transfer problem for a multilayer PCB with vias in great detail. The solver goes through a few regions with no problem, but when it proceeds to a very big region with 141 211 296 cells, it crashes with the error below.
I have tried to increase number of subdomains, e.g. 1024, 2048, 4096 CPUs (all hierarchical method) and 1024 (with ptscotch), but the error persists. This makes me think, that the error is caused by the absolute number of cells in the region and independent of decomposition. A few more things were tried as a solution, but with no success: https://www.cfd-online.com/Forums/openfoam-solving/253681-mpi_send-mpi_err_count-invalid-count-argument.html
### Steps to reproduce
Basically, any solver with with comparable mesh size case should fail. Surely, to run such a case, a lot of computational resources are required that's why it's difficult to reproduce.
Feel free to contact me if you need more details on the Virgo cluster that I'm using. Meanwhile, I will ask OpenFOAM community if anybody could test it on a cluster with comparable size.
### Example case
My case can be found at https://sf.gsi.de/f/4db522c9b39b4125855f/?dl=1 (24,2 Mb)
_Requirements: 1024 CPUs (it's with multithreading), 4 Gb RAM per processor, Slurm workload manager, OpenFOAM installed with WM_LABEL_SIZE=64_
Simply run ./Allrun script
The case uses collated file format.
### What is the current _bug_ behaviour?
It seems that MPI_Send is called with a negative count argument. The count argument is a signed int https://www.open-mpi.org/doc/v4.1/man3/MPI_Send.3.php of 32 bit size, so it is likely overflowing (MPI_Send with a count \> INT_MAX).
### What is the expected _correct_ behavior?
Basically, the solver should proceed with the very big region if there's no hardware limitations like in this situation.
### Relevant logs and/or images
chtMultiRegionSimpleFoam fails with the following error message:
```plaintext
<...>
[lxbk1164:3797445] *** An error occurred in MPI_Send
[lxbk1164:3797445] *** reported by process [710282087,0]
[lxbk1164:3797445] *** on communicator MPI_COMM_WORLD
[lxbk1164:3797445] *** MPI_ERR_COUNT: invalid count argument
[lxbk1164:3797445] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
[lxbk1164:3797445] *** and potentially your MPI job)
slurmstepd: error: *** STEP 19265579.0 ON lxbk1164 CANCELLED AT 2024-01-19T18:02:26 ***
srun: Job step aborted: Waiting up to 32 seconds for job step to finish.
<...>
```
Full logs that were generated by the case can be downloaded at https://sf.gsi.de/f/66935ac60645422da948/?dl=1 log.\* files are ordinary logs that OpenFOAM generates, Slurm-\*.out are logs from the workload manager.
### Environment information
- OpenFOAM version : v2306
- Operating system : CentOS-based
- Hardware info : https://hpc.gsi.de/virgo/user-guide/overview/hardware.html
- OpenMPI : 3.1.6, 4.1.2 (from ThirdParty-v2306), 5.0.0 (tried with three of them)
- Slurm: 21.08.8-2
- Compiler : gcc-toolset-13, gcc 10.2.0 (tried with the two)
### Possible fixes
The PStream interface accepts a std::streamsize and implicitely casts it to the int argument on the mpi interfaces, performing a narrowing conversion https://develop.openfoam.com/Development/openfoam/-/blob/master/src/Pstream/mpi/UOPstreamWrite.C#L56
```plaintext
<source>:3:27: error: static assertion failed
3 | static_assert(sizeof(int) == sizeof(std::streamsize));
| ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:3:27: note: the comparison reduces to '(4 == 8)'
```
(from https://godbolt.org/)
OpenFOAM would have plenty of options to deal with this situation by e.g. issuing multiple MPI_Send or choose a larger MPI_Datatype.
P.S. It seems that there's a problem adding a bug label: /label ~bughttps://develop.openfoam.com/Development/openfoam/-/issues/1810MRF correctBoundaryVelocity not working with rotatingWallVelocity bc2022-04-26T16:10:01ZMortesinsMRF correctBoundaryVelocity not working with rotatingWallVelocity bc<!--
*** 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 `correctBoundaryVelocity` method of the MRF does not correct the boundary velocity of a patch that has a `rotatingWallVelocity` boundary condition, so it just ends up having the `rotatingWallVelocity` condition that does not set the velocity normal to the face. For example, if I have a rim with an MRF only around the spokes, I need the `rotatingWallVelocity` boundary condition for the rest of the rim, but even the spokes that are inside the MRF don't have velocity normal to the face the way the `correctBoundaryVelocity` method should set.
### What is the current *bug* behaviour?
The whole patch has the velocity set as `rotatingWallVelocity` would, disregarding the MRF.
### What is the expected *correct* behavior?
The `correctBoundaryVelocity` method of the MRF should correct the velocity for the faces inside the MRF, setting the rotating velocity even if it's normal to the face.v2206Kutalmış BerçinKutalmış Berçinhttps://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/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/2501MRF - non zero flux through walls in nonRotatingPatches2022-05-31T17:21:32ZnicolaMRF - non zero flux through walls in nonRotatingPatches<!--
*** 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
When including a patch in nonRotatingPatches, even if the patch is a wall, the flux through the patch is not 0. Indeed, printing phi from adjustPhi.C results in both an inflow and an outflow - which are equals and therefore cancel out, but in my opinion, should not be there. In a real-life problem, this might result in a conservation error in the case of a closed domain due to a small discrepancy between inflow and outflow.
### Steps to reproduce
print out flux through patches (e.g. replace lines 61 onwards of adjustPhi.C with
scalar massInStart = massIn;
scalar massOutStart = fixedMassOut;
forAll(phip, i)
{
if (phip[i] < 0.0)
{
massIn -= phip[i];
}
else
{
fixedMassOut += phip[i];
}
}
Info << "Mass in " << phip.patch().name() << endl;
Info << "equal to " << massIn- massInStart << endl;
Info << "Mass out " << phip.patch().name() << endl;
Info << "equal to " << fixedMassOut - massOutStart << endl;
and simpleFoam on the attached tutorial (modified from mixerVessel2DAMI)
[mixer2D.tar.gz](/uploads/669fe555e60f827e316d46b2408ff233/mixer2D.tar.gz)
### What is the expected *correct* behavior?
I would expect phi equal to 0 both inflow and outflow
### Environment information
OpenFOAM v2112
### Possible fixes
I tried to fix the issue by forcing flux to 0 in MRFZoneTemplates.C on the excludedFaces, but I don't believe this is correct.
<!--
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/2135MRFzoneTemplate.C issue2021-06-23T15:01:59ZAshutosh MauryaMRFzoneTemplate.C issueHi ,
I was compiling OpenFoam Adapter from https://precice.org/ . The compiler requires to include certain headers from openFoam. The compilation failed ,I reported it to their forum they said that is not issue with openFoam adapter. I a...Hi ,
I was compiling OpenFoam Adapter from https://precice.org/ . The compiler requires to include certain headers from openFoam. The compilation failed ,I reported it to their forum they said that is not issue with openFoam adapter. I am attaching wmake.log file for more info.
OpenFoam Version: 2012
OS: Ubuntu 20.04 on WSL
[wmake.log](/uploads/09b88701e47a56a5b6a76a8300529465/wmake.log)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2739multiLevel at the scotch level2023-05-09T13:04:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commultiLevel at the scotch level### Functionality to add/problem to solve
multiLevel decomposition can be used to minimise 'expensive' cuts. scotch can support this natively using SCOTCH_archTleaf.
### Target audience
multi-node runs
### Proposal
E.g. start from ...### Functionality to add/problem to solve
multiLevel decomposition can be used to minimise 'expensive' cuts. scotch can support this natively using SCOTCH_archTleaf.
### Target audience
multi-node runs
### Proposal
E.g. start from the extended multiLevel input:
```
numberOfSubdomains 1024;
method multiLevel;
multiLevelCoeffs
{
method scotch
domains (2 8); //< inferred as domains (64 2 8);
}
```
Just needs additional spec of the individual cut weights.
### What does success look like, and how can we measure that?
Would be nice to have stats about cuts*weights on the individual levels...
@mark @andyhttps://develop.openfoam.com/Development/openfoam/-/issues/620multiLevelCoeffs entry should not be optional2019-12-09T22:11:26ZMark OLESENmultiLevelCoeffs entry should not be optionalif the `multiLevelCoeffs` entry is missing, using `optionalSubDict()` results in it using the top-level dictionary, which will immediately fail (eg, trying to interpret `numberOfSubdomains` as a sub-dictionary entry).
Bug introduced by ...if the `multiLevelCoeffs` entry is missing, using `optionalSubDict()` results in it using the top-level dictionary, which will immediately fail (eg, trying to interpret `numberOfSubdomains` as a sub-dictionary entry).
Bug introduced by 9801c2578Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/619multilevel decomposition fails2019-12-09T22:11:26ZMark OLESENmultilevel decomposition fails@Mattijs@Mattijsv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/992Multiphase: transportProperties for e. g. yPlus, wallShearStress, ...2018-09-13T13:09:41ZAdminMultiphase: transportProperties for e. g. yPlus, wallShearStress, ...Dear Foamers,
currently it is not possible to postprocess multiphase solutions where the flow properties ("nu, rho") are not written directly in the file "transportProperties" but only for the phase like e.g.
water
{
transportModel ...Dear Foamers,
currently it is not possible to postprocess multiphase solutions where the flow properties ("nu, rho") are not written directly in the file "transportProperties" but only for the phase like e.g.
water
{
transportModel ...
nu 1e-6;
rho 1000;
}
So evaluating e.g. yPlus or wallShearStress is a bit hard because you need to copy each phase value to a 'general' value and so on. Would it possible to improve that? Cos the information is available for each phase...
Regardshttps://develop.openfoam.com/Development/openfoam/-/issues/404multiple intersections not found by shm2020-01-03T09:56:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commultiple intersections not found by shmThis can cause mesh leakage.
Problem 1: triSurfaceSearch::findLineAll does not increase starting point after finding hit. This should not be needed since any previous intersections are excluded through the shapeMask.
Problem 2: fast tria...This can cause mesh leakage.
Problem 1: triSurfaceSearch::findLineAll does not increase starting point after finding hit. This should not be needed since any previous intersections are excluded through the shapeMask.
Problem 2: fast triangle-bounding box calculation misses some intersections.https://develop.openfoam.com/Development/openfoam/-/issues/263Multiple paths pointing to the same main folder can lead to compilation problems2020-03-13T14:21:34ZAdminMultiple paths pointing to the same main folder can lead to compilation problemsEssentially the following is a brief summary of this bug report: http://bugs.openfoam.org/view.php?id=2204
1. Have two similar paths, but one of them is a symbolic link:
```
/home/ofuser/OpenFOAM/OpenFOAM-4.x (symbolic li...Essentially the following is a brief summary of this bug report: http://bugs.openfoam.org/view.php?id=2204
1. Have two similar paths, but one of them is a symbolic link:
```
/home/ofuser/OpenFOAM/OpenFOAM-4.x (symbolic link to OpenFOAM-dev)
/home/ofuser/OpenFOAM/OpenFOAM-dev
```
2. Source the environment for the `OpenFOAM-4.x` path.
3. Then run the build commands from within the `OpenFOAM-4.x` path.
4. **Result**: messy builds, where the first hit was in the folder `src/Pstream`, when building `mpi`.
The solution should be to use `pwd -P` in both `Allwmake` and `wmake` scripts, to enforce the correct paths to be used, after sorting through the symbolic link map.
The only problem with this solution that I can remember at the moment is mostly related to user confusion when inspecting the build output... nonetheless, I expect that there are some other weird corner cases, such as having the symbolic links switched around and the source paths enforced on the symbolic paths, resulting in a larger build stack confusion.
----
Tagging @mark, since he asked for it to be cross-referenced here as well ;)
\## Reattaching the author to the issue ticket: @wyldckat ##https://develop.openfoam.com/Development/openfoam/-/issues/2099multiple world coupling to support AMI2022-12-23T15:02:54ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commultiple world coupling to support AMI### Functionality to add/problem to solve
multiple world coupling to support AMI
Using -world only supports one-to-one patch mapping (nearestPatchFace). It would be nice to support AMI:
```
// What to sample:
sampleMod...### Functionality to add/problem to solve
multiple world coupling to support AMI
Using -world only supports one-to-one patch mapping (nearestPatchFace). It would be nice to support AMI:
```
// What to sample:
sampleMode nearestPatchFaceAMI;
```
### Target audience
Multi-world simulationsMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com