Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-01-10T19:58:42Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1073change internal dictionary separator2024-01-10T19:58:42ZMark OLESENchange internal dictionary separatorPropose for **1906**, we could adjust the internal dictionary separator from a dot (.) to a comma (,) separator.
The change in output appearance would be minimal. Eg,
```
/path/dictionary/subdict1,subdict2,entry
```
But by using a comma,...Propose for **1906**, we could adjust the internal dictionary separator from a dot (.) to a comma (,) separator.
The change in output appearance would be minimal. Eg,
```
/path/dictionary/subdict1,subdict2,entry
```
But by using a comma, which is rarely if ever used within a keyword, we could have things like this
```
file.obj
{
type xxx;
}
```
And now be able to recover the keyword `file.obj` from the dictionary dictName() method. At the moment the dictName() parses based on dot and would return `obj` instead.
@Developmentv1906Mark OLESENMark OLESEN2019-02-01https://develop.openfoam.com/Development/openfoam/-/issues/1483Singularity OpenFOAM containers2024-01-10T19:58:01ZAdminSingularity OpenFOAM containersA common issue with OpenFOAM is that due to a significant amount of forks and releases within each fork, it is rather difficult for HPC administrators to provide all the sorts of flavours of OpenFOAM out there. Typically, only a few vers...A common issue with OpenFOAM is that due to a significant amount of forks and releases within each fork, it is rather difficult for HPC administrators to provide all the sorts of flavours of OpenFOAM out there. Typically, only a few versions are installed, which can hinder adoption of new versions of the code.
A way to solve this problem would be adopting container technology, so that OpenFOAM does not actually have to be installed. OpenFOAM is already provided as Docker images, but unfortunately, Docker is not suitable for running wide MPI jobs.
A different type of container, developed to be suitable for HPC environments is Singularity.
Fortunately, one can build a Singularity container directly from Docker containers, and even pull from Dockerhub.
Thus, building Singularity containers of OpenFOAM is very easy.
On my request, the use of OpenFOAM Singularity containers has been investigated at the National Supercomputer Centre
at Linköping University, which hosts a large cluster called Tetralith.
What follows is copied from a mail I have received from the system administrator
> I have been able to get Openfoam to run within a singularity container, including MPI.
> I have documented how to do it on our webpage:
> https://www.nsc.liu.se/software/installed/tetralith/OpenFOAM/
> There is a section: How to run OpenFOAM within Singularity containers
>
> Unfortunately, it is not so trivial to get singularity images to run in parallel.
> The MPI version within the image must be exactly the same as the version installed on Tetralith Therefore you have to identify which version is used in the image and then use the same version on Tetralith.
> I installed two extra Open MPI versions on Tetralith that I found in two dirrerent openfoam versions on docker hub.
> But there is a good chance that other images use an OpenMPI version that is not available yet.
> In this case, we have to install this openmpi version ... Even if one uses the same Open MPI version, it still may not work, if the MPI in the image was configured/compiled in a very different way than the version we have on Tetralith. E.g. the version Openfoam 1812 on dockerhub works, but 1806 does not since the MPI in **the 1806 image differs from the 1812 image, even they are using the same MPI version**, but some components seem to be missing.
So, in serial the containers work out of the box (which is nice!), but for parallel computation the version of MPI and even more minor configuration settings within a single version should be matched.
What could perhaps be improved on the part of OpenFOAM developers is consistency with respect to the build environment and OpenMPI versions used within the containers for each release, and careful documentation of the configuration settings used. Also, at least version 2.1 of OpenMPI is desirable, since older ones are not fully supported by Singularity.
In the containers from OpenCFD, the versions used seem to be consistent: GCC 4.8.5 and OpenMPI 1.10.4, however, see the bold text in the quote. Also, both GCC and OpenMPI versions are quite old.
In summary
- I wanted to make the devs aware of this effort, which I hope can, upon success, make life easier for quite a lot of people.
- Consistency of settings in the images is very important. Any comment on v1806 vs v1812 regarding OpenMPI settings?
- Would it be possible to use a newer environment with OpenMPI >= 2.1 instead?
Kind regards,
Timofey
\## Reattaching the author to the issue ticket: @timofeymukha ##Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/120redistributePar utility does not write pointDisplacement field2024-01-10T17:09:51ZPawan GhildiyalredistributePar utility does not write pointDisplacement fieldredistributePar utility when used to decompose , does not write pointDisplacement field .
testcase : tutorials/multiphase/interDyMFoam/ras/DTCHullredistributePar utility when used to decompose , does not write pointDisplacement field .
testcase : tutorials/multiphase/interDyMFoam/ras/DTCHullMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1572snappyHexMesh leak detection is prone to false positives2024-01-10T16:49:17ZJustin GraupmansnappyHexMesh leak detection is prone to false positives<!--
*** 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
snappyHexMesh leak detection using the locationsOutsideMesh keyword is highly prone to false positives. In other words, a detected leak often doesn't actually cause the mesh to leak when meshed.
### Steps to reproduce
I've attached a simple model to demonstrate this issue. The model is simply a block inside of another block. The inner block has a triangle removed which snappyHexMesh detects as a leak.
On the attached model run...
* blockMesh
* snappyHexMesh -overwrite
You should get an error and a leak path is exported. Now...
* remove the locationsOutsideMesh keyword in the snappyHexMeshDict
* re-run snappyHexMesh
* Review mesh, you'll see that there is no leak into the inner box
### Example case
[boxLeakBug.zip](/uploads/48fe8be4c572aefea8a29b2dcc218453/boxLeakBug.zip)
### What is the current *bug* behaviour?
snappyHexMesh detects a leak when there isn't one.
### What is the expected *correct* behavior?
snappyHexMesh should only detect a leak if there actually is one.
### Environment information
- OpenFOAM version : v1906
- Operating system : RHEL/Windows 10
- Hardware info : Intel
- Compiler : gcc/minGW
### Possible fixes
I suspect the leak detection code is not using the same method that is used to find regions and remove cells during the castellation phase. If possible, the same walking method used to find regions and remove cells should be used to find leaks between the two points. The current method produces way too many false positives to be useful on more complex geometry.v2012https://develop.openfoam.com/Development/openfoam/-/issues/2709[Feature request] Macro expansion: Access keywords from separate files2024-01-10T16:36:52Zs1291[Feature request] Macro expansion: Access keywords from separate filesHello,
If I am not mistaken, It appears that OpenFOAM ESI versions do not provide a way to access external keywords from separate files.
OpenFOAM 9 and newer versions allow accessing keywords from separate files with the following synt...Hello,
If I am not mistaken, It appears that OpenFOAM ESI versions do not provide a way to access external keywords from separate files.
OpenFOAM 9 and newer versions allow accessing keywords from separate files with the following syntax:
```
aValue $FOAM_CASE/otherFile!foo;
```
`aValue` will have the value of `$foo` from the file `otherFile` within the case.
My workaround is to use a temporary dictionary with include to access the external keyword, e.g:
```
temp_dict
{
#include "otherFile"
}
aValue $temp_dict/foo;
#remove temp_dict
```
Is this feature already available that I am not aware of?
Thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/2224solverInfo - colon in field names2024-01-10T16:13:48ZPacific ESIsolverInfo - colon in field namesUsing a colon in the residual field names of function object solverInfo means that the files created for these fields have names that are indecipherable in Windows. For example, in a recent run, initialResidual:p became ICLAZW~C. Not a p...Using a colon in the residual field names of function object solverInfo means that the files created for these fields have names that are indecipherable in Windows. For example, in a recent run, initialResidual:p became ICLAZW~C. Not a problem in Linux where the computations were done, but it is when I want to examine the results in Windows.
The same comment will apply to field names containing colons that are created anywhere else in OpenFOAM.https://develop.openfoam.com/Development/openfoam/-/issues/3030Dead links on documentation page2024-01-10T16:12:56ZJohan RoenbyDead links on documentation pageAll pdf links are dead on https://www.openfoam.com/documentation/overviewAll pdf links are dead on https://www.openfoam.com/documentation/overviewhttps://develop.openfoam.com/Development/openfoam/-/issues/2598binModels, force etc have questionable handling of coordinate systems2024-01-10T12:57:09ZMark OLESENbinModels, force etc have questionable handling of coordinate systemsThey expect either a `CofR` entry or a `coordinateSystem` entry. If neither exist, they fallback to using `coordinateSystem(const dictionary&)` construction which then requires the following:
- origin (mandatory)
- rotation (optional)
...They expect either a `CofR` entry or a `coordinateSystem` entry. If neither exist, they fallback to using `coordinateSystem(const dictionary&)` construction which then requires the following:
- origin (mandatory)
- rotation (optional)
If `rotation` is missing, it reverts to using the e3/e1 axis specifications. If these are also missing, will fail to construct.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2521checkMesh -allTopology -allGeometry extensions2024-01-10T11:39:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh -allTopology -allGeometry extensions### Functionality to add/problem to solve
checkMesh:
- report duplicate elements in cell/face/point zones
- patch/zone manifold checking across processor boundaries
- avoid table column overflow for high number of digits (no space betwe...### Functionality to add/problem to solve
checkMesh:
- report duplicate elements in cell/face/point zones
- patch/zone manifold checking across processor boundaries
- avoid table column overflow for high number of digits (no space between volume and bounding box)
```
Checking basic cellZone addressing...
CellZone Cells Points VolumeBoundingBox
domain0 843053 972786 0.005553786145390933 (-0.01777677609419323 0.00198479132561023 -0.2625008427378372) (0.252276776117958 0.0770502 0.01250084273903893)
```https://develop.openfoam.com/Development/openfoam/-/issues/1815installation instructions for fedora 322024-01-10T11:32:04ZGhost Userinstallation instructions for fedora 32Hello,
I couldn't find any documentation on how to build openfoam2006 from source on Fedora 32. Could you please point me to the right location?
I have also tried to install it from copr (see below) but it fails:
```
$ sudo dnf copr en...Hello,
I couldn't find any documentation on how to build openfoam2006 from source on Fedora 32. Could you please point me to the right location?
I have also tried to install it from copr (see below) but it fails:
```
$ sudo dnf copr enable openfoam/openfoam
Enabling a Copr repository. Please note that this repository is not part
of the main distribution, and quality may vary.
The Fedora Project does not exercise any power over the contents of
this repository beyond the rules outlined in the Copr FAQ at
<https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr>,
and packages are not held to any quality or security level.
Please do not file bug reports about these packages in Fedora
Bugzilla. In case of problems, contact the owner of this repository.
Do you really want to enable copr.fedorainfracloud.org/openfoam/openfoam? [y/N]: y
Error: This repository does not have any builds yet so you cannot enable it now.
```
ThanksMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1904CentOS precompiled packages don't include scotch2024-01-10T11:27:31ZCristóbal TapiaCentOS precompiled packages don't include scotchHi,
I installed OpenFOAM v2006 with the instructions provided for CentOS in [1]. However, the `decomposePar` command is not working and gives the following error:
```
--> FOAM FATAL ERROR:
Attempted to use <scotch> without the scotchDe...Hi,
I installed OpenFOAM v2006 with the instructions provided for CentOS in [1]. However, the `decomposePar` command is not working and gives the following error:
```
--> FOAM FATAL ERROR:
Attempted to use <scotch> without the scotchDecomp library loaded.
This message is from the dummy scotchDecomp stub library instead.
Please install <scotch> and ensure libscotch.so is in LD_LIBRARY_PATH.
The scotchDecomp library can then be built from src/parallel/decompose/scotchDecomp.
Dynamically loading or linking this library will add <scotch> as a decomposition method.
```
Scotch is installed in the system, but I suppose that there is something else missing. Does this has to do with the "Third-Party" builds (not included in the packages?).
[1] https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/redhathttps://develop.openfoam.com/Development/openfoam/-/issues/2518Changes or information for FreeBSD port2024-01-10T11:25:00ZYuri ZChanges or information for FreeBSD port```
$ source ./work/OpenFOAM-v2112/etc/bashrc
cc: error: unsupported option '--showme:link'
``````
$ source ./work/OpenFOAM-v2112/etc/bashrc
cc: error: unsupported option '--showme:link'
```https://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/2542Online documentation (user guide) sidebar broken2024-01-10T11:23:42ZChristian RohrOnline documentation (user guide) sidebar broken<!--
*** 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
The sidebar in the user guide is no longer functional. It doesn't show the headings or links to pages making it very difficult to find what you need, as you have to guess search terms. It stays collapsed listing only the main page no matter where you navigate or what you search for.
![image](/uploads/c4694e1879bc8c1e15060b9820c3898f/image.png)
### Steps to reproduce
Just go to the online [user guide](https://www.openfoam.com/documentation/guides/latest/doc/index.html) and try to navigate through.
Have reproduced on Edge, Firefox, Chrome.
### What is the expected *correct* behavior?
The sidebar should populate with the document structure as it does for the API guide. It did so up until about 2 weeks ago. Like this:
![image](/uploads/c180e7a6ffee807794506a23dc46dc20/image.png)https://develop.openfoam.com/Development/openfoam/-/issues/2549Error when cross-compile mingw on OpenSUSE2024-01-10T11:21:47ZQuang NguyenError when cross-compile mingw on OpenSUSEHi all,
When I try to cross compile OF source by using mingw on OpenSuse according to tutorial: https://develop.openfoam.com/Development/openfoam/-/wikis/building/cross-compile-mingw
But I have 2 problems:
- <mpi.h>: no such file or di...Hi all,
When I try to cross compile OF source by using mingw on OpenSuse according to tutorial: https://develop.openfoam.com/Development/openfoam/-/wikis/building/cross-compile-mingw
But I have 2 problems:
- <mpi.h>: no such file or directory
- cannot find -lmsmpi
I don't know how to solve these problem. Could you help me?
Thank you in advance!https://develop.openfoam.com/Development/openfoam/-/issues/2606CylicAMI incompatible with scaling of mesh2024-01-10T11:09:06Zfranco otaolaCylicAMI incompatible with scaling of mesh<!--
*** 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 -->
Hello,
there is a bug regarding the cyclicAMI patches to be more precise regarding the separationVector (at least I think it commes from that).
if we create a mesh that we assign a pair of cyclicAMI patches source and target, and we check the mesh, where we obtain correct AMI weights, if the we scale the mesh with transformPoints(I would guess that this behavior is the same one for the other transformations) the cyclicAMI breakes completly, even in the checkMesh output we can see that the weights are 0.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
create a mesh with snappyHexMesh
use createPatch to create two cyclicAMI patches that are linked by "transform translational;"
checkMesh to be sure that the AMI weights are correct
scale the mesh using transformPoints -scale 1000
checkMesh again, the AMI weights will explode completly
### 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?
<!-- What actually happens -->
the source cyclicAMI patch unlinks from its cyclicAMI target patch after scaling the mesh
### What is the expected *correct* behavior?
<!-- What you should see instead -->
the source and target cyclicAMI patches should stay linked even after doing a transformation of points
### 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 :2206
- Operating system :ubuntu
- 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/2628Link to source files doesn't work2024-01-10T11:06:28ZTorquil SørensenLink to source files doesn't workWhen using the documentation at https://www.openfoam.com/documentation/guides/latest/api, whenever I click on a link to a source file (*.C), I get a "file not found" web page. E.g, consider the following documentation page:
https://www....When using the documentation at https://www.openfoam.com/documentation/guides/latest/api, whenever I click on a link to a source file (*.C), I get a "file not found" web page. E.g, consider the following documentation page:
https://www.openfoam.com/documentation/guides/latest/api/semiPermeableBaffleMassFractionFvPatchScalarField_8C.html
Under "Detailed Description", there is a link "semiPermeableBaffleMassFractionFvPatchScalarField.C" to https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v2112/src/thermoTools/derivedFvPatchFields/semiPermeableBaffle/semiPermeableBaffleMassFraction/semiPermeableBaffleMassFractionFvPatchScalarField.C
But this link doesn't work. I am sent to a "404 page not found" error page.
The same happens when I click on any such link to a *.C-file on any of the documentation pages.
Thankfully, the link further up "Go to the source code of this file" does work.https://develop.openfoam.com/Development/openfoam/-/issues/2510sphereDrop tutorial does not run to the end2024-01-10T11:02:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsphereDrop tutorial does not run to the end<!--
*** 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 -->
sphereDrop tutorial does not run far with layer addition.
Smaller issues:
- runs with PCG on pcorr but GAMG on p_rgh
- runs pcorr to unnecessary tight tolerance?
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Change end time on sphereDrop tutorial to 0.7 instead of 0.07.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Case diverges at some point - alpha max gets above 1.
### 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.
-->
At around time 0.1992 the deltaT goes from e-5 to e-6 due to the Courant number. After that it starts getting lower and lower (assume velocity goes up - not checked). I've tried with 4 outer correctors but that didn't help.
### 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 : v2206https://develop.openfoam.com/Development/openfoam/-/issues/2515All species from phase are losing mass on interfaceCompositionPhaseChangeMult...2024-01-10T10:59:47ZCássio AzevedoAll species from phase are losing mass on interfaceCompositionPhaseChangeMultiphaseSystemAll species from biomass (particles) are "evaporated" (fibras.particles and H2O.particles into H2O.gas) simultaneusly insted of only H2O.particles.
I'm using the multiphaseEulerFoam solver in Openfoam8.
[phaseProperties](/uploads/89089...All species from biomass (particles) are "evaporated" (fibras.particles and H2O.particles into H2O.gas) simultaneusly insted of only H2O.particles.
I'm using the multiphaseEulerFoam solver in Openfoam8.
[phaseProperties](/uploads/89089d5861aa7a52029f1d704b6551ee/phaseProperties)
[thermophysicalProperties.gas](/uploads/b48930324b73cf847474e519389b6525/thermophysicalProperties.gas)
[thermophysicalProperties.particles](/uploads/cdde465e7fda4d865b522c094d93695c/thermophysicalProperties.particles)https://develop.openfoam.com/Development/openfoam/-/issues/2058Windows OpenFOAM version not writing field files with name including ":"2024-01-10T10:58:10ZSandeepWindows OpenFOAM version not writing field files with name including ":"<!--
*** 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###
Field file names with ":" are not written in result folders
### Steps to reproduce
Run any simulation on windows with proudmanAcousticPower function object.
### Example case
Please check attached zip file as example for same
### What is the current *bug* behaviour?
It writes empty field file with name "proudmanAcousticPower", with 0kb size
### What is the expected *correct* behavior?
It should write two files "proudmanAcousticPower:L_P" and "proudmanAcousticPower:P_A"
### 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.
-->[proudmanAcousticPower.zip](/uploads/33bad9f2537c121066bd2339479115ae/proudmanAcousticPower.zip)
### 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 : OpenFOAM-v2012
- Operating system : Windows
- 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
-->Pawan GhildiyalPawan Ghildiyal