Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-01-10T11:24:32Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2536Problems with the "useImplicit" feature for coupled patches2024-01-10T11:24:32ZTobias HolzmannProblems with the "useImplicit" feature for coupled 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 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 -->
Hey everybody, since we introduced the `useImplicit` keyword for coupled patches, I had the feeling that we have discrepancies using this feature in the energy equation (e.g., for chtMultiRegionSimpleFoam cases). After having some discussions on the 17th OpenFOAM workshop, people second my statement, that the `implicit` implementation is somehow buggy and lead to different results compared to running the case in the weakly coupling mode (standard one).
Hence, I made further investigations by using the multiRegionHeaterRadiation tutorial:
- Added a FO to record the average temperature inside each region
- Running the case in standard mode
- Running the case by adding the `useImplicit` keyword to the mapped boundary conditions (for all regions)
- Comparing the average temperatures of all regions between both simulations
- Simulation was run for 5000 iterations
- Simulation was performed in serial (no parallel run performed up to now)
The comparison is attached and as we can see, we get different results.
I also attached both cases and the gnuplot script.
If we do have mismatches for the CHT cases, I guess the `cyclic*` patches might have problems as well (e.g., AMI and aero).
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Unpack the tar ball with the two cases + the gnuplot script.
Run the Allrun script for both cases and execute the gnuplot script.
### Example case
Already mentioned above. No further information required here.
[chtMultiRegionTestCasesImplicitBug.tar.gz](/uploads/9397d6b19087f36fbc0ded7fa7a6c169/chtMultiRegionTestCasesImplicitBug.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?
Energy-Mismatch. It seems that the `implicit` somehow adds some sink term which reduces the temperature in the regions.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Having the same results for both, the standard and implicit case.
<!-- What you should see instead -->
### Relevant logs and/or images
![comparison](/uploads/6b6d2d8341c3735ee6e6c460ce058c31/comparison.png)
<!--
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 : Ubuntu 20.04
- Hardware info : Not interesting
- Compiler : Gcc v 9.4
### 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/1813compressibleInterFoam: unphysical oscillations in transonic flows2020-11-10T17:34:53ZMartin HeinrichcompressibleInterFoam: unphysical oscillations in transonic flows### Summary
compressibleInterFoam produces unrealistic oscillations for transonic flow simulations. This can be demonstrated using a simple shockTube tutorial case. Interestingly, this problem was not present prior to OpenFOAM 5.0.
###...### Summary
compressibleInterFoam produces unrealistic oscillations for transonic flow simulations. This can be demonstrated using a simple shockTube tutorial case. Interestingly, this problem was not present prior to OpenFOAM 5.0.
### Steps to reproduce
Use the shockTube tutorial case of rhoCentralFoam and solve it with compressibleInterFoam with OpenFOAM v2006
### Example case
I have attached the shockTube tutorial case set up for compressibleInterFoam and for comparison also the case for rhoPimpleFoam with OpenFOAM v2006 [summary.zip](/uploads/f912e1f72bfd05fd7edd866bc4417c04/summary.zip). The solution for rhoPimpleFoam matches quite well with rhoCentralFoam. However, compressibleInterFoam is quite far off and oscillates strongly between x = 2 and x = 4. This happens for all OpenFOAM versions starting with 5.0, including the latest v2006. However, it does not happen in OpenFOAM 4.x and earlier.
![shockTube](/uploads/fae665ca0e06cef72810a3349011f4b6/shockTube.png)
### Environment information
- OpenFOAM version : v2006
- Operating system : Debian 10
- Hardware info :
- Compiler : gcc 9.1
### Possible fixes
This problem started somewhere around [commit e8daaa5c767ac9731fb7ec3259043a4aae5ae972](https://github.com/OpenFOAM/OpenFOAM-5.x/commit/e8daaa5c767ac9731fb7ec3259043a4aae5ae972) in OpenFOAM 5.x. Prior to that (for example OpenFOAM 4.x), the results agree quite well with rhoCentralFoam and rhoPimpleFoam.https://develop.openfoam.com/Development/openfoam/-/issues/2731Clarification on Lambda2 function object2023-09-29T12:54:35ZYannClarification on Lambda2 function object### Functionality to add/problem to solve
The description of the Lambda2 function object states:
> The Lambda2 function object computes the second largest eigenvalue of the sum of the square of the symmetrical and anti-symmetrical par...### Functionality to add/problem to solve
The description of the Lambda2 function object states:
> The Lambda2 function object computes the second largest eigenvalue of the sum of the square of the symmetrical and anti-symmetrical parts of the velocity gradient tensor.
But it seems the function actually computes the opposite value: -Lambda2
`return store
(
resultName_,
-eigenValues(SSplusWW)().component(vector::Y)
);`
This is a bit confusing, since negative Lambda2 values are supposed to indicate vortex cores while in OpenFOAM you need to look for positive values to get vortex cores.
### Target audience
Anyone using Lambda2 to visualize vortex structures
### Proposal
Two possible solutions:
1. writing the actual Lambda2 rather than -Lambda2
2. updating the function description to clearly mention the opposite value of Lambda2 is written
I don't really have a preference between these solutions, as long as the description matches the code to avoid misleading users.
### Links / references
This old thread put me on track: https://www.cfd-online.com/Forums/openfoam-post-processing/117005-lambda2-openfoam-utilities.htmlKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2642Incorrect algorithm in void Foam::fvMatrix<Type>::setValuesFromList2023-01-18T11:47:48ZZhao WuIncorrect algorithm in void Foam::fvMatrix<Type>::setValuesFromList<!--
*** 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
Incorrect algorithm in `void Foam::fvMatrix<Type>::setValuesFromList` in file [src/finiteVolume/fvMatrices/fvMatrix/fvMatrix.C:L226](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/finiteVolume/fvMatrices/fvMatrix/fvMatrix.C#L226)
<!-- Summarize the bug encountered concisely -->
### What is the current *bug* behaviour?
within Loop `forAll(cellLabels, i)`, the source_ is first set by `source_[celli] = value*Diag[celli];`.
Then the value of `source_[nei[facei]]` is immediatly changed by the `-=` operator.
However, `nei[face]` might be behind `celli`, therefore this modification might be overwritten by the upcoming celli loop.
<!-- What actually happens -->
### What is the expected *correct* behavior?
I think we should split the single loop `forAll(cellLabels, i)` into two.
The first loop is to set the initial value of `psi` and `source_`, and the second loop is to do the `-=` operation.
<!-- 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 : 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 : all versions
- Operating system : N/A
- Hardware info : N/A
- Compiler : N/A
### 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
-->
```cpp
forAll(cellLabels, i)
{
const label celli = cellLabels[i];
const Type& value = values[i];
psi[celli] = value;
source_[celli] = value*Diag[celli];
}
forAll(cellLabels, i)
{
const label celli = cellLabels[i];
const Type& value = values[i];
if (symmetric() || asymmetric())
{
...
}
}
```https://develop.openfoam.com/Development/openfoam/-/issues/2577maxIter with PPCR,PPCG not working in parallel2022-09-07T14:33:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commaxIter with PPCR,PPCG not working in parallel<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
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 -->
Sometimes using coarsest level inside GAMG with PPCR or PPCG in combination with maxIter gives a crash. Issue seems to be the combination of
- maxIter
- parallel running
- PPCR,PPCG (i.e. any linear solver using non-blocking reductions)
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Set up pressure solver to use PPCR or PPCG. Set maxIter to a very low level, e.g. 1. Run parallel.
### 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?
Crashes with `stack-smashing' error on some machines.
<!-- 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 : 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 : any version with PPCR,PPCG
### 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
-->
Make sure to clean up outstanding non-blocking request before exiting the solver loop inside PPCR,PPCG. This happens for 'normal' exits (convergence reached) but not for `maxIter` exits.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2500Linear solver residual tolerances should not always be normalized2022-11-17T15:36:59ZCarsten ThorenzLinear solver residual tolerances should not always be normalized### Functionality to add/problem to solve
In the implementation of the linear solvers, the calculated L2-norm (?) of the residual vector is compared to user supplied absolute and relative tolerances. In the code, before comparison, the ...### Functionality to add/problem to solve
In the implementation of the linear solvers, the calculated L2-norm (?) of the residual vector is compared to user supplied absolute and relative tolerances. In the code, before comparison, the calculated residual is normalized with an estimate of the scale of the problem, which is computed from an initial guess for the solution and the RHS of the equation system. Actually, this turns the "absolute" tolerance into some kind of relative tolerance.
This is helpful (though misleading), if the expected absolute values of the residuals are unknown to the user. It is a disadvantage, if the expected absolute errors are known.
Thus it is proposed to optionally switch of the normalization of the residuals. A proposed patch is attached.
IMHO, the current specification of a tolerance and a relTol in the solver dictionary is weird, because actually both tolerances are compared to normalized residuals in the code. One by some properties of the equation system, the other by the initial residual. The treatment in the code "looks" different, but actually both variants are normalizations. But cleaning this up would require larger changes in the linear solvers, that I didn't want to tackle.
### Target audience
If the expected residuals and tolerances are well known, it is beneficial to use absolute tolerances for the solvers and not normalized ones, because it enhances the performance. Example: Transient tracer transport. In a simulation period with no or few tracer in the system, in the current implementation the normalization factor is near zero. Thus, the normalization of the residuals with "near zero" results in excessive iterations to reach the tolerance. The acquired accuracy is gained at high cost and might be unnecessary, if later in the transient development, at a much higher level of tracer concentrations, the interesting things happen.
### Proposal
Make the normalization of residuals a user choice. The proposed patch is an enhancement in lduMatrix::solver::normFactor . A user specified "residualNormalization" can then be added to the solver dictionary. If omitted, the old behaviour is retained. If set to "none", the normalization method returns "1", i.e. normalization is switched off. The currently implemented method is also available as axbScaling". For future use, other choices can easily be added.
### What does success look like, and how can we measure that?
Problem: The necessary effort (i.e. iterations) for the linear solvers should depend on the dynamics of the physical processes. The current normalization hinders that.
Example:
Unzip the example and run scalarTransportFoam. It is a simple example for a tracer transport, with a tracer injection starting at t=0.1 s. In the time < 0.1 s, only the initial value of tracer is in the system (very small) and is unchanged. Thus the solver should spend minimal effort. In the current implementation, the first initial residual is rescaled to 1 and unexplicably drops until t=0.1 s. The linear solver spends 5-8 unnecessary iterations in each time step. This is unwanted. After the tracer injection started, the number of iterations stays in the same range, while it should be higher then.
With the patch: Uncomment "residualNormalization" in system/fvSolution/solvers and re-run scalarTransportFoam.
Result: The solver spends zero iterations before the injection starts, because the initial residual are very low. After injection (t=0.1s), the iterations increase.
### Links / references
Example:
[o2112_example_scalarTransportFoam.zip](/uploads/dc6ab6eff55251eae6a76053b5a2517c/o2112_example_scalarTransportFoam.zip)
Patches:
[o2112_patches.zip](/uploads/6b0df79bd3107781b4b56ec62d53b6f6/o2112_patches.zip)
### Funding
The requested functionality has been implemented and tested. Both are attached (see above).
The diff of lduMatrixSolver.C is here:
[diff.txt](/uploads/d9e1075ca5bac7253409594edbe3ca44/diff.txt)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2304mixture density error perfectGas reactingTwoPhaseEulerFoam2022-05-06T09:31:08ZHans Skarsvågmixture density error perfectGas reactingTwoPhaseEulerFoamCalculating the density of a mixture of 2 components with different moleweights give wrong density from perfectGas equation of state. Error appears in v2012 and v2106, but not in v1912. Attached case with gas mixture of water (steam) and...Calculating the density of a mixture of 2 components with different moleweights give wrong density from perfectGas equation of state. Error appears in v2012 and v2106, but not in v1912. Attached case with gas mixture of water (steam) and air prints (T.gas p water.gas thermo:rho.gas air.gas) to postprocessing file. The density should be rho = 1/(Y1/rho1 + Y2/rho2), with Yi being the mass fraction of component i and rhoi = p/(8.31447*T/wi) where wi is the composition moleweight. For v2012 and v2106 the density is erroneously calculated with mass fractions replaced by mole fractions Yi -> Xi = Yi/wi/sum(Yj/wj). Attached case is for reactingTwoPhaseEulerFoam, but same bug has been observed in reactingFoam with 2 components.
[density_perfectGas.zip](/uploads/11fa5445d27b746e01168fd6e8336a1e/density_perfectGas.zip)https://develop.openfoam.com/Development/openfoam/-/issues/2294Application of Implicit treatment of coupled boundary conditions to heat exch...2021-12-14T10:26:09ZLuca CornoltiApplication of Implicit treatment of coupled boundary conditions to heat exchange### Summary
The problem is related to the newly developed implicit treatment of mapped boundary condition (for next release 2112). In particular, the issue appears when the implicit treatment is applied to solve the temperature field at...### Summary
The problem is related to the newly developed implicit treatment of mapped boundary condition (for next release 2112). In particular, the issue appears when the implicit treatment is applied to solve the temperature field at the interface of fluid and solid regions with the chtMultiRegionSimpleFoam solver.
### Steps to reproduce
Use the chtMultiRegionSimpleFoam solver to run, on a single processor, the attached case with the flag "useImplicit" set to true or false for interface patches named "fluid_higher_to_solid" and "fluid_lower_to_solid" for the fluid and the corresponding patches "solid_to_fluid_higher" and "solid_to_fluid_lower" in the solid region to reproduce the explicit and implicit solutions.
### Example case
Attached ([test_parallelPlates.tar](/uploads/3bddea413717060c8226fe27fd8b664e/test_parallelPlates.tar)) you can find a rectangular case with two fluid regions and a solid region in between. They schematized two consecutive channels of a counter-flow compact heat exchanger. In the upper fluid region named "fluid_higher" the cold flow is heated by the hot flow flowing in the lower fluid region named "fluid_lower". The solid region named "solid" represents the heat exchanger. This test case was originally developed to check some user code implementation but, in the reported tests, only standard libraries are employed.
### What is the current *bug* behaviour?
The results of the temperature field with the explicit treatment are correct, while the same setup with the implicit treatment gives nonphysical values.
### What is the expected *correct* behavior?
For a steady state case, after enough iterations, the results of implicit and explicit treatments setups should be the same.
### Relevant logs and/or images
Scheme of the testes configuration.
![System_description](/uploads/2fa3c940a34c1ba9d36f2ae1df6eadf9/System_description.PNG)
Comparison of the mas averaged outlet temperature of the heated cold flow with different setups/solver of different version:
![outletTemperature](/uploads/a8fd549043dabc4d6a2e80a38ed545f4/outletTemperature.png)
Computed Temperature fields:
| Explicit treatment | Implicit treatment |
| ------ | ------ |
| ![TemperatureField_explicit](/uploads/8f01a1aa89554bad51c20a010356684a/TemperatureField_explicit.png) | ![TemperatureField_implicit](/uploads/7a4358a711581b2b15dc32221030f897/TemperatureField_implicit.png) |
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : development (next release 2112)
- Operating system : Mint 19.1 Cinammon
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2267turbulentDigitalFilterInlet makes pattern of the turbulent structures running...2022-06-07T20:16:58ZFlavio GaleazzoturbulentDigitalFilterInlet makes pattern of the turbulent structures running in parallel<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
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 -->
turbulentDigitalFilterInlet makes a pattern of the turbulent structures which follow the partitioning of the domain decomposition using DFM and FSM modes.
### Steps to reproduce
1. Using the tutorial
<!-- How one can reproduce the issue - this is very important -->
```
cp -r $FOAM_TUTORIALS/tutorials/verificationAndValidation/turbulentInflow/oneCellThickPlaneChannel .
```
2. Run in serial mode
```
vi Allrun
# flag to enable computations in parallel mode
parallel=false
```
3. Plot the resulting velocity field magnitude using Paraview
4. Change the number of processors to 9, and change the partition method to serial with 3x3 partitions in y and z directions
```
vi setups.orig/common/system/decomposeParDict
numberOfSubdomains 9;
method simple;
simpleCoeffs
{
n (1 3 3);
}
```
5. Run for only one time-step, as the partitioning makes the simulation unstable.
```
vi setups.orig/common/system/controlDict
stopAt writeNow;
```
6. Run in parallel mode
```
mv results results_serial
vi Allrun
# flag to enable computations in parallel mode
parallel=true
```
6. Plot the resulting velocity field magnitude using Paraview
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
See above
### What is the current *bug* behaviour?
<!-- What actually happens -->
The results when running in parallel or serial modes is different using DFM and FSM. A pattern of the turbulent structures follows the partitioning of the domain decomposition.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The results when running in parallel or serial modes is the same. Using DFSEM this behavior is seen.
### 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.
-->
![Screenshot_DFM_serial](/uploads/97a506d42fabf783de1a77042b75dbe8/Screenshot_DFM_serial.png)
![Screenshot_DFM_parallel](/uploads/ba14dcd7583ac4776204dacdb13421e0/Screenshot_DFM_parallel.png)
Visible pattern dividing the structures into three partitions, following the domain decomposition.
![Screenshot_FSM_serial](/uploads/a1368b56009b73990c2d3afc225d2cb8/Screenshot_FSM_serial.png)
![Screenshot_FSM_parallel](/uploads/66e3b7d15fa4c187b5bda58d67863b54/Screenshot_FSM_parallel.png)
Visible pattern dividing the structures into three partitions, following the domain decomposition.
![Screenshot_DFSEM_serial](/uploads/04b4d2ae03c1844c637eb95b51963e8a/Screenshot_DFSEM_serial.png)
![Screenshot_DFSEM_parallel](/uploads/f5752366f46b60f6e7bcc508b3135d6c/Screenshot_DFSEM_parallel.png)
No visible pattern.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
- Operating system : centos 8
- Hardware info : AMD EPYC Rome
- Compiler : GCC 9.2
### 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
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1927Possible typo in solidProperties.C variable name definition2020-11-26T01:16:19ZRobin KnowlesPossible typo in solidProperties.C variable name definition<!--
*** 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
Possible typo in the solidProperties.C in the `Hf` variable name
### 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 : v2006
### Possible fixes
```diff
.../solidProperties/solidProperties/solidProperties.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidProperties.C b/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidPr
operties.C
index 3c12e9733f..9ae8cd1bc9 100644
--- a/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidProperties.C
+++ b/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidProperties.C
@@ -77,7 +77,7 @@ void Foam::solidProperties::readIfPresent(const dictionary& dict)
dict.readIfPresent("rho", rho_);
dict.readIfPresent("Cp", Cp_);
dict.readIfPresentCompat("kappa", {{"K", 1612}}, kappa_);
- dict.readIfPresent("Hf_", Hf_);
+ dict.readIfPresent("Hf", Hf_);
dict.readIfPresent("emissivity", emissivity_);
dict.readIfPresent("W", W_);
}
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1885foamNewBC incorrect for Function1 member data2020-10-24T09:01:27ZHåkanfoamNewBC incorrect for Function1 member data<!--
*** 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
foamNewBC incorrect for Function1 member data. It is not possible to compile the default output.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
foamNewBC -f -v XYZ
wmake XYZ
<!-- How one can reproduce the issue - this is very important -->
### Example case
N/A
<!--
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?
Compilation fails
<!-- What actually happens -->
### What is the expected *correct* behavior?
It should compile, so that the user gets a good example from the script.
<!-- 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 : v2006
- Operating system : Ubuntu 20.04
- 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
-->
In last three constructors in the initialization (XYZ...C), it should be corrected to (from translatingWallVelocityFvPatchVectorField.C):
timeVsData_(ptf.timeVsData_.clone()),Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1862blockMesh does not work for wedge meshes2021-12-10T13:18:40ZHåkanblockMesh does not work for wedge meshes<!--
*** 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 -->
Cells at axis of wedge meshes are hexahedra after running blockMesh. They should be prisms. This makes e.g. curl(volVectorField) break.
I.e. blockMesh does not understand that if a side of a block is collapsed, the faces of that side should also be collapsed, so that the cells will be prisms.
This has worked correctly in all other versions.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run blockMesh and then checkMesh on tutorial pimpleFoam/laminar/movingCone. There should be a number of prism cells.
### 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
-->
Tutorial pimpleFoam/laminar/movingCone
### What is the current *bug* behaviour?
<!-- What actually happens -->
See above
### What is the expected *correct* behavior?
<!-- What you should see instead -->
See above
### 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.
-->
Present log from checkMesh:
```
Overall number of cells of each type:
hexahedra: 1900
prisms: 0
***Total number of faces on empty patches is not divisible by the number of cells in the mesh. Hence this mesh is not 1D or 2D.
***Zero or negative face area detected. Minimum area: 0
***Max skewness = 1.22226e+146, 35 highly skew faces detected which may impair the quality of the results
<<Writing 35 skew faces to set skewFaces
```
Correct log from checkMesh:
```
Overall number of cells of each type:
hexahedra: 1865
prisms: 35
```
### Environment information
OpenFOAM version : v2006
Operating system : ubuntu
Hardware info :
Compiler : gcc (default)
git rev-parse --short HEAD:
6461eec886
### 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 movingCone tutorial works only because the empty condition is set on the 35 faces with zero area, but that is not how it should be done. There should not be any faces on that patch.https://develop.openfoam.com/Development/openfoam/-/issues/1859Force calculation depends on number of ranks2024-01-11T18:14:19ZDavidForce calculation depends on number of ranksWe currently face an issue with the force functionObject: depending on the total number of ranks in parallel runs the obtained forces differ.
We use `pimpleFoam` in combination with dynamic meshes to perform our simulations. The issue a...We currently face an issue with the force functionObject: depending on the total number of ranks in parallel runs the obtained forces differ.
We use `pimpleFoam` in combination with dynamic meshes to perform our simulations. The issue appeared originally in a rather complex application case and the best guess for the rank dependency there was the FV mesh motion solver itself. The behavior can be reproduced using the tutorial case `movingCone` of the latest release v2006. The tutorial includes a uniform mesh motion in x-direction, which is solved by the `velocityComponentLaplacian` solver of the `dynamicMotionSolverFvMesh` dynamic mesh. The force is evaluated at the moving interface with the `libforces.so` library, as usual. Since `wedge` type patches cannot be partitioned as expected with the latest OpenFOAM version, the out-of-plane patches have been switched from type `wedge` to the type `patch`.
We performed the simulation on a various number of ranks and looked at the resulting force at the moving interface. Comparing a serial run with a simulation on 5 x 5 = 25 ranks shows on the first time level a deviation around O(10^{-5}). At the final time level 3e-3s, a deviation of around O(10^{-6}) can be observed. Both measures are absolute deviations, so that the accuracy is clearly below machine accuracy. The force diff for all time steps is also attached `diff_serial_25_procs.log`.
[diff_serial_25_procs.log](/uploads/bee9f77b954044c5b458aee5375098c6/diff_serial_25_procs.log)
In a second step, the mesh movement has been removed. Since the non-zero fluid velocity is entirely triggered by the moving obstacle, a uniform inlet flow velocity of strength 1 is placed on the left side and an outlet is placed on the right side of the domain. Again, the force for a serial run and a 5 x 5 = 25 rank parallel run is considered. The deviation of the calculated force values is initially around O(10^{-6}) and at the final time level around O(10^{-9}). Thus, the differences do not disappear in case the mesh motion is deactivated. The complete log is also attached `diff_serial_25_procs_no_motion.log`.
[diff_serial_25_procs_no_motion.log](/uploads/baf0046cec48522b11295f4588df53e1/diff_serial_25_procs_no_motion.log)
I'm a bit puzzled about the reason. Although the attached log files contain only the `force.dat` file comparison, I also checked the console output for more than the default write precision in order to exclude round-off errors while creating the `force.dat` file. Also, selecting very (too) strict residual controls doesn't affect the observed differences.
Are there any hints for these differences?
Background:
We are performing black-box coupled FSI simulations with OpenFOAM using the [openfoam-adapter](https://github.com/precice/openfoam-adapter) and these differences can lead to severe differences for coupled simulations so that the entire coupled system converges to different states. In contrast to the tutorial setup, as described above, our original problem setup applies the displacement based FV mesh motion solver with time varying boundary conditions.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1823interCondensatingEvaporatingFoam: wrong temperature field inside vapour in ph...2021-07-08T20:32:29ZSebastian BorrmanninterCondensatingEvaporatingFoam: wrong temperature field inside vapour in phase-transition region near interface<!--
*** 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
I initialized a vapor-bubble inside a rectangular liquid domain and set the heat conduction in the vapor to 0 (in order to visualize the problem). The condensation and evaporation coefficients are set to 0. The top wall is hot and the bottom wall cold, gravity is off. A temperature gradient emerges in the liquid as expected.
The wrong behavior occurs in the vapor-bubble near the interface, in the alpha-transition region, where 0 < alpha < 1. The temperature gradient that should only be present in the liquid phase also travels into this transition-region inside the vapor-phase (note that it is not smeared according to alpha in this region, but continued from the liquid) I discussed this problem with colleagues and we couldn't find a physical reason for this behavior. It seams that the temperature-field inside the vapor is only correct if alpha is exactly 0 (or at least smaller than 1e-8).
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Run the attached testcase (Allrun), look at the alpha- and temperature-field in paraview and compare their size.
<!-- How one can reproduce the issue - this is very important -->
### Example case
[bugreport.tar.gz](/uploads/eeff365fc1b69b64c7e90888464536c9/bugreport.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?
The temperature-field of the surrounding field is present in the alpha-transition region inside the bubble near the interface.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The temperature should be constant everywhere in the bubble, due to heat conduction kappa = 0.
<!-- What you should see instead -->
### Relevant logs and/or images
![camparison](/uploads/adcc705a6dfd4cb5052fe553a860acc5/camparison.png "Temperature-field (left) and alpha-field (right)")
Temperature-field (left) and alpha-field (right)
![temperatureInAlphaClip05](/uploads/623224fc46a9de86cedce5b0a9b713b8/temperatureInAlphaClip05.png "Temperature field inside the bubble (clipped with alpha = 0.5)")
Temperature field inside the bubble (clipped with alpha = 0.5)
<!--
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 : tested in v1912 (fixed version with interface.correct()) and v2006
- Operating system : debian
- Hardware info :
- Compiler : gcc
### Possible fixes
Didn't find one yet.
<!--
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
-->v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1671handle Fujitsu compiler2022-08-17T07:54:12ZMark OLESENhandle Fujitsu compilerIssue raised as a [github spack issue](https://github.com/spack/spack/pull/15941).
From the changes, the Fujitsu compiler seems to be a pure clang derivative.
If so, we might try something like the following:
```
WM_COMPILER=Clang10Fuji...Issue raised as a [github spack issue](https://github.com/spack/spack/pull/15941).
From the changes, the Fujitsu compiler seems to be a pure clang derivative.
If so, we might try something like the following:
```
WM_COMPILER=Clang10Fujitsu
```
Within the rules setup, the compiler-family is determined by stripping out numbers etc
(this could be modified to look nicer).
```
COMPILER_FAMILY = $(shell echo "$(WM_COMPILER)" | sed -e 's/[0-9].*//')
```
Within the `rules/linuxARM64Clang/general` we could then add in some custom handling. For example,
```
# Override compiler calls for fujitsu compiler
ifneq (,$(findstring jitsu,$(WM_COMPILER)))
cc = fjclang
CC = fjclang++-10 -std=c++11
endif
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1664Could not load dynamic library such as "fieldFunctionObjects" on macOS2023-05-31T11:06:38ZShigeki FujiiCould not load dynamic library such as "fieldFunctionObjects" on macOS<!--
*** 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 one application (use dynamic library) execute, it could not load this library on macOS.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
In the directory of "tutorials/incompressible/icoFoam/cavityMappingTest",
execute the script of "Allrun".
### 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
-->
`% ./Allrun
Running blockMesh on /opt/OpenFOAM/OpenFOAM-v1912/tutorials/incompressible/icoFoam/cavityMappingTest
Running blockMesh on /opt/OpenFOAM/OpenFOAM-v1912/tutorials/incompressible/icoFoam/cavityMappingTest
Running icoFoam on /opt/OpenFOAM/OpenFOAM-v1912/tutorials/incompressible/icoFoam/cavityMappingTest`
### What is the current *bug* behaviour?
<!-- What actually happens -->
In the file of "log.icoFoam", there is the following message.
`--> FOAM Warning :
From function void *Foam::dlLibraryTable::openLibrary(const Foam::fileName &, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 65
Could not load "fieldFunctionObjects"
dlopen(libfieldFunctionObjects.dylib, 9): image not found`
### What is the expected *correct* behavior?
<!-- What you should see instead -->
There is no warning.
### 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 : v1912
- Operating system : macOS 10.15.4
- Hardware info : MacBook Pro
- Compiler : Apple clang version 11.0.3 (clang-1103.0.32.29)
### 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
-->
When SPI(System Integrity Protection) is enabled, we can not use the environment value of DYLD_LIBRARY_PATH. So another environment value is introduced and it used before call dlopen(). it is patch for this.
[dl-search-paths.patch](/uploads/6d78336585c7094774f856c4d0634dfe/dl-search-paths.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1522Add OpenQBMM2020-02-10T15:21:01ZMark OLESENAdd OpenQBMMAs per discussions with @andy and @albertop - aim to add OpenQBMM in as a submodule for 1912.
Alberto has rejiged some bits to compile will 1906 (only some deprecation warnings for dimensionedType that can be safely ignored). I've recom...As per discussions with @andy and @albertop - aim to add OpenQBMM in as a submodule for 1912.
Alberto has rejiged some bits to compile will 1906 (only some deprecation warnings for dimensionedType that can be safely ignored). I've recompiled his branch with the 1912 develop and nothing came up with gcc-7.4.
May need to recheck with gcc-4.8.5, but probably not too bad.
As soon as we get a _mostly_ finalized branch (even better, tagged) can add the submodule.
Q: The subdirectory name as under modules/OpenQBMM, modules/open-qbmm ...? We are flexible.v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3098Dynamic linker environment variables setup on Darwin2024-03-09T18:31:27ZAlexey MatveichevDynamic linker environment variables setup on Darwin### Summary
Folder existence check was introduced on Darwin in `_foamAddLib` function. The function fails, when multiple folders separated by colon are passed as an argument. Due to this bug `FOAM_USER_LIBBIN` and `FOAM_SITE_LIBBIN` are...### Summary
Folder existence check was introduced on Darwin in `_foamAddLib` function. The function fails, when multiple folders separated by colon are passed as an argument. Due to this bug `FOAM_USER_LIBBIN` and `FOAM_SITE_LIBBIN` are not added to `DYLD_LIBRARY_PATH`.
### Steps to reproduce
1. Setup OpenFOAM(R) environment.
2. Look at `DYLD_LIBRARY_PATH`: neither `FOAM_USER_LIBBIN`, nor `FOAM_SITE_LIBBIN` are there.
### What is the current *bug* behaviour?
`FOAM_USER_LIBBIN` and `FOAM_SITE_LIBBIN` are missing from `DYLD_LIBRARY_PATH`, so user-compiled libraries are not found by dynamic linker.
### What is the expected *correct* behavior?
Libraries located in `FOAM_USER_LIBBIN` or `FOAM_SITE_LIBBIN` should be found by dynamic linker.
### Environment information
- OpenFOAM version : v2312
- Operating system : macOS
- Compiler : clang
### Possible fixes
There are two possible approaches to fix the issue.
1. Remove `-e` check from `_foamAddLib` function. I.e. change this (`etc/config.sh/functions:92`)
```sh
_foamAddLib()
{
case "$1" in (/?*)
if [ -e "$1" ]
then
export FOAM_LD_LIBRARY_PATH="${1}${FOAM_LD_LIBRARY_PATH:+:}${FOAM_LD_LIBRARY_PATH}"
export DYLD_LIBRARY_PATH="$FOAM_LD_LIBRARY_PATH"
fi
esac
}
```
to
```sh
_foamAddLib()
{
case "$1" in (/?*)
export FOAM_LD_LIBRARY_PATH="${1}${FOAM_LD_LIBRARY_PATH:+:}${FOAM_LD_LIBRARY_PATH}"
export DYLD_LIBRARY_PATH="$FOAM_LD_LIBRARY_PATH"
esac
}
```
The same should be applied to `csh` functions.
2. Do not pass multiple folders to `_foamAddLib` function, effectively splitting single function call to multiple. I.e. instead of this (`etc/config.sh/setup:233`):
```sh
_foamAddLib "$FOAM_USER_LIBBIN:$FOAM_SITE_LIBBIN"
```
use this
```sh
_foamAddLib "$FOAM_SITE_LIBBIN"
_foamAddLib "$FOAM_USER_LIBBIN" # User library folder has higher priority
```
`grep -r` in `etc` folder shows, that this line is a single invocation of `_foamAddLib` with multi-folder argument. So, maybe, this approach is easier.https://develop.openfoam.com/Development/openfoam/-/issues/3066masterUncollatedFileOperation compilation error on 23122024-01-20T15:12:18ZMatej FormanmasterUncollatedFileOperation compilation error on 2312### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int3...### compilation problem.
I have: fetched the 2312 source code from master.
I have set my etc-darwin to take most of the libs fro the system (homebrew).
Compilation run with -j -l options.
``
Opt/src/OpenFOAM/primitives/ints/int32/int32IO.o
make: *** [/Volumes/ofdisk/OpenFOAM-v2312/build/darwin64ClangDPInt32Opt/src/OpenFOAM/global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.o] Error 1
make: *** Waiting for unfinished jobs....
Done logging to 'log.darwin64ClangDPInt32Opt'
``
my prefs.sh:
`
export projectDir="/Volumes/OFdisk/OpenFOAM-v2312"
export FOAM_CONFIG_ETC=etc-darwin
export WM_COMPILER_TYPE=system
export WM_COMPILER=Clang
export WM_PRECISION_OPTION=DP
export WM_LABEL_SIZE=32
export WM_COMPILE_OPTION=Opt
export WM_MPLIB=SYSTEMOPENMPI
export SCOTCH_VERSION=scotch-system
export fftw_version=fftw-system
export boost_version=boost-system
export cgal_version=cgal-system
export SCOTCH_ARCH_PATH=/usr/local/Cellar/scotch/7.0.4 ## 6.1.1 # run brew info scotch
export FFTW_ARCH_PATH=/usr/local/Cellar/fftw/3.3.10_1
export MPI_ARCH_PATH=/usr/local/Cellar/open-mpi/4.1.5
export BOOST_ARCH_PATH=/usr/local/Cellar/boost/1.82.0_1
export CGAL_ARCH_PATH=/usr/local/Cellar/cgal/5.6
export LDFLAGS="-L/usr/local/opt/readline/lib"
export CPPFLAGS="-I/usr/local/opt/readline/include"
export CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include"
export FOAM_EXTRA_CXXFLAGS="-I/usr/local/Cellar/flex/2.6.4_2/include -DBOOST_MATH_DISABLE_FLOAT128"
export VTK_DIR="/usr/local/Cellar/vtk/9.2.5_1" # for runTimePostprocessing FO
export CMAKE_INCLUDE_PATH="/usr/local/Cellar/flex/2.6.4_2/include"
export CMAKE_LIBRARY_PATH="/usr/local/Cellar/flex/2.6.4_2/lib"
`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3044add flag to not keep comments in foamDictionary and set default behavior to k...2023-12-21T15:52:40Zfranco otaolaadd flag to not keep comments in foamDictionary and set default behavior to keep them### Functionality to add/problem to solve
foamDictionary when using -set or other flags removes all the comments. this makes almost unsable the tool as a lot of us have pieces of code commented that came from other cases and we want to k...### Functionality to add/problem to solve
foamDictionary when using -set or other flags removes all the comments. this makes almost unsable the tool as a lot of us have pieces of code commented that came from other cases and we want to keep. I would propose that the default behavior would be to keep the comments (as people could loose information) and add a flag to not keep them like -removeComments or something in that logic
### Target audience
users in general
### Proposal
detect the comments and place them in between the entries where it was before.
### What does success look like, and how can we measure that?
if we use it for transportProperties for a dictionary that looks like this:
```
transportModel Newtonian;
//[g m s K kgmol A cd]
nu 1e-05; //[0 2 -1 0 0 0 0]
//comment
//comment2
/* block
of
comment
*/
Sct 0.7; //[0 0 0 0 0 0 0]
//comment3
```
that the resulting dictionary at least look like this (with each time that there is a // a new line is created and the /* */ block comments are kept as they were):
```
transportModel Newtonian;
//[g m s K kgmol A cd]
nu 1;//[0 2 -1 0 0 0 0]
//coment
//comment2
/* block
of
comment
*/
Sct 0.7;//[0 0 0 0 0 0 0]
//comment3
```
even if the final structure is not ideal this would be a great addition to using it.