Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-12-09T22:37:29Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1367backport META-INFO2019-12-09T22:37:29ZMark OLESENbackport META-INFO- the META-INFO system is useful for packaging patch releases (eg, as tar files).
- a minimal _backport_ is accomplished by adding the directory and the -show-api/-show-patch hooks into foamEtcFile- the META-INFO system is useful for packaging patch releases (eg, as tar files).
- a minimal _backport_ is accomplished by adding the directory and the -show-api/-show-patch hooks into foamEtcFileMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/863Coordinate system issues: cylindricalCS / fixedProfileFvPatchField2020-06-19T14:43:50ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comCoordinate system issues: cylindricalCS / fixedProfileFvPatchField- cyclindricalCS cannot be run-time selected: missing TypeName and addToRunTimeSelectionTable.
- hard to specify
```
coordinateSystem
{
coordinateRotation
{
type axesRota...- cyclindricalCS cannot be run-time selected: missing TypeName and addToRunTimeSelectionTable.
- hard to specify
```
coordinateSystem
{
coordinateRotation
{
type axesRotation;
e3 (1 0 0);
e1 (0 1 0);
}
type cylindricalCS;
origin (0 0 0.01);
}
```
With this in place we could re-write various boundary conditions to use cylindrical coordinates. E.g. `fixedProfileFvPatchField`.
@matej
Remark: cylindrical coordinateRotation currently stores transformation tensors. This should be stored outside.
https://develop.openfoam.com/Development/openfoam/-/issues/1386Lamb vector2020-03-13T13:28:56ZAdminLamb vectorWhen trying to compute the Lamb vector function object as suggested in the guide with:
postProcess -func lambVector
I receive the following error:
Cannot find functionObject file lambVector
Moreover, the tutorial suggested in the gui...When trying to compute the Lamb vector function object as suggested in the guide with:
postProcess -func lambVector
I receive the following error:
Cannot find functionObject file lambVector
Moreover, the tutorial suggested in the guide to test the Lamb vector does not exist in the path:
$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/motorBike
\## Reattaching the author to the issue ticket: @Ricky\-11 ##Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/569locationInMesh specified in shmDict being ignored in favor of locationsInMesh2019-07-03T19:47:41ZAdminlocationInMesh specified in shmDict being ignored in favor of locationsInMeshI am having issues with snappy in 1706 - locationsInMesh is being used despite shmDict specifying locationInMesh.
We mesh automotive geometries, where we want a MRF cellZone for brake discs. These brake ducts have dozens of independent...I am having issues with snappy in 1706 - locationsInMesh is being used despite shmDict specifying locationInMesh.
We mesh automotive geometries, where we want a MRF cellZone for brake discs. These brake ducts have dozens of independent volume channels where a centroid can be outside the volume (total=100s per car), so specifying all locationsInMesh can't be automated - we use the original functionality of defining bounds to these channels via STL geometry. In all versions before 1706 this works fine.
However, in 1706, despite specifying locationInMesh and then providing the geometry for cellZones, locationsInMesh is what shows up in shm's log. Strangely, the faceZones are created, and are not empty. The MRF cellZones are also created, but no cells are assigned to them. I checked the extended code guide, where it shows both locationInMesh and locationsInMesh can be used, so I suspect this could be a bug?
**snappyHexMeshDict:**
> allowFreeStandingZoneFaces true;
locationInMesh (-1.5 -0.5 1.5);
internal_fluid_l_mrf_fr_wheel
{
level (8 8);
faceZone internal_l_mrf_fr_wheel;
faceType internal;
cellZone fluid_l_mrf_fr_wheel;
cellZoneInside inside;
}
**log from snappy** (anomolies to previous versions in boxes)
![snappyLog](/uploads/7efb9df21a47eaeab50e2c7e7e3446d2/snappyLog.png)
I've attached a small test case, just run the run_snappy.sh to reproduce (runs in minutes.) Log from when I run it locally is also attached.
[cellZoneProblem_testCase.zip](/uploads/9f16affbb2b99d49d8f1926f41885c11/cellZoneProblem_testCase.zip)[log.mesh.allMeshing](/uploads/efbf9d6753d975c35e08f9626878174d/log.mesh.allMeshing)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/1356pressure functionObject in v1906 does not calculate total pressure coefficien...2020-03-13T13:32:29ZAdminpressure functionObject in v1906 does not calculate total pressure coefficient (fix attached)In v1906, the pressure function object uses a new "mode" specification. The documentation is not up yet, but from the source code it looks like the options are: static, total, isentropic, staticCoeff, totalCoeff.
The block of code below...In v1906, the pressure function object uses a new "mode" specification. The documentation is not up yet, but from the source code it looks like the options are: static, total, isentropic, staticCoeff, totalCoeff.
The block of code below correctly handles the difference between static and total pressure, and when I calculate these, the values are correct.
However, when the mode is totalCoeff or staticCoeff, the output of both is the same: staticCoeff (i.e., the default in the switch below). I think the switch needs some kind of "startswith" logic.
To fix this, I have replaced this switch case with an if statement similar to the one used for the coeff logic and resultName logic. After compiling and running, I am getting proper values for totalCoeff. I've attached the modified file.
[pressure.C](/uploads/1d39079c9ef69f73369b474f4f1e9ed2/pressure.C)
```c
Foam::tmp<Foam::volScalarField> Foam::functionObjects::pressure::calcPressure
(
const volScalarField& p,
const tmp<volScalarField>& tp
) const
{
switch (mode_)
{
case TOTAL:
{
return
tp
+ dimensionedScalar("pRef", dimPressure, pRef_)
+ rhoScale(p, 0.5*magSqr(lookupObject<volVectorField>(UName_)));
}
case ISENTROPIC:
{
const basicThermo* thermoPtr =
p.mesh().lookupObjectPtr<basicThermo>(basicThermo::dictName);
if (!thermoPtr)
{
FatalErrorInFunction
<< "Isentropic pressure calculation requires a "
<< "thermodynamics package"
<< exit(FatalError);
}
const volScalarField gamma(thermoPtr->gamma());
const volScalarField Mb
(
mag(lookupObject<volVectorField>(UName_))
/sqrt(gamma*tp.ref()/thermoPtr->rho())
);
return tp()*(pow(1 + (gamma - 1)/2*sqr(Mb), gamma/(gamma - 1)));
}
default:
{
return
tp
+ dimensionedScalar("pRef", dimPressure, pRef_);
}
}
}
```
\## Reattaching the author to the issue ticket: @aerogt3 ##AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1267The 'function object' does not write out the results of 'volFieldValue' if 's...2019-07-03T19:32:25ZAdminThe 'function object' does not write out the results of 'volFieldValue' if 'solidificationMeltingSource' is used.<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
After calculation using solidificationMeltingSource, the time change of the liquid phase (eg. sMS:alpha1 field) fails to written out by function object utility.
### Steps to reproduce
> $ buoyantPimpleFoam
>
> (after the end)
>
> $ buoyantPimpleFoma -postProcess
### Example case
After expanding this attached file, execute 'Allrun' script file!
[solidificationMeltingSourceTest.tar.gz](/uploads/556b79b4ce57806740507da6e5ce49f6/solidificationMeltingSourceTest.tar.gz)
### 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
In case of the calculation simultaneously with solver
>volFieldValue meltingFranctions write:
>
> sum(PCM) of sMS1:alpha1 = 475.61726
>
>End
>
>(no problem)
---
When executed as post-processing
>volFieldValue meltingFranctions write:
>
> sum(PCM) of sMS1:alpha1 = 0
>
>
>End
### 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 :v1812
Operating system :ubuntu18.04
Compiler :gcc-7.3.0
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->https://develop.openfoam.com/Development/openfoam/-/issues/987tet decomposition puts all triangles into faceZone2020-01-08T14:39:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comtet decomposition puts all triangles into faceZonetetDecomposer uses the faceZone for all of the triangles of a cell instead of just the decomposition of the original face.tetDecomposer uses the faceZone for all of the triangles of a cell instead of just the decomposition of the original face.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1343Bug2020-03-13T13:32:51ZAdminBugI am trying to compile a new application on Ubuntu(new turbulence model), I get the following error:
In file included from /home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/x86_64-pc-linux-gnu/bits/c++c...I am trying to compile a new application on Ubuntu(new turbulence model), I get the following error:
In file included from /home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/x86_64-pc-linux-gnu/bits/c++config.h:507:0,
from /home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/utility:68,
from /home/rozie/OpenFOAM/OpenFOAM-v1812/src/OpenFOAM/lnInclude/autoPtr.H:51,
from ../turbulenceModels/lnInclude/turbulenceModel.H:39,
from incompressibleTurbulenceModel.H:38,
from incompressibleTurbulenceModel.C:26:
/home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/x86_64-pc-linux-gnu/bits/os_defines.h:39:22: fatal error: features.h: No such file or directory
#include <features.h>
^
compilation terminated.
\## Reattaching the author to the issue ticket: @Rozie123 ##https://develop.openfoam.com/Development/openfoam/-/issues/1354Metis decomposition is not working using OpenFOAM-v19062019-07-08T18:49:33ZAdminMetis decomposition is not working using OpenFOAM-v1906Metis decomposition is not working using OpenFOAM-v1906
Steps to reproduce:
* compile metis
```
cd $WM_THIRD_PARTY_DIR
wget http://glaros.dtc.umn.edu/gkhome/fetch/sw/metis/metis-5.1.0.tar.gz
tar -xzf metis-5.1.0.tar.gz
rm metis-5.1.0.t...Metis decomposition is not working using OpenFOAM-v1906
Steps to reproduce:
* compile metis
```
cd $WM_THIRD_PARTY_DIR
wget http://glaros.dtc.umn.edu/gkhome/fetch/sw/metis/metis-5.1.0.tar.gz
tar -xzf metis-5.1.0.tar.gz
rm metis-5.1.0.tar.gz
cd $WM_PROJECT_DIR
./Allwmake -j -l
```
* modify decomposeParDict in twoSimpleRotors tutorial (OpenFOAM-v1906/tutorials/multiphase/overInterDyMFoam/twoSimpleRotors)
```
method metis;
```
* output
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1906 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : v1906 OPENFOAM=1906
Arch : "LSB;label=32;scalar=64"
Exec : decomposePar -cellDist
Date : Jul 04 2019
Time : 09:16:22
Host : coastal2
PID : 118852
I/O : uncollated
Case : /home/u0109460/OpenFOAM/u0109460-v1906/run/twoSimpleRotors
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Overriding DebugSwitches according to controlDict
overset 0;
dynamicOversetFvMesh 0;
cellVolumeWeight 0;
Decomposing mesh region0
Create mesh
Calculating distribution of cells
Selecting decompositionMethod metis [3]
--> FOAM FATAL ERROR:
Attempted non-const reference to const object from a tmpNrc<N4Foam4ListIiEE>
From function T& Foam::tmpNrc<T>::ref() const [with T = Foam::List<int>]
in file /home/u0109460/OpenFOAM/OpenFOAM-v1906/src/OpenFOAM/lnInclude/tmpNrcI.H at line 234.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::metisDecomp::decomposeSerial(Foam::UList<int> const&, Foam::UList<int> const&, Foam::UList<double> const&, Foam::List<int>&) const at ??:?
#3 Foam::metisLikeDecomp::decomposeGeneral(Foam::UList<int> const&, Foam::UList<int> const&, Foam::UList<double> const&, Foam::List<int>&) const at ??:?
#4 Foam::metisLikeDecomp::decompose(Foam::polyMesh const&, Foam::Field<Foam::Vector<double> > const&, Foam::Field<double> const&) const at ??:?
#5 Foam::decompositionMethod::decompose(Foam::polyMesh const&, Foam::Field<Foam::Vector<double> > const&) const at ??:?
#6 Foam::decompositionMethod::decompose(Foam::polyMesh const&, Foam::Field<double> const&, Foam::List<bool> const&, Foam::PtrList<Foam::List<int> > const&, Foam::List<int> const&, Foam::List<Foam::Pair<int> > const&) const at ??:?
#7 Foam::decompositionMethod::decompose(Foam::polyMesh const&, Foam::Field<double> const&) const at ??:?
#8 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
#9 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
#10 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
#11 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#12 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
Aborted (core dumped)
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1137steady particle tracking is very slow2019-07-03T19:37:14ZAdminsteady particle tracking is very slowIn some cases, the steady particle tracking of OF-dev is very slow. It seems that it is related with the mesh. In a case with all-hex mesh, the problem is not serious. But in a case with mesh generated by snappyHexMesh, the steady partic...In some cases, the steady particle tracking of OF-dev is very slow. It seems that it is related with the mesh. In a case with all-hex mesh, the problem is not serious. But in a case with mesh generated by snappyHexMesh, the steady particle tracking of OF-dev is very slow, While the steady particle tracking of OF-2.3 is normal in this case.https://develop.openfoam.com/Development/openfoam/-/issues/1398Holes are detected in wrong places by the overset algorithm in ``twoSimpleRot...2020-03-13T13:18:30ZAdminHoles are detected in wrong places by the overset algorithm in ``twoSimpleRotors`` tutorial<!--
*** 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
The overset algorithm detects the wrong ``cellType``. Basically, it marks some cells as holes when the interpolated cells are near the wall.
### Steps to reproduce
Run the ``twoSimpleRotors`` tutorial for few time steps and visualize the ``cellType`` in paraview.
### 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
-->
Run the ``twoSimpleRotors`` there are no modifications needed to produce this issue.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Holes are detected in wrong places which leads to zero velocity.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It should be as shown in the [user guide](https://vimeo.com/223790883)
<figure class="video_container">
<iframe src="https://vimeo.com/223790883" frameborder="0" allowfullscreen="true"> </iframe>
</figure>
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
Here are a collection of six snapshots for ``cellType`` field and two for the velocity field;
* t1
![test1](/uploads/b9a856a0ec9c7ae2e9aa344dd65967af/test1.png)
* t2
![test2](/uploads/51b676d235e83d1b2408bbbf16554878/test2.png)
* t3
![test3](/uploads/5acea4afaac26fe6c6f84f95c13725cb/test3.png)
* t3, velocity field
![test3_U](/uploads/ef1e0494e59b8b4639e4c822bd4fc161/test3_U.png)
* t4
![test4](/uploads/f7e421478a1bfd85a0ed1179f5e9f105/test4.png)
* t5
![test5](/uploads/22ce12218f32cda2fd635eecab93d7bd/test5.png)
* t6
![test6](/uploads/556d2b871a61c616682bfb8bd6c477a8/test6.png)
* t6, velocity field
![test6_U](/uploads/10967ca1af7694e5edfff0f7b9bf7efa/test6_U.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 : v1906
- Operating system : ubuntu 18.04LTS WSL on Win10
- Hardware info :
- Compiler : gcc
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
I'm not sure but it seems that this issue didn't exist for the version you used to produce the video attached above.
## Reattaching the author to the issue ticket: @hikassem ##https://develop.openfoam.com/Development/openfoam/-/issues/1329attach/detach does not correctly set owner/neighbour2019-07-03T19:27:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comattach/detach does not correctly set owner/neighbour<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
(exchange platform 1010)
Issue: If statement does not check to see if face was modified in codeblock from lines 115 to 156 of attachInterface.C. This results in the attach instructions for the faces on the master patch being overwritten with old values for owner/neighbour/patchID.
The overall effect is that attachInterface.C:
deletes the faces from the slave patch as expected, but,
does not delete the faces from the master patch, and the cells across the faceZone are not attached. So the information in polymesh/<neighbour,boundary,owner> is incorrect
Adding a check to exclude faces that have been modified at line attachInterface.C:176 fixes this behaviour.
### Possible fixes
attachInterface.CMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/314mergeOrSplitBaffles cannot operate on selected set of patches2018-05-29T05:39:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commergeOrSplitBaffles cannot operate on selected set of patchesmergeOrSplitBaffles can only operate on all boundary faces.mergeOrSplitBaffles can only operate on all boundary faces.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1351Typo in the example2019-07-03T19:25:30ZAdminTypo in the exampleIn this link: https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-general-uniform-fixed-value.html
Under the **Usage** section, We can find the following:
> The uniformValue is a Foam::Function1 type, allowing the value to...In this link: https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-general-uniform-fixed-value.html
Under the **Usage** section, We can find the following:
> The uniformValue is a Foam::Function1 type, allowing the value to be prescribed as a function of time. For example, to ramp vector values from (0 0 0) to (10 0 0) over 5 seconds:The uniformValue is a Foam::Function1 type, allowing the value to be prescribed as a function of time. For example, to ramp vector values from (0 0 0) to (10 0 0) over 5 seconds:
> ```
> <patchName>
> {
> type uniformFixedValue;
> uniformValue table
> (
> (0 (0 0 0))
> (5 (0 0 0)) // Here, should be (10 0 0)
> );
> }
> ```
As you can see in the comment the velocity component should be `(10 0 0)` instead of `(0 0 0)`.https://develop.openfoam.com/Development/openfoam/-/issues/1101Stability issue in dynamicLagrangian model2019-12-12T08:21:02ZAdminStability issue in dynamicLagrangian modelHi,
There is a stability issue in the dynamicLagrangian model, which is caused by flm_/fmm_. Some cells may have 0 value in fmm_. If replacing flm_/fmm_ with flm_/(fmm_+fmm0_), the model will be stable, where fmm0_ is a VSMALL defined i...Hi,
There is a stability issue in the dynamicLagrangian model, which is caused by flm_/fmm_. Some cells may have 0 value in fmm_. If replacing flm_/fmm_ with flm_/(fmm_+fmm0_), the model will be stable, where fmm0_ is a VSMALL defined in the model.
Attached is a patch file for this model.[V1806-Fix-stability-issue-in-dynamicLagrangian-model.patch](/uploads/706afdd4f55d19ebd6ab62394d7c6e61/V1806-Fix-stability-issue-in-dynamicLagrangian-model.patch)
Thanks,
Ning Ren
\## Reattaching the author to the issue ticket: @renning ##Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1321overset incorrect addressing in parallel2020-01-08T14:34:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comoverset incorrect addressing 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
Overset crashes if there are cells which have all donor cells remote. Part local/remote donors seems to be ok.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Out-of-range index on PtrList/UListMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1163Compilation failed2019-07-03T19:35:56ZAdminCompilation failedCompilation failed while compiling celCellStencil : compiler can't find cellCellStencilTemplates.C file
```
g++ -std=c++11 -m64 -DOPENFOAM=1812 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon...Compilation failed while compiling celCellStencil : compiler can't find cellCellStencilTemplates.C file
```
g++ -std=c++11 -m64 -DOPENFOAM=1812 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -Wno-unknown-pragmas -O3 -DNoRepository -ftemplate-depth-100 -I/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/src/fileFormats/lnInclude -I/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/src/surfMesh/lnInclude -I/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/src/sampling/lnInclude -I/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/src/meshTools/lnInclude -I/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/src/dynamicMesh/lnInclude -I/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/src/finiteVolume/lnInclude -I/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/src/dynamicFvMesh/lnInclude -I/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/src/parallel/decompose/decompositionMethods/lnInclude -IlnInclude -I. -I/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/src/OpenFOAM/lnInclude -I/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/src/OSspecific/POSIX/lnInclude -fPIC -c oversetPolyPatch/oversetPolyPatch.C -o /home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/overset/oversetPolyPatch/oversetPolyPatch.o
In file included from cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.H:39:0,
from cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C:26:
lnInclude/cellCellStencil.H:229:13: fatal error: cellCellStencilTemplates.C: No such file or directory
# include "cellCellStencilTemplates.C"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
In file included from lnInclude/inverseDistanceCellCellStencil.H:45:0,
from cellCellStencil/leastSquares/leastSquaresCellCellStencil.H:43,
from cellCellStencil/leastSquares/leastSquaresCellCellStencil.C:26:
lnInclude/cellCellStencil.H:229:13: fatal error: cellCellStencilTemplates.C: No such file or directory
# include "cellCellStencilTemplates.C"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
In file included from cellCellStencil/inverseDistance/inverseDistanceCellCellStencil.H:45:0,
from cellCellStencil/inverseDistance/inverseDistanceCellCellStencil.C:26:
lnInclude/cellCellStencil.H:229:13: fatal error: cellCellStencilTemplates.C: No such file or directory
# include "cellCellStencilTemplates.C"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/wmake/rules/General/transform:34: recipe for target '/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.o' failed
make: *** [/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.o] Error 1
make: *** Waiting for unfinished jobs....
/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/wmake/rules/General/transform:34: recipe for target '/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/overset/cellCellStencil/inverseDistance/inverseDistanceCellCellStencil.o' failed
make: *** [/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/overset/cellCellStencil/inverseDistance/inverseDistanceCellCellStencil.o] Error 1
/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/wmake/rules/General/transform:34: recipe for target '/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/overset/cellCellStencil/leastSquares/leastSquaresCellCellStencil.o' failed
make: *** [/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/overset/cellCellStencil/leastSquares/leastSquaresCellCellStencil.o] Error 1
In file included from lnInclude/inverseDistanceCellCellStencil.H:45:0,
from cellCellStencil/trackingInverseDistance/trackingInverseDistanceCellCellStencil.H:38,
from cellCellStencil/trackingInverseDistance/trackingInverseDistanceCellCellStencil.C:26:
lnInclude/cellCellStencil.H:229:13: fatal error: cellCellStencilTemplates.C: No such file or directory
# include "cellCellStencilTemplates.C"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/wmake/rules/General/transform:34: recipe for target '/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/overset/cellCellStencil/trackingInverseDistance/trackingInverseDistanceCellCellStencil.o' failed
make: *** [/home/mqnguyen/Code/OpenFOAM/OpenFOAM-plus/build/linux64GccDPInt32Opt/src/overset/cellCellStencil/trackingInverseDistance/trackingInverseDistanceCellCellStencil.o] Error 1
In file included from lnInclude/cellCellStencilObject.H:36:0,
from dynamicOversetFvMesh/dynamicOversetFvMeshTemplates.C:28,
from dynamicOversetFvMesh/dynamicOversetFvMesh.H:335,
from dynamicOversetFvMesh/dynamicOversetFvMesh.C:26:
lnInclude/cellCellStencil.H:229:13: fatal error: cellCellStencilTemplates.C: No such file or directory
# include "cellCellStencilTemplates.C"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
```https://develop.openfoam.com/Development/openfoam/-/issues/1462Make blending wieghts in LUST user selectable2019-10-17T13:21:06ZAdminMake blending wieghts in LUST user selectable### The proposal
LUST is a scheme that linearly blends linear interpolation with a linear upwind scheme using a 0.25 weight for for the latter.
It is claimed that this
```c
optimises the balance between accuracy and stability on a range ...### The proposal
LUST is a scheme that linearly blends linear interpolation with a linear upwind scheme using a 0.25 weight for for the latter.
It is claimed that this
```c
optimises the balance between accuracy and stability on a range of LES cases with a range of mesh quality.
```
I don't necessarily disagree with this, but 0.25 upwinding is quite a lot in some situations, and insufficient in other. There seems to be no particular reason to not allow the user to choose the weight. I suggest that we do just that, with 0.75 remaining the default value when no user input is provided.
### Beneficiaries
Mainly folk doing LES on unsructured grids.
### Funding
I may be wrong, but implementing this should be pretty trivial and require minimal resources.
### Bonus
The paper in which LUST appears to be introduced, different weights are tested. The paper is written by H. Weller. **HILARY** Weller :).
Weller, H. (2012). Controlling the computational modes of the arbitrarily structured C grid. Monthly Weather Review, 140(10), 3220–3234. https://doi.org/10.1175/MWR-D-11-00221.1
This reference should probably be added to LUST.H unless someone is aware of prior art.
Kind regards,
Timofeyhttps://develop.openfoam.com/Development/openfoam/-/issues/1379Openfoam 1812 over Infiniband2019-08-31T20:47:38ZAdminOpenfoam 1812 over Infiniband<!--
*** 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
-->
Hello evryone,
### Summary
I am trying to run OpenFoam 1812 over Infiniband (Mellanox) with OpenMPI 4 but it crashes at launch, I wonder if it is a compatibility issue between openfoam and openmpi.
With a simple C code I can use openmpi over infiniband (I am not exchanging data with this code though)
### Steps to reproduce
I have an openFoam case and use the following command:
`foamJob -p -s snappyHexMesh`
I add the following to my bashrc:
`export OMPI_MCA_btl_openib_allow_ib=1`
`export OMPI_MCA_btl_openib_if_include="mlx5_1:1"`
### Environment information
OpenFOAM version : v1812
Operating system : ubuntu 18.04
Hardware info : infiniband Mellanox
Compiler : gcc
### Possible fixes
I am using OpenMPI 4, but Openfoam doesn't accept it so I add a link from `libmpi.so.40` to `libmpi.so.20` because Openfoam is looking for the v2, but it is using the v4 with the link, for a calculation only on one server it is working perfectly (v4 faster than v2)
I tried to switch back to v2 but if I install it I get:
`[maui:16468] PMIX ERROR: UNPACK-PAST-END in file ../../../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/mca/bfrops/v12/unpack.c at line 206`
### What is the current *bug* behaviour?
I get a segmentation fault from snappyHexMesh
```
cws@maui:~/Molokai/bench/run_32$ foamJob -p -s snappyHexMesh
Parallel processing using SYSTEMOPENMPI with 2 processors
Executing: /opt/openfoam1812/OpenFOAM-v1812/bin/mpirun -np 2 -hostfile hostfile -x FOAM_SETTINGS /opt/openfoam1812/OpenFOAM-v1812/bin/foamExec snappyHexMesh -parallel | tee log
[maui:22883] Warning: could not find environment variable "FOAM_SETTINGS"
--------------------------------------------------------------------------
WARNING: There is at least non-excluded one OpenFabrics device found,
but there are no active ports detected (or Open MPI was unable to use
them). This is most certainly not what you wanted. Check your
cables, subnet manager configuration, etc. The openib BTL will be
ignored for this job.
Local host: oahu
--------------------------------------------------------------------------
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1812 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : v1812 OPENFOAM=1812
Arch : "LSB;label=32;scalar=64"
Exec : snappyHexMesh -parallel
Date : Jul 18 2019
Time : 10:43:48
Host : maui
PID : 22891
I/O : uncollated
[maui:22891:0:22891] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
==== backtrace ====
0 /usr/lib/libucs.so.0(+0x1ec4c) [0x7fc7ab995c4c]
1 /usr/lib/libucs.so.0(+0x1eec4) [0x7fc7ab995ec4]
===================
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun noticed that process rank 0 with PID 0 on node maui exited on signal 11 (Segmentation fault).
--------------------------------------------------------------------------```