openfoam issueshttps://develop.openfoam.com/Development/openfoam/-/issues2022-05-17T04:32:25Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2448chemFoam solver gets wrong results when using second order time scheme2022-05-17T04:32:25ZHaochen LiuchemFoam solver gets wrong results when using second order time scheme<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When using the chemFoam solver to to run the corresponding tutorial case, we found that using "Euler" as the ddt scheme leads to correct results, which is the same as the CHEMKIN result (the final temperature is 2660K). While using "backward" or the other second order schemes leads to a much lower final temperature. We are not sure if this issue still exists in reactingFoam, which has been widely used in turbulent combustion simulations by OpenFOAM. This question is very important for us.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
1. Run the tutorial case with default settings and plot the results. The case dictionary is: /tutorials/combustion/chemFoam/gri
2. Change the ddt scheme from "Euler" into "backward" and run the case again.
3. Plot the results and compare them with the CHEMKIN result provided in the tutorial case: /tutorials/combustion/chemFoam/gri/chemkin/senk.out
(The OpenFOAM version we use is v2112)
<!-- How one can reproduce the issue - this is very important -->
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
The final temperature does not agree with the CHEMKIN result for second order ddt schemes.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The final temperature agree with the CHEMKIN result for different ddt schemes.
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2112
- Operating system :Linux
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2246chtMultiRegionFoam looses heat due to explicit coupling2021-10-27T17:02:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comchtMultiRegionFoam looses heat due to explicit coupling### Functionality to add/problem to solve
chtMultiRegionFoam looses heat when evaluating 'mapped' type bcs (e.g. `compressible::turbulentTemperatureRadCoupledMixed`). This is because the owner side evaluates with 'old' neighbour side va...### Functionality to add/problem to solve
chtMultiRegionFoam looses heat when evaluating 'mapped' type bcs (e.g. `compressible::turbulentTemperatureRadCoupledMixed`). This is because the owner side evaluates with 'old' neighbour side values but the neighbour side evaluates with the 'new'
owner side values.
This should instead use a scheme where the owner side also updates the neighbour side patch.
### Target audience
cht on closed domains. See e.g. https://develop.openfoam.com/Development/openfoam/-/blob/develop/applications/test/multiWorld/solidFoam/solid1_solid2 testcase.
Switch off the kappaLayers, switch to transient, switch on the debug flag for the BC so it prints the heat flux for both sides.https://develop.openfoam.com/Development/openfoam/-/issues/2192chtMultiRegionFoam -postProcess does not work2021-10-29T13:46:19ZHenning ScheuflerchtMultiRegionFoam -postProcess does not work
### Summary
The postProcessing results generated by postProcess and during runtime are not identical
### Steps to reproduce
./Allrun
and compare the postProcessing results
### Example case
[multiRegionHeater.tar.xz](/uploads/0901...
### Summary
The postProcessing results generated by postProcess and during runtime are not identical
### Steps to reproduce
./Allrun
and compare the postProcessing results
### Example case
[multiRegionHeater.tar.xz](/uploads/0901403264338b6e67029780bb33ce6b/multiRegionHeater.tar.xz)
### What is the current *bug* behaviour?
The results obtained by function object, probe and wallheatFlux, differ from the runtime results. The wallHeatflux and the temperature probe produce the same value for the whole time series. However, we see the correct behavior for the pressure ,p , with the probe function object
Is the temperature reloaded in the thermoLibraries?
PS the same behavior can also be observed in rhoPimpleFoam tut-case: helmholtzResonance
### What is the expected *correct* behavior?
The results should be identical
### Environment information
- OpenFOAM version : 2012
- Operating system : Ubuntu 2004
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/1615chtMultiregionFoam relaxation problem2021-07-06T17:09:26ZTj KimchtMultiregionFoam relaxation problemIn the Pimple mode with relaxation of p_rgh, the chtMultiregionFoam solver returns an error message of
"not stored. Use field.storePrevIter()"
I found the solver already includes a function call of storePrevIter().
So I think that it is ...In the Pimple mode with relaxation of p_rgh, the chtMultiregionFoam solver returns an error message of
"not stored. Use field.storePrevIter()"
I found the solver already includes a function call of storePrevIter().
So I think that it is out of my job.
The solver in v1906 is same as the v1912.
With the same fvSolution file, OF-7 runs good.
Could you please check the reason?
My recommendation is to update solutioncontrol classes in v1912 similar to those in OF-7Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2442chtMultiRegionFoam with anistropic diffusivity2023-12-07T05:40:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comchtMultiRegionFoam with anistropic diffusivity### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the proper...### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the properties
- if the thermo properties change (e.g. temperature varying alpha)
- if the coordinate system changes (e.g. cylindrical coordinate system, pivoting across second axis)
### Target audience
Anyone using cht with changing solid properties.
### Proposal
Two possibilities:
- have option to update/correct coordinate system and update anisotropic diffusivity accordingly
- not cache aniAlphas but calculate it on-the-fly
@mark @Sergiohttps://develop.openfoam.com/Development/openfoam/-/issues/2225chtMultiRegionSimpleFoam - frozenFlow mode results in large errors2021-12-06T20:45:03ZKumar KrishnachtMultiRegionSimpleFoam - frozenFlow mode results in large errorsRunning chtMultiRegionSimpleFoam on a converged flow by activating the frozenFlow switch to calculate the heat transport results in fairly large deviations in the final temperatures as opposed to running the case in the "normal" (fully c...Running chtMultiRegionSimpleFoam on a converged flow by activating the frozenFlow switch to calculate the heat transport results in fairly large deviations in the final temperatures as opposed to running the case in the "normal" (fully coupled) mode.
Attached is a 2D case to illustrate the problem. It is a simple case of water flowing at high velocity through a narrow channel above a copper plate which is heated from below.
To reproduce the problem, please do the following steps:
(1) Run the case as it is. The case runs in fully coupled mode for 2000 iterations.
(2) Run the case for the first 1000 iterations by turning off the (h|e) solvers in the ./system/copper/fvSolution and ./system/water/fvSolution subdirectories, i.e, please activate the 'maxIter 0' statement.
(3) Now please turn on the frozenFlow keyword in the PIMPLE subdict and run for another 1000 iterations. In this case, deactivate the 'maxIter 0' statement in the respective fvSolution dicts.
We can see that the Temp. results obtained at the end of 2000 iterations in both cases are very different.
[ConjCopperWater.tar.gz](/uploads/9bbe5fd5dedce1ef301d0f0f8c86b96a/ConjCopperWater.tar.gz)
**Environment Information**
- OpenFOAM Version: v2106
- Operating System: Windows 10 (MinGW)
- Hardware Info: PC (HP Z240)https://develop.openfoam.com/Development/openfoam/-/issues/1909chtMultiRegionTwoPhaseEulerFoam, pimple2022-05-24T08:14:58ZRobin KamenickychtMultiRegionTwoPhaseEulerFoam, pimple<!--
*** 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 -->
Solver reports that it runs PIMPLE mode but actually it runs in PISO mode. Further more, residualControl for PIMPLE cannot be used.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Use $FOAM_TUTORIALS/heatTransfer/chtMultiRegionTwoPhaseEulerFoam/solidQuenching2D.
````
$./Allrun
````
Have a look at the log.chtMultiRegionTwoPhaseEulerFoam. It will show
````
PIMPLE: no residual control data found. Calculations will employ 2 corrector loops
````
You can further check that only one outer correction loop was done
![log](/uploads/bc0eaf803d6614eed6a57c2cdd536c3d/log.png)
Then change system/water/fvSolution from
````
PIMPLE
{
nOuterCorrectors 2;
nCorrectors 2;
nNonOrthogonalCorrectors 0;
nEnergyCorrectors 4;
faceMomentum yes;
}
````
into
````
PIMPLE
{
nOuterCorrectors 1;
nCorrectors 2;
nNonOrthogonalCorrectors 0;
nEnergyCorrectors 4;
faceMomentum yes;
}
````
Now, it informs
````
PIMPLE: Operating solver in PISO mode
````
There are no other differences in log because it run before in PISO mode as well. It just informed wrongly.
![log1](/uploads/eee26a12f3287435ec66c42c1fae2e38/log1.png)
Apparently, the solver outer loop logic which loops over fluid and solid regions is based on system/fvSolution. It constructs object of pimpleControl from system/\<region\>/fvSolution, but it does not use it for outer correction loops.
The pimplControl object is constructed in createFluidFields.H but it is used only for pressure correction loops and nonorthogonal correction. Thus, eventhough the number of outercorrectors and residualControl are read from system/\<region\>/fvSolution, they are not used.
The residualControl was tested adding
````
{
p_rgh {relTol 0; tolerance 1e-3;}
}
````
in the PIMPLE dictionary in system/fvSolution and system/water/fvSolution and defining the nOuterCorrectors to 10. However, the residualControl is ignored in system/fvSolution and in system/water/fvSolution is read but not used.
### Example case
Given above
<!--
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?
Given above
<!-- What actually happens -->
### What is the expected *correct* behavior?
It should correctly inform whether PIMPLE runs as PIMPLE or in PISO. Also, residual conrol should be possible to use.
<!-- 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 (most probably also in v2006, but not tested)
- Operating system : ubuntu 16.04.6 LTS
- Hardware info :
- Compiler : gcc
### Possible fixes
Perhaps pimpleControl class should be adapted for multiregion solvers.
<!--
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
-->
/lable ~bugv2206Kutalmış BerçinKutalmış Berçinhttps://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/3041cht solid temperature distribution2023-12-11T19:23:58ZPekkacht solid temperature distribution### Summary
Solid temperature distribution in steady cht solver with mixture models pureZoneMixture and pureMixture leads nonphysical results. The same case by simulated with separated regions give a different results than single region...### Summary
Solid temperature distribution in steady cht solver with mixture models pureZoneMixture and pureMixture leads nonphysical results. The same case by simulated with separated regions give a different results than single region case.
In pureZoneMixture case temperature distribution look that heat goes from lower to higher temperature. In pureMixture case heat flux does not match between regions. Temperature distribution looks logical but temperature levels are much higher that single region case.
![T2](/uploads/7aaa99e1c9251e903504ed2ac6cd0726/T2.png)
### Steps to reproduce
Please find attached cases. By looking heat flux data from log files and temperature distribution is possible notice difference between mixture models.
### Example case
### What is the current _bug_ behaviour?
Results are unreliable
### What is the expected _correct_ behavior?
In pureZoneMixture case temperature distribution can be "fix" by setting the same Cp values to all materials. I think that in solid solver is used alpha instead of kappa in temperature equation.
### Relevant logs and/or images
T fixed wall0 to 300 and wall1 to 400 K. Heat source 10 W in middle of the model. pureZoneMixture heat flux:
```plaintext
min/max/integ(wall0) = -1322.838, -1322.838, -132.2838
min/max/integ(wall1) = 1222.838, 1222.838, 122.2838
```
difference between in and out 10 W and it is OK. Respectively pureMixture case
```plaintext
min/max/integ(wall0) = -114.41282, -114.41282, -11.441282
min/max/integ(z1_to_z2) = 594.6436, 594.6436, 59.46436
min/max/integ(z2_to_z1) = -594.6436, -594.6436, -59.46436
min/max/integ(z2_to_z3) = 2408.3388, 2408.3388, 240.83388
min/max/integ(wall1) = -15889.687, -15889.687, -1588.9687
min/max/integ(z3_to_z2) = -2408.3388, -2408.3388, -240.83388
```
wall0 and wall1 difference is much higher (1588 - 11) than 10 W.
### Environment information
- OpenFOAM version : v2212
- Operating system : AlmaLinux 8
- Hardware info : Intel Core 8
- Compiler : gcc version 8.5.0 20210514 (Red Hat 8.5.0-18) (GCC)
### Possible fixes
\[chtCases.zip\](/uploads/0b33599299701063e04e68c42a50fb47/chtCases.zip
[chtCases.tar.xz](/uploads/12757bc6320abcbbc15e9fded6189f8e/chtCases.tar.xz)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2930"Clean" build fails with ThirdParty MPI2023-07-05T12:20:49ZBernhard Gschaider"Clean" build fails with ThirdParty MPI### Summary
When doing a build on
- a clean system
- with a ThirdParty MPI-implementation
- ThirdParty-packages that depend on that MPI
the compilation of packages depending on MPI fails because thw path to the MPI-implementation is...### Summary
When doing a build on
- a clean system
- with a ThirdParty MPI-implementation
- ThirdParty-packages that depend on that MPI
the compilation of packages depending on MPI fails because thw path to the MPI-implementation is not in the environment variables
This happens because during the first sourcing of the `etc/bashrc` the MPI-Implementation is not there and the variables are therefor not set
### Steps to reproduce
This happens for instance when loading the sources into a docker image where only the bare minimum for compiling is installed (no system-MPI) and running the `$WM_PROJECT_DIR/Allwmake` there
### What is the current *bug* behaviour?
Compilation runs through but some decomposition methods (like Scotch) are missing
### What is the expected *correct* behavior?
Compilation runs through (including Scotch et al)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : OpenFOAM v2306 but also 221 and 2206 (didn't try older)
- Operating system : Unix-like
- Hardware info : any
- Compiler : any
### Possible fixes
This can be fixed by sourcing the config.sh/mpi after the compilation of the MPI-implementation in the ThirdParty-Allwmake.
the patch
[resourceEtcBashrc.patch](/uploads/6368cca5680fc75effe76e233c6d953b/resourceEtcBashrc.patch)
applies this patch to the ThirdParty-2306Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1570Cloud post-processing data not written when steady case converges using resid...2020-01-28T09:28:57ZAndrew HeatherCloud post-processing data not written when steady case converges using residualControl<!--
*** 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 -->
When using clouds in steady solvers combined with case termination controls set using `residualControl` in the `fvSolution` file, cloud post-processing data are not written on the last iteration.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Add `residualControl` settings to a steady flow solver with cloud functionality and cloud a post-processing object, e.g. `particleTracks`
```
particleTracks
{
type particleTracks;
trackInterval 5;
maxSamples 1000000;
resetOnWrite yes;
}
```
and notice that the cloud post-processing data are not written
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
When the criteria specified in the `residualControls` dictionary are achieved the solver loop calls `time.writeAndEnd()` to write any objects registered with `AUTO_WRITE` and exits. Operations such as cloud post-processing are currently only triggered when evolving the cloud and intercept the `writeTime()` flag and are therefore missed.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Couple of options
- instead of exiting straight away, run for 1 more iteration with the `writeTime_` flag set (e.g. using `time.writeOnce()` and exit
- intercept the `write()` call to trigger other post-processing actionsv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1576coded FO does not support mesh changes2020-01-27T15:19:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcoded FO does not support mesh changes### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify...### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify missing callbacks
- syntax inside codedFunctionObject to specify the missing code ('codeMovePoints'?)
- redirection callshttps://develop.openfoam.com/Development/openfoam/-/issues/2117codedFunctionObjects: Info stream in #codeRead is executed twice + Feature re...2021-12-09T16:43:11ZHendrik HetmanncodedFunctionObjects: Info stream in #codeRead is executed twice + Feature request: Info stream number of total cells to standard log.<!--
*** 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 -->
If an Info stream is executed in the #codeRead section of a codedFunctionObject, the line is shown twice. (I don't know if any variables might be assigned twice too?)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Put a line
`Info << "Test" << endl;`
into the #codeRead section of a codedFunctionObject and run the case.
### Example case
I attached a codedFunctionObject "addCellsInfo" to the example case. This is also sort of a feature request: It would be very neat to report the number of total cells in the mesh to standard log on mesh built-up. This would increase the information content of the logs and consequently make it possible to compare the performance between 2 runs just by analyzing their log files.
[pitzDaily_codedfObj.tar.gz](/uploads/8cf5416c96d1d238c5f91dc041faa46d/pitzDaily_codedfObj.tar.gz)
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012 and also in OF7
- Operating system : openSUSE
- 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
-->Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2700coincidentBaffleInteraction missing from the source code (but present in the ...2024-01-04T09:46:28ZFranz DcoincidentBaffleInteraction missing from the source code (but present in the documentation?)In the files multiInteraction.C and multiInteraction.H, there is some reference to a feature / keyword "coincidentBaffleInteraction". While it is documented, it seems that the feature has not been implemented and the keyword is not worki...In the files multiInteraction.C and multiInteraction.H, there is some reference to a feature / keyword "coincidentBaffleInteraction". While it is documented, it seems that the feature has not been implemented and the keyword is not working.
Seems to be a long-standing issue:
https://bugs.openfoam.org/view.php?id=2939
https://www.cfd-online.com/Forums/openfoam-solving/141571-cyclic-boundary-conditions-particles.htmlAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2546colons in filenames break Makefiles2022-08-24T16:42:07ZSergey Matsievskiycolons in filenames break Makefiles<!--
*** 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 -->
OpenFOAM sometimes uses colons in filenames (e.g. `0/jouleHeatingSource:V`). There's a number of issues due to this: #2224 #1142 #1675.
One additional problem with this is that colons (`:`) in file names [break Makefiles](https://lists.gnu.org/archive/html/bug-make/2004-10/msg00010.html).
Consider this example:
```makefile
FIELD_FILES_ORIG:=$(wildcard 0.orig/*)
FIELD_FILES:=$(foreach v,$(FIELD_FILES_ORIG),$(notdir $(v)))
FIELD_FILES_INITIAL:=$(foreach v,$(FIELD_FILES),0/$(v))
0/cellToRegion: constant/polyMesh $(FIELD_FILES_INITIAL) | 0
splitMeshRegions -cellZones -overwrite
renumberMesh -allRegions -overwrite
```
This code tracks changes in `0/*` files and run OpenFOAM subprograms on demand. However, it breaks when `:` characters are in the names of the files.
### Steps to reproduce
Execute code
```bash
git clone https://develop.openfoam.com/Development/openfoam.git --branch master
cd openfoam/tutorials/heatTransfer/chtMultiRegionSimpleFoam/jouleHeatingSolid
cat > Makefile << _EOF_
FILES:=\$(wildcard 0.orig/**/*)
all: \$(FILES)
echo success
_EOF_
make
```
Observe GNU Make error.
Fix file names and try again
```bash
rename 's/:/-/' 0.orig/solid/*
make
```
Observe output string `success`.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
*See `Steps to reproduce`*
### What is the current *bug* behaviour?
<!-- What actually happens -->
OpenFOAM file names break GNU Make automation
### What is the expected *correct* behavior?
OpenFOAM file names do not break GNU Make automation
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
- Operating system : GNU Debian bookworm
- Hardware info : x86-64
- 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
-->
It is clear that changing file name separator would break many existing OpenFOAM based projects. IMHO the best way to deal with this is to replace hardcoded file names with some kind of `FIELD_FILE_NAME_SEPARATOR` macro and throw a deprecation warning when its value is `:`. This way, people could easily roll back changes in case of problems with their projects.https://develop.openfoam.com/Development/openfoam/-/issues/3024compressibleInterFoam crahes when compiled with gcc 11.4.02024-01-19T20:23:54ZChris SesslercompressibleInterFoam crahes when compiled with gcc 11.4.0<!--
*** 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 -->
The provided case crashes within the first 5 iterations due to "Negative initial temperature T0" when compiled with gcc 11.4.0. In contrast, when compiled with gcc 9.5.0 this problem doesn't occur.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run the case after initialization with blockMesh and setFields
### 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
-->
[compressibleInterFoam.zip](/uploads/f52c0f14bdf8eb473e1b5916e70af854/compressibleInterFoam.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
This problem only arised with 3D cases, a different 2D case ran perfectly
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Compilation with gcc 9.5.0 runs stable
### 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.
-->
<details><summary>Error log</summary>
[1] [0]
[0]
[0] --> FOAM FATAL ERROR: (openfoam-2012)
[0] Negative initial temperature T0: -180.035335774
[0]
[0] From Foam::scalar Foam::species::thermo<Thermo, Type>::T(Foam::scalar, Foam::scalar, Foam::scalar, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar, Foam::scalar) const, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar, Foam::scalar) const, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar) const) const [with Thermo = Foam::hConstThermo<Foam::perfectGas<Foam::specie> >; Type = Foam::sensibleEnthalpy; Foam::scalar = double; Foam::species::thermo<Thermo, Type> = Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleEnthalpy>]
[0] in file /home/itvcs/OpenFOAM/OpenFOAM-v2012/src/thermophysicalModels/specie/lnInclude/thermoI.H at line 57.
</details>
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012 commit 79e353b84e3e7cace6ea35c6b7570dfd198d0135
- Operating system : Ubuntu 22.04.3 LTS
- Hardware info : Intel 13th gen
- Compiler : gcc 9.5.0 and 11.4.0
### 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/1213compressibleInterfoam + twoPhaseTransport2024-02-09T21:57:04ZAdmincompressibleInterfoam + twoPhaseTransport<!--
*** 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
Per compressibleInterPhaseTransportModel.H by setting switch to twoPhaseTransport should allow separate turbulence models for each phase (RAS, laminar, LES). Test case ...OpenFOAM-v1812/tutorials/multiphase/compressibleInterFoam/laminar/climbingRod provides further explanation but uses laminar turbulence models only. When the stress model is set to e.g. RAS the solver crashes.
### Steps to reproduce
Change the climbingRod test case to RAS and e.g. kOmegaSST, add omega.air, liquid.air, k.air, k.liquid, alphat.air, alphat.liquid to the 0 folder, update the fvSchemes and fvSolution files and run the case.
### 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
-->
[climbingRod.tar.gz](/uploads/03f55cb8fe6922114873583e5c64d8de/climbingRod.tar.gz)
### What is the current *bug* behaviour?
Solver crashes if the turbulence model is set to anything except laminar.
### What is the expected *correct* behavior?
Case should run, or the error messages should provide indication of how to fix the issues (i.e., the "bananas" approach should guide the user in what is missing).
### 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.
-->
![Selection_001](/uploads/f53d7990a742e1be3297a7cf6bda7228/Selection_001.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 : v1812
Operating system : Ubuntu 16.04
Compiler : GCC
### Possible fixes
Perhaps use the switch (twoPhaseTransport) should direct the solver to use the turbulence models employed by reactingTwoPhaseEulerFoam, e.g. continuousGasKE?
\## Reattaching the author to the issue ticket: @GXA_William ##v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2524construct faMesh fails with distributed roots2022-06-24T11:12:08ZMark OLESENconstruct faMesh fails with distributed rootsNoticed during testing of #2523 - needs more attention
Running `checkFaMesh` with distributed roots:
```
[0] --> FOAM FATAL ERROR: (openfoam-2206)
[0] Cannot find file "faceLabels" in directory "faMesh" in times "0" down to constant
[...Noticed during testing of #2523 - needs more attention
Running `checkFaMesh` with distributed roots:
```
[0] --> FOAM FATAL ERROR: (openfoam-2206)
[0] Cannot find file "faceLabels" in directory "faMesh" in times "0" down to constant
[0]
[0] From virtual Foam::IOobject Foam::fileOperation::findInstance(const Foam::IOobject &, const Foam::scalar, const Foam::word &) const
[0] in file global/fileOperations/fileOperation/fileOperation.C at line 1139
```v2212https://develop.openfoam.com/Development/openfoam/-/issues/2690contactAngle BC in contactAngleCavity tutorial is not working as expected2023-06-13T11:42:29ZIason TsiapkiniscontactAngle BC in contactAngleCavity tutorial is not working as expected<!--
*** 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
In the tutorial case contactAngleCavity, the free surface of a cavity is simulated with the `interfaceTrackingFvMesh` library. In the simulation a contact angle of 70° is set at the walls via the file `0.orig/contactAngle`. The contact angle after running the tutorial, however, is ~80°.
### Steps to reproduce
1. Copy the case `$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/contactAngleCavity`
2. Add the following function objects for post-processing (this writes out the first two and last two points on the free surface):
```
pointHistoryLeft1
{
type pointHistory;
refHistoryPoint (0 0.01 0);
fileName leftPoint.txt;
}
pointHistoryLeft2
{
type pointHistory;
refHistoryPoint (0.00025 0.01 0);
fileName leftPointRef.txt;
}
pointHistoryRight1
{
type pointHistory;
refHistoryPoint (0.01 0.01 0);
fileName rightPoint.txt;
}
pointHistoryRight2
{
type pointHistory;
refHistoryPoint (0.00975 0.01 0);
fileName rightPointRef.txt;
}
```
3. Calculate the angle between the first two and the last two points respectively. This can be done by running the accompanied script `postProcessing.py` inside the simulation directory.
### 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 attached the tutorial case with slight modifications in the `functionObjects`, together with the post-processing script.
Run the case using the `Allrun` script.
[contactAngleCavity.tar](/uploads/2bee417aad9c1e7704685b1632fd4804/contactAngleCavity.tar)
### What is the current *bug* behaviour?
The contact angle at the specified locations is not equal to the set contact angle.
### What is the expected *correct* behavior?
The contact angle should be 70°, as specified in `0.orig/contactAngle`.
### 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.
-->
The Figure below shows the calculated angle between the first two and the last two mesh points. Note that the angle does not change with a longer run time. The tutorial runs only for 0.2s.
![contactAngle](/uploads/d64c2e7a4cbb976a264e470ab9c7a47b/contactAngle.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212
Operating system : ubuntu docker container on windows
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : v2212
Operating system : ubuntu docker container on windows
### 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
-->
The calculations regarding the contact angle can be found in the file
```$FOAM_SRC/dynamicFaMesh/interfaceTrackingFvMesh/freeSurfacePointDisplacement.C```
in lines 120-197. In this approach, the vector `N` is rotated by the value of `contactAngle` at the specified boundaries. The `patchMirrorPoints` at this boundary are then moved using (line 225f.):
```
patchMirrorPoints[patchI] =
peCentres + ((I - 2*N*N)&delta);
```
Maybe the innermost `controlPoints` have to be moved as well to satisfy the contact angle.https://develop.openfoam.com/Development/openfoam/-/issues/1977Contribution: Dynamic load balancing for combustion simulations2023-11-24T16:26:56ZBulut TekgulContribution: Dynamic load balancing for combustion simulationsDear all,
I am writing behalf of my research group in Aalto University, Finland. Recently we have developed a custom chemistry model called DLBFoam that mitigates the well-known computational load imbalance issue in multi-processor reac...Dear all,
I am writing behalf of my research group in Aalto University, Finland. Recently we have developed a custom chemistry model called DLBFoam that mitigates the well-known computational load imbalance issue in multi-processor reactive CFD simulations using finite-rate chemistry and provides speed-up by 10 fold. Our model consists of two main features:
* A dynamic load balancer that uses MPI routines to balance the load between the processors during runtime
* A zonal reference mapping model based on Bilger's mixture fraction to map the chemistry solution of the cells from a reference solution instead of explicitly solving them, when applicable.
![crab pet](https://i.imgur.com/yYVBgHV.gif)
Our code is very well written and implemented with following OpenFOAM's code structure and guidelines and can be found in our public repository:
[GitHub - DLBFoam](https://github.com/blttkgl/DLBFoam)
You can find the branch called v1.0_OF2006 to see the version compatible with OpenFOAM ESI.
In addition, the preprint describing the code in great detail and providing benchmarking results are available at:
[ArXiv - DLBFoam](https://arxiv.org/abs/2011.07978)
There are still some things that need to be ironed out for a fully compatible contribution.
Minor:
* The Bilger's mixture fraction that we implement ourselves can be easily changed with the Bilger's mixture fraction that is implemented to OpenFOAM a while ago: [Issue Link](https://develop.openfoam.com/Development/openfoam/-/issues/1915)
Major:
* The chemistry model **at the moment** is derived from StandardChemistryModel and it does not extend to TDACChemistryModel. However, this is a low hanging fruit and can be easily implemented in a future release by us.
Finally, we will be rolling out some major changes to DLBFoam in the near future, such as replacing the finite-difference Jacobian of the chemistry ODE system with an analytical solution and using optimized matrix routines for the ODE solver. Combined with these features, we report speedup in the order of 200x in large 3D cases compared to StandardChemistryModel. Unlike DLBFoam at its current state these features are dependent on some open-source third party libraries but we would be glad to share them as well as contributions.
Please let me know if you are interested with this contribution and if yes what else would you require from us to move on with the contribution process. I will be following this thread but also feel free to reach at to me from bulut.tekgul@aalto.fi
Best,
Bulut