OpenFOAM-plus issueshttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues2019-12-02T09:43:57Zhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1514solid body motion solver does not work with rigid body solver2019-12-02T09:43:57ZAlisolid body motion solver does not work with rigid body solverHi,
I am trying to use solid body motion as a mesh motion solver for rigid body motion. Although it lists the solid body motion as a valid motion solver, it fails to cast solver type and crash at the beginning. I have attached dynamicMe...Hi,
I am trying to use solid body motion as a mesh motion solver for rigid body motion. Although it lists the solid body motion as a valid motion solver, it fails to cast solver type and crash at the beginning. I have attached dynamicMeshDict file which can be placed in floatingBody overset tutorial to reproduce the error. The error line
--> FOAM FATAL ERROR:
Attempt to cast type solidBody to type displacementMotionSolver
Regards,
Ali
[6DoF.dat](/uploads/b4482b95045d89f392cbb664abc39412/6DoF.dat)
[dynamicMeshDict](/uploads/090b4e4130601b0d00883af3c85c20dc/dynamicMeshDict)https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1513applyBoundaryLayer : fails when cell is disconnected2019-11-27T13:00:05ZPrashant SonakarapplyBoundaryLayer : fails when cell is disconnected<!--
*** 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
For disconnected cells wallDistance can have -1e15 (i.e. -GREAT) value, which can cause issue with ::pow
cross ref : EP#1158
<!-- Summarize the bug encountered concisely -->
### What is the current *bug* behaviour?
Fails with error (discriminator 1)
<!-- What actually happens -->
### Possible fixes
Warn user for non-visited cells. And protection in ::pow function?
<!--
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
-->
@Mattijshttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1512Porting OpenFOAM to Windows2019-12-02T06:26:05Zs1291Porting OpenFOAM to WindowsHello,
Yesterday I have opened an [issue about OpenFOAM filenames in Windows](https://github.com/blueCFD/Core/issues/136) in BlueCFD project. Bruno, told me to open an issue here as well. This might be a potential solution to the probl...Hello,
Yesterday I have opened an [issue about OpenFOAM filenames in Windows](https://github.com/blueCFD/Core/issues/136) in BlueCFD project. Bruno, told me to open an issue here as well. This might be a potential solution to the problem of file naming in Windows (case insensitive).
In summary:
* Windows 10 now offers an optional case-sensitive file system, just like Linux and other UNIX-like operating systems. But this could be enabled on per-directory basis.
* Newer C++ compilers that support C++17, have `__has_include` feature for conditional including.https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1511ensightReadFile ignores string limits2019-12-02T12:36:35ZMark OLESENensightReadFile ignores string limitsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1510support specified time for trasformPoints2019-11-25T18:34:03ZPrashant Sonakarsupport specified time for trasformPoints### Functionality to add/problem to solve
transformPoints reads time from points instance. But it might be nice to operate on given time.
### Proposal
As discussed with @mark Use given time or default to constant### Functionality to add/problem to solve
transformPoints reads time from points instance. But it might be nice to operate on given time.
### Proposal
As discussed with @mark Use given time or default to constantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1508isoSurfaceTopo not passing through ACMI2019-11-21T09:47:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comisoSurfaceTopo not passing through ACMIRun oscillatingInletACMI2D tutorial with
```
isoSurfaceTopo
{
type surfaces;
libs ("libsampling.so");
enabled true;
writeControl timeStep;
writeInterval 1;
interpolationScheme cellPoint;
surfaceFo...Run oscillatingInletACMI2D tutorial with
```
isoSurfaceTopo
{
type surfaces;
libs ("libsampling.so");
enabled true;
writeControl timeStep;
writeInterval 1;
interpolationScheme cellPoint;
surfaceFormat vtk;
// Fields to be sampled
fields
(
p
U
);
surfaces
(
isoSurface1
{
type isoSurfaceTopo;
patches ( ".*");
isoField p;
isoValue 0.1;
interpolate true;
triangulate false;
regularise cell; //diagcell;
}
);
}
```
and the isosurface does not pass through the acmi. This is due to the duplicate faces (ACMI+wall) on either side of the ACMI.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1505Failed start of simulation due to non-zero "defaultFaces" in a case converted...2019-11-20T03:19:47ZPin LyuFailed start of simulation due to non-zero "defaultFaces" in a case converted by gmshToFoam<!--
*** 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 -->
(I think this issue can be closed. I gave my analysis in the first comment.)
I intended to generate 2D mesh by `Gmsh` (latest version v4.4.1), and then convert it to `OpenFOAM` (latest version v1906) polyMesh by `gmshToFoam`.
But I found the utility "gmshToFoam" is unreliable. Two example cases are provided here. They have nearly the same configuration but produce different states of mesh conversion. After minor adjustment of the spatial coordinate of a control point in the geometry definition ("bridgeFlow.geo"), "gmshToFoam" might find some faces that belongs to none of any defined physical groups and label them as "`defaultFaces`" in "constant/polyMesh/boundary". By visualizing the patches, the internal wall, which is expected to be in the same patch, is found to be divided into two patches by `gmshToFoam`.
The non-zero "nFaces" of "defaultFaces" in "boundary" will make the following commands unable to proceed.
For example, errors will be met in the operation "`decomposePar`".
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. Have Gmsh v4.4.1 and OpenFOAM v1906 in the environment.
2. Extract zipped files in the example cases.
3. `cd example_failed` or `cd example_successful`
4. `gmsh -3 bridgeFlow.geo`
5. `gmshToFoam bridgeFlow.msh`
6. Open `constant/polyMesh/boundary` and check whether it has non-zero "defaultFaces".
### 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
-->
I've uploaded two cases here. The only differences in their setup are Line 14 and Line 17 in `bridgeFlow.geo` in these two cases.
The "failed" one will produce non-zero "defaultFaces".
[example_failed.zip](/uploads/d69ae6d7064727938b0a894a74630d55/example_failed.zip)
[example_successful.zip](/uploads/fd7a016b47cf46d6785c815681c5fb3c/example_successful.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The utility `gmshToFoam` is unreliable. Sometime it works well (as in 'example_successful'), but after a minor modification of geometry setup of mesh (as in 'example_failed'),
it will generate non-zero `defaultFaces` in `constant/polyMesh/boundary` and make the workflow unable to proceed.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No `defaultFaces` appears in `constant/polyMesh/boundary`, as in 'example_successful'.
### 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.
-->
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / 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 : gmshToFoam bridgeFlow.msh
Date : Nov 20 2019
Time : 01:08:37
PID : 5532
I/O : uncollated
Case : /mnt/c/python/Chamorro_thermal/DRL_girder_optimization/example_failed
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
Starting to read mesh format at line 2
Read format version 4.1 ascii 0
Starting to read physical names at line 5
Physical names:7
Surface 1 outlet
Surface 2 top
Surface 3 inlet
Surface 4 bottom
Surface 5 backAndFront
Surface 6 bridgeWall
Volume 7 bridgeFlow
Starting to read points at line 174
Vertices to be read: 14844
Vertices read: 14844
Starting to read cells at line 29989
Cells to be read:43860
Mapping region 5 to Foam patch 0
Mapping region 6 to Foam patch 1
Mapping region 1 to Foam patch 2
Mapping region 2 to Foam patch 3
Mapping region 3 to Foam patch 4
Mapping region 4 to Foam patch 5
Mapping region 7 to Foam cellZone 0
Cells:
total: 14513
hex : 0
prism: 14513
pyr : 0
tet : 0
CellZones:
Zone Size
0 14513
Skipping tag $Periodic at line 73888
Patch 0 gets name backAndFront
Patch 1 gets name bridgeWall
Patch 2 gets name outlet
Patch 3 gets name top
Patch 4 gets name inlet
Patch 5 gets name bottom
--> FOAM Warning :
From function Foam::polyMesh::polyMesh(const Foam::IOobject&, Foam::pointField&&, const cellShapeList&, const faceListList&, const wordList&, const wordList&, const Foam::word&, const Foam::word&, const wordList&, bool)
in file meshes/polyMesh/polyMeshFromShapeMesh.C at line 592
Found 29357 undefined faces in mesh; adding to default patch.
Finding faces of patch 0
Finding faces of patch 1
Finding faces of patch 2
Finding faces of patch 3
Finding faces of patch 4
Finding faces of patch 5
FaceZones:
Zone Size
1 24
Writing zone 0 to cellZone bridgeFlow and cellSet
Writing zone 1 to faceZone bridgeWall and faceSet
End
```
For the failed case, the block in `boundary` says:
```
defaultFaces
{
type patch;
nFaces 34;
startFace 50927;
}
```
I visualized the location of the 'defaultFaces' by Tecplot.
The 2D mesh layout looks like:
![location_of_defaultFaces](/uploads/9134ccea3d7116d1a838c4c7f39c49db/location_of_defaultFaces.png)
The internal wall is dyed with colors for each patch.
![location_of_defaultFaces_2](/uploads/9e66b9e5cbbbab84249a6444b6a2f69f/location_of_defaultFaces_2.png)
The whole internal wall should be in the same patch `bridgeWall`.
However, after the mesh conversion by `gmshToFoam`, the internal wall is divided into two patches: `bridgeWall` in the blue color and `defaultFaces` in the green color, as shown in the picture above.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1906
Operating system : ubuntu
Compiler : pre-compiled binary for WSL of Win10
-->
- OpenFOAM version : v1906
- Operating system : ubuntu
- Compiler : pre-compiled binary for WSL of Win10
- Gmsh version : 4.4.1
https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1497Error decomposing with redistributePar and codedFixedValue BC2019-11-21T13:48:52ZCarlos Peña-MonferrerError decomposing with redistributePar and codedFixedValue 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 ...<!--
*** 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
Decomposing a case with `redistributePar` fails when `codedFixedValue` boundary condition is used.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
A minimal example with `pitzDaily` has been attached. The error appears when executing the following commands:
```
blockMesh
mpirun -np 16 redistributePar -parallel -decompose
```
<!-- How one can reproduce the issue - this is very important -->
### Example case
`pitzDaily` tutorial. `0/U` file modified for reproducing the error.
[pitzDailyTest.zip](/uploads/a516c651c6e06aef2e2a8027c9156628/pitzDailyTest.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?
Trying to decompose with `redistributePar` any case that includes `codedFixedValue` fails.
Decomposition works with `decomposePar`, or `fixedValue` and `redistributePar` but fails including a basic `codedFixedValue` BC.
<!-- What actually happens -->
### Relevant logs and/or images
```
[10] --> FOAM FATAL IO ERROR:
[10] Attempt to put back onto bad stream
[10]
[10] file: IOstream at line 0
[11]
[11] file: IOstream.
[9]
[9] From function [5]
FOAM parallel run exiting
```
<!--
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 : 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 : centos
- Compiler : gcc
<!--
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-plus/-/issues/1492fixup for PDRsetFields2019-11-19T11:21:20ZMark OLESENfixup for PDRsetFieldsPlaceholder for topics, changes etc.
@pratap @puttockPlaceholder for topics, changes etc.
@pratap @puttockMark OLESENMark OLESENhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1491SnappyHexMesh: Treat feature edge/cell between different PID for layer addtition2019-11-12T12:09:21ZPrashant SonakarSnappyHexMesh: Treat feature edge/cell between different PID for layer addtition### Functionality to add/problem to solve
Using mutli-region feature edge we can capture in-plane edges. Improve the snapping to help generate layers at this section.
### Links / references
EP#1084### Functionality to add/problem to solve
Using mutli-region feature edge we can capture in-plane edges. Improve the snapping to help generate layers at this section.
### Links / references
EP#1084Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1490postProcess with cyclicACMI patches2019-11-13T10:00:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compostProcess with cyclicACMI patches<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** 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 the oscillatingACMI2D tutorial with some e.g. isoSurface functionObject as
``postProcess```
and it will crash since the pointMesh gets cleared out but the pointField (from volPointInterpolation) does not.
### 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
-->
In polyMesh::readUpdate make sure to update pointMesh (or MeshObject) in general instead of deleting it.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1489LiquidEvaporationBoil spalding number defined on molar basis2019-11-18T07:51:40ZAlessandro D'AusilioLiquidEvaporationBoil spalding number defined on molar basisIn OpenFOAM-2.4.0 at **src/lagrangian/intermediate/submodels/Reacting/PhaseChangeModel/LiquidEvaporationBoil/LiquidEvaporationBoil.C**
line 318:
dMassPC[lid] += pi d Sh Dab rhos log(1.0 + Xr) dt;
where d is the droplet diameter, Sh is...In OpenFOAM-2.4.0 at **src/lagrangian/intermediate/submodels/Reacting/PhaseChangeModel/LiquidEvaporationBoil/LiquidEvaporationBoil.C**
line 318:
dMassPC[lid] += pi d Sh Dab rhos log(1.0 + Xr) dt;
where d is the droplet diameter, Sh is the Sherwood number (Sh(Re,Sc)), Dab the vapor diffusivity assuming properties at the film, rhos the density at the film and Xr (line313):
// molar ratio
const scalar Xr = (Xs - Xc)/max(SMALL, 1.0 - Xs);
The units of dMassPC are in kg. However, the dimensionless group Xr is expressed in terms of molar fractions.
In literature, Xr is better known as the Spalding mass number (BM) where the ratio is expressed in terms of mass fractions rather than molar fractions [1,2]
I wonder if there is an implementation reason, which I do not see immediately, or if this is an implementation issue that should be fixed in order to correctly predict the evaporation rate.
Thank you in advance for your support and reply.
Alessandro
[1] Sergei S. Sazhin, Advanced models of fuel droplet heating and evaporation, Progress in Energy and Combustion Science, Volume 32, Issue 2, 2006.
[2] Patrick Jenny, Dirk Roekaerts, Nijso Beishuizen, Modeling of turbulent dilute spray combustion, Progress in Energy and Combustion Science, Volume 38, Issue 6, 2012.https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1487I can't compile my own solver: illegal instruction constexpr v19062019-11-11T07:24:51ZRodrigo André Zelada ManciniI can't compile my own solver: illegal instruction constexpr v1906Hi everyone, I'm trying to compile my own solver in Windows 10, Ubuntu 18.04 but i can't.
The error is " illegal instruction constexpr..."
I've seeing this post: https://develop.openfoam.com/Development/OpenFOAM-plus/issues/938
and when...Hi everyone, I'm trying to compile my own solver in Windows 10, Ubuntu 18.04 but i can't.
The error is " illegal instruction constexpr..."
I've seeing this post: https://develop.openfoam.com/Development/OpenFOAM-plus/issues/938
and when I modify the etc/bashrc file:
# [WM_COMPILER_TYPE] - Compiler location:
# = system | ThirdParty
export WM_COMPILER_TYPE=system
# [WM_COMPILER] - Compiler:
# = Gcc | Gcc4[8-9] | Gcc5[1-5] | Gcc6[1-5] | Gcc7[1-4] | Gcc8[12] |
# Clang | Clang3[7-9] | Clang[4-6]0 | Icc | Cray | Arm | Pgi
export WM_COMPILER=Gcc
(or export WM_COMPILER=Gcc74)
the ubuntu shell says "No completion added for /opt/OpenFOAM/OpenFOAM-v1906/platforms/linux64Gcc73DPInt32Opt/bin
... incorrect platform, or not yet compiled?"
What should I do to fix this?
Thanks,https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1486surfaceFeatureExtract trims all features on a brick when minElem > 12019-11-11T04:36:51ZJustin GraupmansurfaceFeatureExtract trims all features on a brick when minElem > 1### Summary
Not sure if this is a bug report of a feature request, but here it goes.
When I extract features on a brick defined by an stl file, the edge features (12 of them) only get extracted if trimFeatures minElem is not used or set...### Summary
Not sure if this is a bug report of a feature request, but here it goes.
When I extract features on a brick defined by an stl file, the edge features (12 of them) only get extracted if trimFeatures minElem is not used or set to something not higher than 1. Since all the features are "connected" on the brick, I would have expected features to not be trimmed until at least a value of 13 on minElem.
This probably gets into how you are determining the number of elements in feature strings. In other software I've used, they generally separate things into "connected" feature groups and then apply element filtering to each of those. For example, a brick would have 12 connected feature edges and be in one group, so a minElem of 2 shouldn't trim any of the features, but in surfaceFeatureExtract, it does.
### Steps to reproduce
Run surfaceFeatureExtract on the attached brick model. No features will be extracted because minElem is set to 2. If you set it to 1, the features get extracted.
### Example case
[brick.zip](/uploads/be63b675856f5a189e7cd6035e0294e6/brick.zip)
### What is the current *bug* behaviour?
No features will be extracted because minElem is set to something above 1.
### What is the expected *correct* behavior?
I would expect all features to be extracted until minElem reaches 13, since there are 12 connected feature edges on a brick.
### Environment information
OpenFOAM version : v1906
Operating system : RHEL / Windows
Compiler : gcc / MinGW
### Possible fixes
I looked in surfaceFeatures.C to try and glean how feature strings were being determined, but I was unable to decipher the strategy being used. My guess is that there is a difference in strategy, if that's the case, then this is a feature request.https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1483Singularity OpenFOAM containers2019-11-13T08:48:34ZTimofey MukhaSingularity OpenFOAM containersA common issue with OpenFOAM is that due to a significant amount of forks and releases within each fork, it is rather difficult for HPC administrators to provide all the sorts of flavours of OpenFOAM out there. Typically, only a few vers...A common issue with OpenFOAM is that due to a significant amount of forks and releases within each fork, it is rather difficult for HPC administrators to provide all the sorts of flavours of OpenFOAM out there. Typically, only a few versions are installed, which can hinder adoption of new versions of the code.
A way to solve this problem would be adopting container technology, so that OpenFOAM does not actually have to be installed. OpenFOAM is already provided as Docker images, but unfortunately, Docker is not suitable for running wide MPI jobs.
A different type of container, developed to be suitable for HPC environments is Singularity.
Fortunately, one can build a Singularity container directly from Docker containers, and even pull from Dockerhub.
Thus, building Singularity containers of OpenFOAM is very easy.
On my request, the use of OpenFOAM Singularity containers has been investigated at the National Supercomputer Centre
at Linköping University, which hosts a large cluster called Tetralith.
What follows is copied from a mail I have received from the system administrator
> I have been able to get Openfoam to run within a singularity container, including MPI.
> I have documented how to do it on our webpage:
> https://www.nsc.liu.se/software/installed/tetralith/OpenFOAM/
> There is a section: How to run OpenFOAM within Singularity containers
>
> Unfortunately, it is not so trivial to get singularity images to run in parallel.
> The MPI version within the image must be exactly the same as the version installed on Tetralith Therefore you have to identify which version is used in the image and then use the same version on Tetralith.
> I installed two extra Open MPI versions on Tetralith that I found in two dirrerent openfoam versions on docker hub.
> But there is a good chance that other images use an OpenMPI version that is not available yet.
> In this case, we have to install this openmpi version ... Even if one uses the same Open MPI version, it still may not work, if the MPI in the image was configured/compiled in a very different way than the version we have on Tetralith. E.g. the version Openfoam 1812 on dockerhub works, but 1806 does not since the MPI in **the 1806 image differs from the 1812 image, even they are using the same MPI version**, but some components seem to be missing.
So, in serial the containers work out of the box (which is nice!), but for parallel computation the version of MPI and even more minor configuration settings within a single version should be matched.
What could perhaps be improved on the part of OpenFOAM developers is consistency with respect to the build environment and OpenMPI versions used within the containers for each release, and careful documentation of the configuration settings used. Also, at least version 2.1 of OpenMPI is desirable, since older ones are not fully supported by Singularity.
In the containers from OpenCFD, the versions used seem to be consistent: GCC 4.8.5 and OpenMPI 1.10.4, however, see the bold text in the quote. Also, both GCC and OpenMPI versions are quite old.
In summary
- I wanted to make the devs aware of this effort, which I hope can, upon success, make life easier for quite a lot of people.
- Consistency of settings in the images is very important. Any comment on v1806 vs v1812 regarding OpenMPI settings?
- Would it be possible to use a newer environment with OpenMPI >= 2.1 instead?
Kind regards,
TimofeyMark OLESENMark OLESENhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1481Website only consists of the letter x2019-11-11T11:35:10ZVolker WeißmannWebsite only consists of the letter x[Here](https://www.openfoam.com/documentation/guides/latest/doc/openfoam-guide-mesh-motion.html) you link to [this](https://www.openfoam.com/documentation/guides/latest/doc/guide-mesh-motion-dynamicRefineFvMesh.html) and [this](https://w...[Here](https://www.openfoam.com/documentation/guides/latest/doc/openfoam-guide-mesh-motion.html) you link to [this](https://www.openfoam.com/documentation/guides/latest/doc/guide-mesh-motion-dynamicRefineFvMesh.html) and [this](https://www.openfoam.com/documentation/guides/latest/doc/guide-mesh-motion-dynamicMotionSolverFvMesh.html) website. Both of them are clearly unfinished: Quote from the site:
Properties
XXX
Usage
XXX
Details
XXX
Further information
Source code:
-XXXhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1478No Fields converted with "ensightWrite" FO with region different than region02019-11-04T14:30:29ZNicolas ZerbibNo Fields converted with "ensightWrite" FO with region different than region0*In my process:*
1- I am mapping a VolScalarField (the pressure "p") from region0 on a targetMesh (coarser than region0) on the fly using the "mapFields" FO as:
meshInterp1
{
type mapFields;
libs ...*In my process:*
1- I am mapping a VolScalarField (the pressure "p") from region0 on a targetMesh (coarser than region0) on the fly using the "mapFields" FO as:
meshInterp1
{
type mapFields;
libs ("libfieldFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
mapRegion targetMesh;
mapMethod cellVolumeWeight;
consistent no;
fields (p);
patchMap ();
cuttingPatches (CONTOUR GAMMA_S GAMMA_E);
}
* Then:*
2- I want to use the "ensightWrite" FO on the fly during the execution to convert the pressure field from the OpenFOAM format to the Ensight one as:
ensightWrite_P
{
type ensightWrite;
libs ("libutilityFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
format binary;
directory "postProcessing/EnSight/";
nodeValues yes;
fields ( p );
region targetMesh;
overwrite true;
}
It seems the fields is not converted, only the mesh is present in the Ensigth directory but no fields data:
PIMPLE: iteration 1
smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 5.60474e-06, No Iterations 6
smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 5.1773e-06, No Iterations 5
GAMG: Solving for p, Initial residual = 1, Final residual = 0.00404502, No Iterations 4
time step continuity errors : sum local = 0.00019636, global = -5.23346e-05, cumulative = -5.23346e-05
GAMG: Solving for p, Initial residual = 0.00782886, Final residual = 7.54917e-08, No Iterations 10
time step continuity errors : sum local = 2.98405e-07, global = 3.4694e-08, cumulative = -5.22999e-05
smoothSolver: Solving for epsilon, Initial residual = 0.0426054, Final residual = 7.6249e-06, No Iterations 6
smoothSolver: Solving for k, Initial residual = 1, Final residual = 7.86417e-06, No Iterations 10
ExecutionTime = 0.41 s ClockTime = 1 s
mapFields mapFields write:
p: interpolated and written
ensightWrite ensightWrite write: ( )
but it seems working when I want to field on the "region0" as
ensightWrite_P
{
type ensightWrite;
libs ("libutilityFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
format binary;
directory "postProcessing/EnSight/";
nodeValues yes;
fields ( p );
// region targetMesh;
overwrite true;
}
it gives:
PIMPLE: iteration 1
smoothSolver: Solving for Ux, Initial residual[pitzDailyFO_ensightWrite_Issue.tar.gz](/uploads/a7fa8c9fce78c6653e3f737c39858538/pitzDailyFO_ensightWrite_Issue.tar.gz) = 0.979549, Final residual = 6.32759e-06, No Iterations 11
smoothSolver: Solving for Uy, Initial residual = 0.663667, Final residual = 3.98739e-06, No Iterations 11
GAMG: Solving for p, Initial residual = 0.0514127, Final residual = 0.000190129, No Iterations 4
time step continuity errors : sum local = 0.0001831, global = 4.22034e-05, cumulative = -1.00965e-05
GAMG: Solving for p, Initial residual = 0.013377, Final residual = 5.64195e-08, No Iterations 11
time step continuity errors : sum local = 1.58111e-07, global = -1.82685e-08, cumulative = -1.01148e-05
smoothSolver: Solving for epsilon, Initial residual = 0.0120984, Final residual = 5.31586e-06, No Iterations 5
smoothSolver: Solving for k, Initial residual = 0.359881, Final residual = 3.64655e-06, No Iterations 9
ExecutionTime = 0.45 s ClockTime = 1 s
mapFields mapFields write:
p: interpolated and written
ensightWrite ensightWrite write: ( p )
End
It seems there is a problem with "region" argument in the "ensightWrite" FO
[pitzDailyFO_ensightWrite_Issue.tar.gz](/uploads/04a4b6fdfea001f927059fcff428328c/pitzDailyFO_ensightWrite_Issue.tar.gz)https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1477OpenFOAM mesh to 2D Ansys fluent mesh2019-11-05T16:29:11ZEvrenOpenFOAM mesh to 2D Ansys fluent meshHello,
I've asked this [here](https://www.cfd-online.com/Forums/openfoam-community-contributions/214825-request-openfoam-mesh-2d-ansys-fluent-mesh.html) since nearly 9 months ago.
The `foamMeshToFluent` utility can convert only 3D meshe...Hello,
I've asked this [here](https://www.cfd-online.com/Forums/openfoam-community-contributions/214825-request-openfoam-mesh-2d-ansys-fluent-mesh.html) since nearly 9 months ago.
The `foamMeshToFluent` utility can convert only 3D meshes to Ansys Fluent Mesh. Is there any tool that generates 2D Fluent Mesh from OpenFOAM?
As you know, in OpenFOAM if we want to do a 2D simulation we create a 3D mesh with at least one cell thick in the third dimension and specifying it as `empty` Boundary condition.
IMO, it is more natural to have a tool or at least adding some options to the existing `foamToFluentMesh` utility to convert these 2D meshes to 2D mesh for Ansys Fluent.
Thank youhttps://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1472dynamicCode should use polling instead of re-checking only once2019-11-27T14:16:35ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdynamicCode should use polling instead of re-checking only once### Functionality to add/problem to solve
db/dynamicLibrary/dynamicCode/dynamicCode.C in parallel can have that the library does not exist on all slave processors. It first checks at beginning and then waits 'fileModificationSkew' secon...### Functionality to add/problem to solve
db/dynamicLibrary/dynamicCode/dynamicCode.C in parallel can have that the library does not exist on all slave processors. It first checks at beginning and then waits 'fileModificationSkew' seconds and rechecks. If this fails the code will fail. Nicer if the check gets done multiple times before failing.
Alternatively send over the library (is this possible? is it cross-node compatible?)https://develop.openfoam.com/Development/OpenFOAM-plus/-/issues/1466(wallBounded)streamLine FO does not do bi-directional tracking2019-10-23T15:55:53ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com(wallBounded)streamLine FO does not do bi-directional tracking### Functionality to add/problem to solve
Add bi-directional tracking to streamlines.
### What does success look like, and how can we measure that?
Put e.g. seeds into recirculation zone and see if we can track back and forwards.### Functionality to add/problem to solve
Add bi-directional tracking to streamlines.
### What does success look like, and how can we measure that?
Put e.g. seeds into recirculation zone and see if we can track back and forwards.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com