Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-12-28T11:46:27Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1860chtMultiRegionTwoPhaseEulerFoam, Population Balance2020-12-28T11:46:27ZRobin KamenickychtMultiRegionTwoPhaseEulerFoam, Population Balance<!--
*** 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
Population balance (PPB) is not calculated when
`solveOnFinalIterOnly true;
`
is used for the PPB in fvSolution of chtMultiRegionTwoPhaseEulerFoam solver.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Use $FOAM_TUTORIALS/heatTransfer/chtMultiRegionTwoPhaseEulerFoam/solidQuenching2D.
Go in constant/water/phaseProperties setup to use predefined PPB:
Change following lines of code from:
````
type thermalPhaseChangeTwoPhaseSystem;
phases (gas liquid);
// phase change in the bulk of the fluid.
phaseChange off;
//populationBalances (bubbles);
gas {
type purePhaseModel;
diameterModel isothermal;
isothermalCoeffs
{
d0 5e-3;
p0 1e5;
}
Sc 0.7;
velocityGroupCoeffs
{
populationBalance bubbles;
formFactor 0.5235987756;
sizeGroups
(
f0 {d 0.5e-4; value 0 ;}
f1 {d 1.040e-3; value 0 ;}
f2 {d 1.640e-3; value 0 ;}
f3 {d 2.265e-3; value 0 ;}
f4 {d 2.889e-3; value 0 ;}
f5 {d 3.512e-3; value 0 ;}
f6 {d 4.141e-3; value 0 ;}
f7 {d 4.771e-3; value 1 ;}
f8 {d 5.402e-3; value 0 ;}
f9 {d 6.033e-3; value 0 ;}
f10 {d 6.665e-3; value 0 ;}
f11 {d 7.297e-3; value 0 ;}
f12 {d 7.929e-3; value 0 ;}
f13 {d 8.562e-3; value 0 ;}
f14 {d 9.194e-3; value 0 ;}
f15 {d 1.194e-2; value 0 ;}
f16 {d 2.400e-2; value 0 ;}
f17 {d 2.700e-2; value 0 ;}
f18 {d 3.000e-2; value 0 ;}
);
}
residualAlpha 1e-4;
}
````
into
````
type thermalPhaseChangePopulationBalanceTwoPhaseSystem;
phases (gas liquid);
// phase change in the bulk of the fluid.
phaseChange off;
populationBalances (bubbles);
gas
{
type purePhaseModel;
diameterModel velocityGroup;
velocityGroupCoeffs
{
populationBalance bubbles;
formFactor 0.5235987756;
sizeGroups
(
f0 {d 0.5e-4; value 0 ;}
f1 {d 1.040e-3; value 0 ;}
f2 {d 1.640e-3; value 0 ;}
f3 {d 2.265e-3; value 0 ;}
f4 {d 2.889e-3; value 0 ;}
f5 {d 3.512e-3; value 0 ;}
f6 {d 4.141e-3; value 0 ;}
f7 {d 4.771e-3; value 1 ;}
f8 {d 5.402e-3; value 0 ;}
f9 {d 6.033e-3; value 0 ;}
f10 {d 6.665e-3; value 0 ;}
f11 {d 7.297e-3; value 0 ;}
f12 {d 7.929e-3; value 0 ;}
f13 {d 8.562e-3; value 0 ;}
f14 {d 9.194e-3; value 0 ;}
f15 {d 1.194e-2; value 0 ;}
f16 {d 2.400e-2; value 0 ;}
f17 {d 2.700e-2; value 0 ;}
f18 {d 3.000e-2; value 0 ;}
);
}
residualAlpha 1e-4;
}
````
further change lines
````
coalescenceModels
(
PrinceBlanch
{
C1 0.05;
h0 1e-4;
hf 1e-8;
turbulentCollisions true;
buoyantCollisions false;
laminarShearCollisions false;
}
);
````
into
````
coalescenceModels
(
PrinceBlanch
{
C1 0.05;
h0 1e-4;
hf 1e-8;
turbulence true;
buoyancy false;
laminarShear false;
}
);
````
and
````
driftModels
(
phaseChange
{
pairNames (gasAndLiquid);
}
densityChange{}
);
````
into
````
driftModels
(
phaseChange
{
pairs ((gas and liquid));
}
densityChange{}
);
````
Then change following line in constant/water/turbulenceProperties.liquid from
````
simulationType laminar;
````
into
````
simulationType RAS;
````
Then run
````
$./Allrun
````
When you have a look at the log.chtMultiRegionTwoPhaseEulerFoam you will see that no PPB is calculated during any iteration.
Change following lines in system/water/fvSolution
````
solveOnFinalIterOnly true;
````
into
````
solveOnFinalIterOnly false;
````
run
````
$./Allclean
$./Allrun
````
in the log.chtMultiRegionTwoPhaseEulerFoam, you can see the PPB being calculated each iteration.
<!-- How one can reproduce the issue - this is very important -->
### Example case
Mentioned in the step to reproduce. Shown at a tutorial case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
No PPB is calculated if chosen to run only during the last iteration.
<!-- What actually happens -->
### What is the expected *correct* behavior?
User should be able to choose when the PPB runs. User might think that the PPB runs during the last iteration even though it is not apparent in the log. However, the true is it does not run at all. Explanation in the fix section.
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : 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 16.04.6 LTS
- Hardware info :
- Compiler : gcc
Most probably, the same issue will be also with v2006.
### Possible fixes
The problem is that chtMultiRegionTwoPhaseEulerFoam does not cunstruct object of pimpleControl class and does not use it. It is rather "hard coded" in the solver to be able to do the iterations based on the user choice. However, populationBalanceModel class uses the pimpleControl class. Then it comes to line populationBalanceModel.C:1236
````
if (!solveOnFinalIterOnly || pimple_.finalIter())
````
where it decides whether to calculate the PPB. If the `solveOnFinalIterOnly true`, it means that this if condition should evaluate true only when `pimple_.finalIter() = true`, but that never happen because the function pimple_.finalIter() gives false
````
inline bool Foam::pimpleControl::finalIter() const
{
return converged_ || (corr_ == nCorrPIMPLE_);
}
````
because the corr_ is always equal to zero.
Some time ago, I worked on the same solver using the version of OpenFOAM Foundation. There is available class called pimpleMultiRegionControl, which manages the pimple logic for multiregion solvers. Having that, I only made a copy of populationBalanceModel class and changed the costructer to use pimpleMultiRegionControl instead of pimpleControl. Certainly, this leads to code duplication because majority of lines for populationBalanceModel are same. Further more if pimpleMultiRegionControl is used in ESI group version then other multiregion solvers should be adjusted adequatly.
Certainly, there might be some other ways how to pass the information about the last iteration to populationBalanceModel class.
<!--
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/1702Wrong displacement accumulation in dynamicMotionSolverListFvMesh2021-01-01T17:00:07ZRomero MoreiraWrong displacement accumulation in dynamicMotionSolverListFvMesh<!--
*** 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 -->
The dynamicFvMesh type named dynamicMotionSolverListFvMesh produces unexpected mesh displacement when two or more motion solvers with non-zero displacement are included in dynamicMeshDict. The explanation would be an incorrect displacement value attribution in the code in dynamicMotionSolverListFvMesh.C.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Applying two or more different solvers in dynamicMeshDict with non-zero displacement components may already cause the issue.
### 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
-->
The attatched example case illustrates the displacement miscalculation, and can be run by tiping:
1. blockMesh
2. moveDynamicMesh
3. paraFoam
### What is the current *bug* behaviour?
The example case shown in the attatched file, which presents constant mesh movement speed for both x and y axis, moves the mesh in the expected direction and with desired displacement variation, but only in alternated time steps. During the other timesteps the mesh is kept almost unchanged, hence halving the expected total displacement for a larger number of time steps. More complex movement cases move the mesh in more unpredictable ways.
<!-- What actually happens -->
### What is the expected *correct* behavior?
For the attatched case, points in the mesh should move 0.2 m in both x and y directions for every 1 s time step.
<!-- What you should see instead -->
### 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 : v1912
- Operating system : ubuntu
- Hardware info : Dell Inspiron 14
- Compiler : gcc
### Possible fixes
The problem was found to be in the Member Function of the code dynamicMotionSovlerListFvMesh.C (located in src/dynamicFvMesh/dynamicMotionSolverListFvMesh), more precisely at lines (123 to 130), as shown bellow:
>
pointField disp(motionSolvers_[0].newPoints() - fvMesh::points());
for (label i = 1; i < motionSolvers_.size(); i++)
{
disp += motionSolvers_[i].newPoints() - fvMesh::points();
}
fvMesh::movePoints(points() + disp);
For every motion solver, the code extract the difference between its result and the current mesh, sum all the results and add that value of displacement to the current mesh points, returning then the new mesh position. The problem is that every motion solver moves the mesh independently of other solver and its result is the respective displacement in relation to the initial time instant. Thus subtracting its result from the current mesh (which is a combination of the movement of all solvers) produce an incorrect mesh displacement. A possible correction would be adding a pointField type variable (hereby named initialMesh) to which the mesh point coordinates of the initial time instant of the simulation is atributed. The new code would be:
>
pointField disp(motionSolvers_[0].newPoints() - initialMesh);
for (label i = 1; i < motionSolvers_.size(); i++)
{
disp += motionSolvers_[i].newPoints() - initialMesh;
}
fvMesh::movePoints(initialMesh + disp);
<!--
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
-->
[exampleCase.tar.gz](/uploads/85f8e45f35a62000c130af2f579aab57/exampleCase.tar.gz)ghttps://develop.openfoam.com/Development/openfoam/-/issues/1964extrudeMesh from patch does not map correctly2021-01-04T14:46:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comextrudeMesh from patch does not map correctly<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
extrudeMesh-from-patch produces maps back to original mesh so do not make sense.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Take cavity. Extrude movingWall patch into new mesh. Switch on polyTopoChange::debug. Debug output uses countMap which accesses outside range.
### 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 : 2006
### 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
-->Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1915Contribution: Bilger Mixture Fraction Function Object2021-01-07T23:41:13ZThorsten ZirwesContribution: Bilger Mixture Fraction Function ObjectDear all,
I recently created a new function object for computing the Bilger mixture fraction from species data. I'm not sure what the correct channel is to contribute the code, since I cannot create a fork here on gitlab. For example, s...Dear all,
I recently created a new function object for computing the Bilger mixture fraction from species data. I'm not sure what the correct channel is to contribute the code, since I cannot create a fork here on gitlab. For example, should I upload a git patch file for code review?
Here are more information about the new function object:
The Bilger mixture fraction indicates the mixing ratio of fuel and oxidizer (kg fuel / kg mixture) and is often used in combustion simulations, either as part of a combustion model or to study the structure of flames. By having a function object that computes the mixture fraction from the resolved chemical species, users can create their own lookup tables for mixture fraction based combustion models or simply use it for post processing/visualization.
My implementation is based on a pull request I did some time ago for the open-source thermo-chemical library Cantera (https://github.com/Cantera/cantera/pull/851). It computes the mixture fraction based on the elemental composition of fuel, oxidizer and the mixture.
Similar functionality has been requested before ([link](https://www.cfd-online.com/Forums/openfoam/217824-mixture-fraction-formulation.html), [link](https://www.cfd-online.com/Forums/openfoam/176755-utility-calculate-mixture-fraction.html), [link](https://www.cfd-online.com/Forums/openfoam-post-processing/214632-temperature-vs-mixture-fraction.html), [link](https://www.cfd-online.com/Forums/openfoam/176601-mixture-fraction-code-implementation-sprayfoam.html)). There are also some user implementations ([link](https://github.com/adhiraj-dasgupta/unsupportedContribOF23x/tree/master/applications/utilities/CalcMixtureFraction), [link](https://bugs.openfoam.org/view.php?id=3411)), however, they only work for specific solvers and do not make use of the information provided by the `reactingMixture` types.
I tested my implementation with the following solvers to make sure that it is compatible with a wide range of solvers and models:
- **combustion**: `reactingFoam, rhoReactingFoam, rhoBuoyantReactingFoam, chemFoam, fireFoam`
- **lagrangian**: `sprayFoam, coalChemistryFoam, reactingParcelFoam`
- **heatTransfer**: `chtMultiRegionFoam`
- **multiphase**: `reactingTwoPhaseEulerFoam`
I also ran the test cases from the Cantera test suite to validate the results. Everything is tested with the current develop branch (1d544540) and gcc 10.
Let me know if this is of interest and if so what the best way is to start the contribution process.
Kind regards,
Thorstenv2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1975apt-get update error : It seems that the xenial distribution does not exits?2021-01-14T17:25:49ZDavid Gomezapt-get update error : It seems that the xenial distribution does not exits?Hello, Im trying to install v2012 on a Ubuntu 16.04 but when I do
apt-get update I get:
`Err :11 https://dl.openfoam.com/repos/deb xenial/main amd64 Packages
404 Not Found`
`E: Impossible de récupérer https://dl.openfoam.com/repos/...Hello, Im trying to install v2012 on a Ubuntu 16.04 but when I do
apt-get update I get:
`Err :11 https://dl.openfoam.com/repos/deb xenial/main amd64 Packages
404 Not Found`
`E: Impossible de récupérer https://dl.openfoam.com/repos/deb/dists/xenial/main/binary-amd64/Packages 404 Not Found
`
then offcourse if i do sudo apt-get install openfoam2012-default i get
`Lecture des listes de paquets... Fait`
`Construction de l'arbre des dépendances`
`Lecture des informations d'état... Fait`
`E: Impossible de trouver le paquet openfoam2012-default`
Am I missing something The xenial distribution seems not to exits
Thank you in advancehttps://develop.openfoam.com/Development/openfoam/-/issues/1627Build with AOCC Compiler Fails2021-01-22T10:48:23ZNikola MajksnerBuild with AOCC Compiler FailsHi there,
I'm trying to build OpenFOAM v1912 with the AOCC compiler that is optimized for the new AMD processors. But I'm getting an error at the very end of the compilation process when the OpenFOAM applications are getting compiled.
...Hi there,
I'm trying to build OpenFOAM v1912 with the AOCC compiler that is optimized for the new AMD processors. But I'm getting an error at the very end of the compilation process when the OpenFOAM applications are getting compiled.
OS: Ubuntu 18.04
OpenFOAM Version: v1912
Compiler: [AOCC(Clang)](https://developer.amd.com/amd-aocc/)
Below are the commands that I'm running:
```bash
$ apt-get install build-essential flex bison cmake zlib1g-dev libboost-system-dev libboost-thread-dev libopenmpi-dev openmpi-bin gnuplot libreadline-dev libncurses-dev libxt-dev libscotch-dev libcgal-dev curl wget
$ wget https://sourceforge.net/projects/openfoam/files/v1912/OpenFOAM-v1912.tgz
$ wget https://sourceforge.net/projects/openfoam/files/v1912/ThirdParty-v1912.tgz
$ mkdir /opt/OpenFOAM && tar -xzf OpenFOAM-v1912.tgz -C /opt/OpenFOAM && tar -xzf ThirdParty-v1912.tgz -C /opt/OpenFOAM
$ sed -i 's/export WM_COMPILER=.*/export WM_COMPILER=Clang/' /opt/OpenFOAM/OpenFOAM-v1912/etc/bashrc
$ source /opt/OpenFOAM/OpenFOAM-v1912/etc/bashrc
$ curl 'https://developer.amd.com/aocc-compiler-eula/' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:74.0) Gecko/20100101 Firefox/74.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Accept-Language: en-GB,en;q=0.5' --compressed -H 'Content-Type: application/x-www-form-urlencoded' -H 'Origin: https://developer.amd.com' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: https://developer.amd.com/aocc-compiler-eula/' -H 'Cookie: c_slidebox_lists=; AKA_A2=A; ak_bmsc=08125A7934F9BC415C45AA72039B16E35435930DA136000064E6685E238A1876~pldSTaRB4wo4gj/7xqZwXbAwCMYYxDpl7AudDCN5q/uyPftrKXIBfjWmPvOTtHqaQALZ5YfYDBwbjJu6wqJwvtJIMB+WaJ1MWYgiREFZ77EA7xTBk7xsVM7E8O2+qzX9Yqf4o9fkwDuK3BKxyT97gLGgIz/kQZhjxmxqGEkfa3QRzWYj5Ar4onwEXHpr7YncScOzkQotLixqAh3bf3Ekhfu54ZkqnuAOIPl6+IyTwEdFg=; c_rurl=https%3A//developer.amd.com/aocc-compiler-eula/' -H 'Upgrade-Insecure-Requests: 1' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' -H 'TE: Trailers' --data 'amd_developer_central_nonce=7a6cd4da48&_wp_http_referer=%2Faocc-compiler-eula%2F&f=YW9jYy1jb21waWxlci0yLjEuMF8xX2FtZDY0LmRlYg%3D%3D' --output aocc.deb
$ dpkg -i aocc.deb
$ source /opt/AMD/aocc-compiler-2.1.0/setenv_AOCC.sh
$ foam
$ ./Allwmake -j -s -l
```
Most of the commands are taken from https://www.openfoam.com/documentation/system-requirements.php and https://www.openfoam.com/code/build-guide.php
Changing back `export WM_COMPILER=Gcc` in `/opt/OpenFOAM/OpenFOAM-v1912/etc/bashrc` results in successful build of OpenFOAM
Attached is the output of compile process.
Thanks,
[log.linux64ClangDPInt32Opt](/uploads/dce39906cb23b74cc534892624feb4f8/log.linux64ClangDPInt32Opt)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1932wall distance calculation correction for point-connected faces2021-01-25T13:38:59ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwall distance calculation correction for point-connected faces<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
On one user case (ep 1442) it was reported that applyBoundaryLayer crashes. This seems to be due to the wall distance calculation. Upon visual inspection the code was not checking for duplicate faces enough so could run out of work array in extreme cases.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Cannot reproduce
### What is the current *bug* behaviour?
<!-- What actually happens -->
Crash in applyBoundaryLayers, seemingly from wall distance calculation (and cellDistFuncs correction for point-connected faces)
### 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
### 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
-->
- use dynamically resized lists
- use more duplicate face checkingMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1982BUG in nearestPatchFaceAMI between regions (v2012)2021-01-26T20:22:11ZRegő SimonBUG in nearestPatchFaceAMI between regions (v2012)<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
In the 2012 version the nearestPatchfaceAMI mapping between regions is broken.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. For example run the multiRegionHeaterRadiation case with allrun. Works fine.
2. Modify the following entry in the constant/topAir/polyMesh/boundary file as (sampleMode is modified to AMI mapping):
```
topAir_to_rightSolid
{
type mappedWall;
inGroups 2 ( wall viewFactorWall );
nFaces 130;
startFace 3760;
sampleMode nearestPatchFaceAMI;
sampleRegion rightSolid;
samplePatch rightSolid_to_topAir;
}
```
3. Modify the following entry in the constant/rightSolid/polyMesh/boundary file as (sampleMode is modified to AMI mapping):
```
rightSolid_to_topAir
{
type mappedWall;
inGroups 1 ( wall );
nFaces 130;
startFace 403;
sampleMode nearestPatchFaceAMI;
sampleRegion topAir;
samplePatch topAir_to_rightSolid;
}
```
4. Now we have a nearestPatchfaceAMI mapping between the topAir and rightSolid. Let's run the simulation again from time 0.
5. The mapping crashes with the following message even on a matching mesh:
```
--> FOAM FATAL ERROR: (openfoam-2012)
did not find sample (0.01666666 0.008 -0.045) on patch topAir_to_rightSolid on region topAir on processor 0
From void Foam::mappedPatchBase::calcMapping() const
in file mappedPatches/mappedPolyPatch/mappedPatchBase.C at line 946.
FOAM exiting
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1973redistributePar: does not decompose cyclicACMI2021-01-26T20:22:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar: does not decompose cyclicACMI<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
`redistributePar -decompose` does not handle cyclicACMI
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run `redistributePar -decompose` on e.g.
`tutorials/incompressible/pimpleFoam/RAS/oscillatingInletACMI2D`
It will give error about `turbulenceProperties` since it tries to evaluate the cyclicACMI (which evaluates the blockage bc)
### 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 : v2012Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1987FunctionObject from foamNewFunctionObject does not compile2021-01-26T20:22:11ZHenning ScheuflerFunctionObject from foamNewFunctionObject does not compile<!--
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
functionObject generated by the utility foamNewFunctionObject does not compile
### Environment information
- OpenF...<!--
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
functionObject generated by the utility foamNewFunctionObject does not compile
### Environment information
- OpenFOAM version : of2006,of2012,ofdev
- Operating system : ubuntu
- Hardware info :
- Compiler : gcc
### Possible fixes
error in following line:
```
boolData_(dict.getOrDefault<bool>("boolData"), true),
```
replace with
```
boolData_(dict.getOrDefault<bool>("boolData", true)),
```https://develop.openfoam.com/Development/openfoam/-/issues/595simplify/extend List, DynamicList2021-01-26T20:22:11ZMark OLESENsimplify/extend List, DynamicListInspired by some of Franjo's @Juretic work, I've started looking into how to incorporate the short list optimization into the standard DynamicList as well as other methods and possible optimizations. I'd like some feedback on some of the...Inspired by some of Franjo's @Juretic work, I've started looking into how to incorporate the short list optimization into the standard DynamicList as well as other methods and possible optimizations. I'd like some feedback on some of these ideas @andy @Mattijs
The static allocation size needs to be templated but the number of parameters for DynamicList is growing too much. My current thought is to remove the SizeInc,SizeMult,SizeDiv from templates and replace with a run-time sizing policy that we can combine with templated factory methods for some compile-time safety.
Eg,
template<class T, unsigned StaticSize = 16>
class DynamicList
{
...
//-
inline void setSizingPolicy(const sizingPolicy& policy);
};
In use this would mean something like this:
DynamicList<label> lst;
lst.setSizingPolicy(sizingPolicy::increment<10>());
lst.setSizingPolicy(sizingPolicy::factor<2>());
lst.setSizingPolicy(sizingPolicy::factor<3,2>());
lst.setSizingPolicy(sizingPolicy::general<10,3,2>());
This is still a long way from handling allocations with an allocator, but I think it is an improvement.
To accommodate some other routines, I've tentatively added in these methods:
UList
//- Find index of the first occurence of the value.
// Linear search.
// \return -1 if not found.
label find(const T& val, const label start=0) const;
//- True if the value if found in the list. Linear search.
inline bool found(const T& val, const label start=0) const;
//- Move element to the first position.
void moveFirst(const label i);
//- Move element to the last position.
void moveLast(const label i);
//- Swap with the first element. Fatal on an empty list.
void swapFirst(const label i);
//- Swap with the last element. Fatal on an empty list.
void swapLast(const label i);
DynamicList
//- Remove and return the last element. Fatal on an empty list.
inline T remove();
//- Remove and return the specified element. Fatal on an empty list.
// With fast=true (default), the removed element is replaced with
// the last one in the list.
// With fast=false, the elements are copied down in the list.
inline T remove(const label i, const bool fast=true);v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/240Improvements to foamToEnsight*2021-01-27T10:52:08ZMark OLESENImprovements to foamToEnsight*During testing of issue #231 noticed that startup/conversion time (per step) to be dependent on the number of times-steps converted (foamToEnsight).
The per step conversion time for foamToEnsightParts is constant.
In serial, the writing ...During testing of issue #231 noticed that startup/conversion time (per step) to be dependent on the number of times-steps converted (foamToEnsight).
The per step conversion time for foamToEnsightParts is constant.
In serial, the writing times for foamToEnsight are generally much slower than foamToEnsightParts.
No comparison in parallel, since foamToEnsightParts is not yet parallelized.Version v1612Mark OLESENMark OLESEN2016-10-14https://develop.openfoam.com/Development/openfoam/-/issues/1874support multiple faceZones/patches in sampling and surfaceFieldValue2021-02-01T18:50:37ZMark OLESENsupport multiple faceZones/patches in sampling and surfaceFieldValueItems raised in EP1415, EP1416
- should sampling onto faceZones.
Currently does not exist, even although they are supported in surfaceFieldValue.
- no support for multiple patches or faceZones in surfaceFieldValue.
Sampling onto mult...Items raised in EP1415, EP1416
- should sampling onto faceZones.
Currently does not exist, even although they are supported in surfaceFieldValue.
- no support for multiple patches or faceZones in surfaceFieldValue.
Sampling onto multiple patches works, so why not surfaceFieldValue.
@Prashantv2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2000Support surface sampling on internal fields2021-02-09T19:26:52ZMark OLESENSupport surface sampling on internal fieldsMentioned on cfd-online, could be useful to sample internal (dimensioned) fields. Will work for many surface types, but might need special care for patch samplers etc.Mentioned on cfd-online, could be useful to sample internal (dimensioned) fields. Will work for many surface types, but might need special care for patch samplers etc.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1998change default setting for sigFpe2021-02-10T12:33:30ZMark OLESENchange default setting for sigFpeReported as a spack issue for Fujitsu: https://github.com/spack/spack/pull/21336
It might be reasonable to have the default disabled. This does cover over possible issues, but perhaps something that we only have enabled for our test loo...Reported as a spack issue for Fujitsu: https://github.com/spack/spack/pull/21336
It might be reasonable to have the default disabled. This does cover over possible issues, but perhaps something that we only have enabled for our test loops?
@andy @Mattijs @Sergio @kuti @Prashanthttps://develop.openfoam.com/Development/openfoam/-/issues/2002foamToEnsight cellZone conversion issues2021-02-16T07:45:04ZMark OLESENfoamToEnsight cellZone conversion issuesMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1999surfaceFieldValue surface writer (VTK) fails with multiple fields2021-02-17T12:46:07ZMark OLESENsurfaceFieldValue surface writer (VTK) fails with multiple fieldscross-ref EP-1482 - agreed to fix in develop
It only outputs the final field.cross-ref EP-1482 - agreed to fix in develop
It only outputs the final field.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2004Potential bug with explicitPorositySource when using a cylindrical reference ...2021-02-17T14:24:39ZRiccardo RossiPotential bug with explicitPorositySource when using a cylindrical reference systemI have recently updated a model developed with the v1606 to the latest v2012 release and found an issue.
The model features a region consisting of four several cell zones where the explicitPorositySource is used to apply a pressure drop...I have recently updated a model developed with the v1606 to the latest v2012 release and found an issue.
The model features a region consisting of four several cell zones where the explicitPorositySource is used to apply a pressure drop as well as allow the flow to move perpendicularly through the zones only.
Since some of the zones are curved, a local cylindrical reference system is used to apply a finite porosity coefficient in the radial direction only.
In the v1606 (first picture attached) everything works fine but the same settings in the v2012 lead to correct behavior in the straight regions but not in the curved ones.
I've been looking in the documentation and it looks like the syntax for the reference system did not change, so I'm wondering if this could be an actual bug.
Syntax:
````
coilPackageSouthWestPorosity
{
type explicitPorositySource;
active yes;
explicitPorositySourceCoeffs
{
selectionMode cellZone;
cellZone coilPackageSouthWest;
type DarcyForchheimer;
DarcyForchheimerCoeffs
{
f (0 -1000 -1000);
d (2.209e+07 -1000 -1000);
coordinateSystem
{
type cartesian;
origin (-0.375 -0.05 0);
coordinateRotation
{
type cylindrical;
e3 (0 0 1);
}
}
}
}
}
````
![v1606](/uploads/d9add3d8559606f35ec9202b326451d3/v1606.png)
![v1912](/uploads/6dbf1184d0c1d889a26c3571223e2e84/v1912.png)https://develop.openfoam.com/Development/openfoam/-/issues/2007checkMesh: output fvc::laplacian of mesh.C()2021-02-18T14:40:57ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh: output fvc::laplacian of mesh.C()### Functionality to add/problem to solve
To additional mesh quality check for solving fc equations (e.g. fvc::laplacian, fvc::grad)
### Proposal
Write output of fvc::laplacian, fvc::grad of analytical functions in checkMesh -writeAll...### Functionality to add/problem to solve
To additional mesh quality check for solving fc equations (e.g. fvc::laplacian, fvc::grad)
### Proposal
Write output of fvc::laplacian, fvc::grad of analytical functions in checkMesh -writeAllFields. Can currently be done through coded functionObjects (e.g.
https://develop.openfoam.com/internal/OpenFOAM-nonRelease/-/blob/master/doc/Notes/dynamicCode.org)https://develop.openfoam.com/Development/openfoam/-/issues/1868Compiled error while using DimensionedField<tensor, volMesh>2021-02-22T06:59:38ZGuan ChaoranCompiled error while using DimensionedField<tensor, volMesh>I encountered a compiled error while using Dimensioned<tensor, volMesh>. Here is what I wrote in the createFields.H of the icoFoam:
```
volTensorField Ut = fvc::grad(U);
DimensionedField<tensor, volMesh> Ud = Ut.internalField();
Info << ...I encountered a compiled error while using Dimensioned<tensor, volMesh>. Here is what I wrote in the createFields.H of the icoFoam:
```
volTensorField Ut = fvc::grad(U);
DimensionedField<tensor, volMesh> Ud = Ut.internalField();
Info << Ud << endl;
Info << Ud.T() << endl;
```
And the compiled error was:
```
error: no matching function for call to ‘T(const Foam::Field<Foam::Tensor<double> >&, const Foam::Field<Foam::Tensor<double> >&)’ Foam::T(result(), *this);
```
Then I found the Foam::T() functions in the FieldFunctions.H is declared as
```
template<class Type> void T(Field<Type>& res, const UList<Type>& f);
```
However, the member function T() of the class dimensionedField<Type, GeoMesh> is defined as
```
template<class Type, class GeoMesh> tmp<DimensionedField<Type, GeoMesh>> DimensionedField<Type, GeoMesh>::T() const
{
tmp<DimensionedField<Type, GeoMesh>> result
(
DimensionedField<Type, GeoMesh>::New
(
name() + ".T()",
mesh_,
dimensions_
)
);
Foam::T(result(), *this);
return result;
}
```
where the operator() of the tmp<T> return a const reference of T rather than a non-const reference which is required by Foam::T() global function.
So, I modify the above code:
```
Foam::T(result(), *this);
```
into:
```
Foam::T(result.ref(), *this);
```
After this modification, the compilation can be done successfully.
Actually I encountered this problem in openFOAM 8 version. But I checked the corresponding source codes of OpenFOAM V2006. The same problem seems also exists.Mark OLESENMark OLESEN