Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-07T19:05:04Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1448enable 'writeControl none' inside controlDict2023-12-07T19:05:04ZPrashant Sonakarenable 'writeControl none' inside controlDict### Functionality to add/problem to solve
develop branch doesn't support 'none' as valid entry for writeControl inside controlDict. Under special situations, it might be good to have this. EP#1147
@mark### Functionality to add/problem to solve
develop branch doesn't support 'none' as valid entry for writeControl inside controlDict. Under special situations, it might be good to have this. EP#1147
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/539IOobjectList does not fail gracefully when reading invalid FoamFiles2017-08-09T14:40:19ZAdminIOobjectList does not fail gracefully when reading invalid FoamFilesIn my [case](https://github.com/petebachant/UNH-RVAT-turbinesFoam), I use a file `constant/turbulenceProperties.template` to fill/select turbulence properties at run time. This is seemingly fine for all other utilities, i.e., the correct...In my [case](https://github.com/petebachant/UNH-RVAT-turbinesFoam), I use a file `constant/turbulenceProperties.template` to fill/select turbulence properties at run time. This is seemingly fine for all other utilities, i.e., the correct file, `constant/turbulenceProperties` is read. However, when running `postProcess`, the template file is loaded. It looks like this occurs because `postProcess` reads all objects in the `constant` directory (actually, all fields regardless of `-fields` argument).
`selectedFields` should be used in the `executeFunctionObjects` function, or the list of `constantObjects` be filtered gracefully. On the other hand, maybe I'm doing something unwise by putting a template file in there that sort of looks like a dictionary.https://develop.openfoam.com/Development/openfoam/-/issues/1504maintenance-v1812 does not compile: getOrDefault is not defined2019-12-09T22:37:29ZAdminmaintenance-v1812 does not compile: getOrDefault is not definedCommit d11cfca introduced use of getOrDefault, but this in not present in version 1812.Commit d11cfca introduced use of getOrDefault, but this in not present in version 1812.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1420Writing fields with layer information makes snappyHexMesh crash in motorbike ...2020-03-13T15:14:24ZAdminWriting fields with layer information makes snappyHexMesh crash in motorbike tutorialI've noticed that starting from the v1812, snappyHexMesh crashes in the motorbike tutorial during the writing fields with layer information step:
```
Doing final balancing
---------------------
Writing 28048 added cells to cellSet adde...I've noticed that starting from the v1812, snappyHexMesh crashes in the motorbike tutorial during the writing fields with layer information step:
```
Doing final balancing
---------------------
Writing 28048 added cells to cellSet addedCells
Writing 0 faces inside added layer to faceSet layerFaces
Writing fields with layer information:
nSurfaceLayers : actual number of layers
thickness : overall layer thickness
[2] #0 [5] #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)[1] #0 Foam::error::printStack(Foam::Ostream&)[4] #0 Foam::error::printStack(Foam::Ostream&)[0] #0 [3] #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at ??:?
at ??:?
[1] #1 Foam::sigFpe::sigHandler(int)[4] #1 Foam::sigFpe::sigHandler(int) at ??:?
at ??:?
at ??:?
[2] #1 Foam::sigFpe::sigHandler(int)[5] #1 Foam::sigFpe::sigHandler(int)[0] #1 at Foam::sigFpe::sigHandler(int)??:?
[3] #1 Foam::sigFpe::sigHandler(int) at ??:?
[1] #2 ? at ??:?
[2] #2 at ???:?
[4] #2 ? at ??:?
[5] #2 ? at ??:?
[3] #2 ? at ??:?
[0] #2 ? in /lib64/libc.so.6
[1] #3 Foam::snappyLayerDriver::writeLayerData(Foam::fvMesh const&, Foam::List<int> const&, Foam::List<int> const&, Foam::Field<double> const&, Foam::Field<double> const&) const in /lib64/libc.so.6
[2] #3 Foam::snappyLayerDriver::writeLayerData(Foam::fvMesh const&, Foam::List<int> const&, Foam::List<int> const&, Foam::Field<double> const&, Foam::Field<double> const&) const in /lib64/libc.so.6
[4] #3 Foam::snappyLayerDriver::writeLayerData(Foam::fvMesh const&, Foam::List<int> const&, Foam::List<int> const&, Foam::Field<double> const&, Foam::Field<double> const&) const in /lib64/libc.so.6
[3] #3 Foam::snappyLayerDriver::writeLayerData(Foam::fvMesh const&, Foam::List<int> const&, Foam::List<int> const&, Foam::Field<double> const&, Foam::Field<double> const&) const in /lib64/libc.so.6
[0] #3 Foam::snappyLayerDriver::writeLayerData(Foam::fvMesh const&, Foam::List<int> const&, Foam::List<int> const&, Foam::Field<double> const&, Foam::Field<double> const&) const in /lib64/libc.so.6
[5] #3 Foam::snappyLayerDriver::writeLayerData(Foam::fvMesh const&, Foam::List<int> const&, Foam::List<int> const&, Foam::Field<double> const&, Foam::Field<double> const&) const at ??:?
[4] #4 Foam::snappyLayerDriver::addLayers(Foam::layerParameters const&, Foam::dictionary const&, Foam::List<int> const&, int, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[2] #4 Foam::snappyLayerDriver::addLayers(Foam::layerParameters const&, Foam::dictionary const&, Foam::List<int> const&, int, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[1] #4 Foam::snappyLayerDriver::addLayers(Foam::layerParameters const&, Foam::dictionary const&, Foam::List<int> const&, int, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[3] #4 Foam::snappyLayerDriver::addLayers(Foam::layerParameters const&, Foam::dictionary const&, Foam::List<int> const&, int, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[0] #4 Foam::snappyLayerDriver::addLayers(Foam::layerParameters const&, Foam::dictionary const&, Foam::List<int> const&, int, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[5] #4 Foam::snappyLayerDriver::addLayers(Foam::layerParameters const&, Foam::dictionary const&, Foam::List<int> const&, int, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[2] #5 Foam::snappyLayerDriver::doLayers(Foam::dictionary const&, Foam::dictionary const&, Foam::layerParameters const&, Foam::meshRefinement::FaceMergeType, bool, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[4] #5 Foam::snappyLayerDriver::doLayers(Foam::dictionary const&, Foam::dictionary const&, Foam::layerParameters const&, Foam::meshRefinement::FaceMergeType, bool, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[1] #5 Foam::snappyLayerDriver::doLayers(Foam::dictionary const&, Foam::dictionary const&, Foam::layerParameters const&, Foam::meshRefinement::FaceMergeType, bool, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[3] #5 Foam::snappyLayerDriver::doLayers(Foam::dictionary const&, Foam::dictionary const&, Foam::layerParameters const&, Foam::meshRefinement::FaceMergeType, bool, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[5] #5 Foam::snappyLayerDriver::doLayers(Foam::dictionary const&, Foam::dictionary const&, Foam::layerParameters const&, Foam::meshRefinement::FaceMergeType, bool, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[0] #5 Foam::snappyLayerDriver::doLayers(Foam::dictionary const&, Foam::dictionary const&, Foam::layerParameters const&, Foam::meshRefinement::FaceMergeType, bool, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[2] #6 at ??:?
[4] #6 at ??:?
[1] #6 ?? at ??:?
[5] #6 at ??:?
at [0] #6 ??:?
[3] #6 ? at ??:?
[2] #7 __libc_start_main?? at ??:?
[1] #7 __libc_start_main at ??:?
[4] #7 __libc_start_main in /lib64/libc.so.6
[2] #8 ? at ??:?
[0] #7 __libc_start_main at ??:?
[3] #7 __libc_start_main in /lib64/libc.so.6
[1] #8 ? in /lib64/libc.so.6
[4] #8 at ??:?
[5] #7 __libc_start_main? in /lib64/libc.so.6
[0] #8 at ??:?
? in /lib64/libc.so.6
[3] #8 in /lib64/libc.so.6
[5] #8 at ??:?
?? at ??:?
? at ??:?
at ??:?
at ??:?
```
\## Reattaching the author to the issue ticket: @Ricky-11 ##https://develop.openfoam.com/Development/openfoam/-/issues/812case fails in 17122018-05-02T11:26:40ZAdmincase fails in 1712motorbike case fails with wallBoundedstreamline FO in 1712.
Reference case is attached herewith[motorBike-wallBoundedStreamLineFO.tgz](/uploads/e5ce2ed5152fe2708e970c01260ce354/motorBike-wallBoundedStreamLineFO.tgz)motorbike case fails with wallBoundedstreamline FO in 1712.
Reference case is attached herewith[motorBike-wallBoundedStreamLineFO.tgz](/uploads/e5ce2ed5152fe2708e970c01260ce354/motorBike-wallBoundedStreamLineFO.tgz)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1455Wrong sign in equation regarding thermal creep in Maxwell boundary condition2019-10-19T18:46:20ZAdminWrong sign in equation regarding thermal creep in Maxwell boundary conditionHello.
Could you please check the sign in equation regarding thermal creep in Maxwell boundary condition?
According to the literature (for example, file colin.pdf, page 32, eq. 2.58), in the code below it should be "+=", and in code l...Hello.
Could you please check the sign in equation regarding thermal creep in Maxwell boundary condition?
According to the literature (for example, file colin.pdf, page 32, eq. 2.58), in the code below it should be "+=", and in code line in maxwellSlipUFvPatchVelocityField.C, it is "-=", as you can see.
refValue() -= 3.0*pnu/(4.0*pT)*transform(I - n*n, gradpT);
Best regards,
Darko Radenkovic
[colin.pdf](/uploads/aa8177bc46358af2611d0b4d557d7580/colin.pdf)
[maxwellSlipUFvPatchVectorField.C](/uploads/9e8e718443376c7ecdd691f930f94ac5/maxwellSlipUFvPatchVectorField.C)https://develop.openfoam.com/Development/openfoam/-/issues/48wrong version name in etc/bashrc2016-01-04T11:43:47ZMatej Formanwrong version name in etc/bashrcIn $WM_PROJECT_DIR/etc/bashrc wrong name of the version (WM_PROJECT_VERSION). Was dev-OpenCFD, should be: plusIn $WM_PROJECT_DIR/etc/bashrc wrong name of the version (WM_PROJECT_VERSION). Was dev-OpenCFD, should be: plusAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1412Inconsistency of globalIndex2019-08-30T06:04:46ZAdminInconsistency of globalIndex<!--
*** 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
I am trying to generate a list of global cellIDs "for a cellSet" using local cellIDs of a decomposed case.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Following code snip was used:
globalIndex globalNumbering(mesh.nCells());
word cellSetName = "b1";
cellSet c1(mesh, cellSetName);
labelList channelID = c1.toc();
labelList gloProc(channelID.size());
labelList locProc(channelID.size());
for(int d=0; d<channelID.size(); d++)
{
const label globalCId = globalNumbering.toGlobal(channelID[d]);
gloProc[d] = globalCId;
const label localCId = globalNumbering.toLocal(globalCId);
locProc[d] = localCId;
}
Pout << "Local Lists on all Procs " << locProc << nl;
Pout << "Global Lists on all Procs " << gloProc << nl;
<!-- How one can reproduce the issue - this is very important -->
### Example case
I have tested my code for two cases; cavity and 1D straight channel.
<!--
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?
Here, the global cellIDs generated from local match with non-decomposed cellIds (i.e, in constant/polyMesh/sets/) for only the channel case.
They do not match in any way for the cavity case.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The global cellIDs should match with those generated from local cellIDs, for any case.
<!-- 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 : v1806
- Operating system : Ubuntu 18.04
- Hardware info : Hp laptop, i7-5th gen, 4 cores
- Compiler : gcc
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Test cases:
[test_cases.tar.gz](/uploads/dee31416b6d779107c902bc5b14f0ca1/test_cases.tar.gz)
Solver used:
[testIco.tar.gz](/uploads/8f3120bba9631f18f4f47a65081663c7/testIco.tar.gz)https://develop.openfoam.com/Development/openfoam/-/issues/1272adjustTimeStep/writeInterval conflict2021-07-06T15:32:23ZAdminadjustTimeStep/writeInterval conflictI'm running a very simple test case using interPhaseChangeFoam and found out that monitors written every writeInterval based on adjustableRunTime conflict with the adjustTimeStep option.
For example, if monitors are not used and a max C...I'm running a very simple test case using interPhaseChangeFoam and found out that monitors written every writeInterval based on adjustableRunTime conflict with the adjustTimeStep option.
For example, if monitors are not used and a max Courant of 0.5 is specified, the solver runs fine with a time step size of the order of 1e-4 after an initial transient regime from the specified time step size of 1e-6.
If monitors are activated with a writeInterval of 1e-3, the case runs initially fine but then the time step size drops suddenly to 1e-28.
\## Reattaching the author to the issue ticket: @Ricky\-11 ##Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/223snappyHexMesh with -region2019-12-09T22:04:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh with -regionsnappyHexMesh (since starts off from initial mesh) should support -regionsnappyHexMesh (since starts off from initial mesh) should support -regionhttps://develop.openfoam.com/Development/openfoam/-/issues/1394topoSet - grow neighbours to cellSet2023-12-07T19:05:01ZPrashant SonakartopoSet - grow neighbours to cellSet### Functionality to add/problem to solve
It might be interesting to grow the cellSet by given steps.
### Proposal
- something similar to nbrToCell in topoSet### Functionality to add/problem to solve
It might be interesting to grow the cellSet by given steps.
### Proposal
- something similar to nbrToCell in topoSetMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1424new cannot satisfy memory request2019-09-04T08:39:47ZAdminnew cannot satisfy memory request<!--
*** 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 -->
### Steps to reproduce
<!-- 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?
<!-- 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 :
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/1423thermopysical library in calculating compressibility for burned products2019-09-18T20:56:21ZAdminthermopysical library in calculating compressibility for burned products<!--
*** 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
Library in evaluating compressibility of burned products is based on the properties of reactants not on those of products, probably by typing error.
See the source code of member function psib() in lines around 612 and 627 $src/thermophysicalModels/reactionThermo/psiuReactionThermo/heheuPsiThermo.C
### Steps to reproduce
Use XiFoam solver, and run a tutorial case, e.g. moriyoshiHomogeneous. Use very different values of molecular weight for reactants and products. Use constant density for both reactants and products. Compare the calculated burned density by the code and your input. You will notice they are different. Since the burned density (or psib() ) is recalcualted based on the molecular weight of reactants.
### Example case
Run tutorial moriyoshiHomogeneous, but change the molecualr weight of reactants and products to be very different values since the tuturial uses very similar values in constant/thermopysicalProperties.
### What is the current *bug* behaviour?
You will notice, the burned density is calculated based on the molecular wieght by reactants not by products.
### What is the expected *correct* behavior?
The burned density should be calculated based on the molecular wieght by products.
### Environment information
- OpenFOAM version :v1812
- Operating system :centos
- Hardware info :
- Compiler :gcc
### Possible fixes
The bug can be easily fixed by changing the keywords from reactants to products as follows in the file of member function psib() in $src/thermophysicalModels/reactionThermo/psiuReactionThermo/heheuPsiThermo.C as follows
forAll(psibCells, celli)
{
psibCells[celli] =
this->**cellProducts**(celli).psi(pCells[celli], TbCells[celli]);
}... forAll(ppsib, facei)
{
ppsib[facei] =
this->**patchFaceProducts**
(patchi, facei).psi(pp[facei], pTb[facei]);
}https://develop.openfoam.com/Development/openfoam/-/issues/1385Old user/developer upgrade guide page should be removed2021-07-06T16:05:44ZAdminOld user/developer upgrade guide page should be removedThe user and developer upgrade guides have migrated to the wiki, but pages for older releases and https://www.openfoam.com/documentation still point to
[the old guides](https://www.openfoam.com/documentation/developer-upgrade-guide.php)...The user and developer upgrade guides have migrated to the wiki, but pages for older releases and https://www.openfoam.com/documentation still point to
[the old guides](https://www.openfoam.com/documentation/developer-upgrade-guide.php), which give a miserable impression of not being updated. The old web-pages should probably be removed and the release pages, as well as [https://www.openfoam.com/documentation](https://www.openfoam.com/documentation) should link to the Gitlab wiki.
I think the spread of parts of documentation across the Gitlab wiki, doxygen (the extended guide), ordinary web-pages, and wiki.openfoam.com is a concern. The above is an example of associated artefacts. Is there some vision for consolidation? In Python, the Sphinx package is commonly used to parse the code like doxygen and then build additional documentation using markdown/rst. There is a C++ parser in Sphinx working on top of doxygen output. Perhaps this approach could be considered?
\## Reattaching the author to the issue ticket: @timofeymukha ##AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/951fvMeshSubSet setLargeCellSubset is ambiguous2022-04-29T15:14:48ZMark OLESENfvMeshSubSet setLargeCellSubset is ambiguousMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1460snappyHexMesh castellation phase continues refining upon multiple runs2020-03-13T13:12:50ZAdminsnappyHexMesh castellation phase continues refining upon multiple runs### Summary
Hello,
I'm not sure if this is a bug, but it is at least behavior I didn't expect.
I have some models where I'm attempting to refine parts of a blockMesh multiple times using the castellation phase of snappyHexMesh and s...### Summary
Hello,
I'm not sure if this is a bug, but it is at least behavior I didn't expect.
I have some models where I'm attempting to refine parts of a blockMesh multiple times using the castellation phase of snappyHexMesh and some geometry. I've noticed that if I run the castellation phase multiple times in a row (no changes to snappyHexMeshDict), snappy will continue finding and refining internal cells during the shell refinement phase. Upon continued runs, eventually the internal cells it finds to refine dwindles and it no longer performs refinement.
Why is additional refinement found during subsequent runs with no change in settings? I don't know if snappy was meant to be run in this way, but I was hoping to be able to do some upfront proximity refinement on certain surfaces before including all geometry to mesh and snap.
### Steps to reproduce
This can reproduced on the snappyHexMesh flange tutorial. Disable snapping in the snappyHexMeshDict. Run the allrun script, note how many cells are in the mesh, then manually run the `snappyHexMesh -overwrite` command again. You'll see that snappy found 2 extra cells to refine. Any additional runs do not refine anything further, which is what I expected to happen the first time.
I have some models though that go through multiple iterations of the above, the tutorial is just an easy example.
### Example case
snappyHexMesh flange tutorial
### What is the current *bug* behaviour?
snappy finds additional cells to refine during the castellation phase when run multiple times in a row.
### What is the expected *correct* behavior?
snappy shouldn't find additional cells to refine during the castellation phase when run multiple times in a row.
### Relevant logs and/or images
```
Shell refinement iteration 0
----------------------------
Marked for refinement due to distance to explicit features : 0 cells.
Marked for refinement due to refinement shells : 0 cells.
Determined cells to refine in = 0.12 s
Selected for internal refinement : 2 cells (out of 19314)
Edge intersection testing:
Number of edges : 66888
Number of edges to retest : 216
Number of intersected edges : 12407
Refined mesh in = 0.04 s
After refinement shell refinement iteration 0 : cells:19328 faces:66888 points:28292
Cells per refinement level:
0 0
1 1180
2 17072
3 107
```
### Environment information
- OpenFOAM version : v1906
- Operating system : RHEL
- Compiler : gcc
\## Reattaching the author to the issue ticket: @graups ##https://develop.openfoam.com/Development/openfoam/-/issues/1363surface uniformity returns vector instead of scalar.2020-03-13T14:44:13ZMark OLESENsurface uniformity returns vector instead of scalar.cross-ref EP1047
@Stefan @Prashantcross-ref EP1047
@Stefan @PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1426contact angle in icoReactingMultiphaseInterFoam2024-02-19T16:15:53ZAdmincontact angle in icoReactingMultiphaseInterFoam### Summary
<!-- Summarize the bug encountered concisely -->
While working with icoReactingmultiphaseInterFoam solver in openfoam1906, I think there is a bug in contact angle boundary condition for alpha_liquid or alpha_gas in this sol...### Summary
<!-- Summarize the bug encountered concisely -->
While working with icoReactingmultiphaseInterFoam solver in openfoam1906, I think there is a bug in contact angle boundary condition for alpha_liquid or alpha_gas in this solver. I tried all the different ways of having a contact angle of 30 or 45 degree (everything except 90 degree) with this solver, but the answer always has been the same. So I think this solver is not compatible with contact angle.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
In this post, I have attached two baseCases. One case using interFoam solver with contact angle of 30 degree and another is using icoReactingMultiphaseInterFoam with contact angle of 30 degree. The basecase is just focous on contact angle and there is no phase change on it, So I can show my point. It is a bubble in box without any force and even gravity.
### 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 results for the latter (icoReactingMultiphaseInterFoam) should be like interfoam and should show 30 degree contact angle, but when you run it with openfoam 1806 or 1812 or 1906, they won’t be and the result is like contact angle of 90 degree.In fact with this solver contact angle always is in this way and have value of 90 degree. [baseCases.zip](/uploads/2c364f2911e133fcb4203d9b22d0fb88/baseCases.zip)
### Environment information
OpenFOAM version : v1806|v1812|v1906
Operating system : ubuntu|
\## Reattaching the author to the issue ticket: @ayn ##https://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/1112XiEngineFoam/ kivaTest can not be decomposed2022-04-29T15:14:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comXiEngineFoam/ kivaTest can not be decomposedDuring decomposing the individual processors cannot find the constant directory. fileOperation::findInstance does not see the 'constant' directory (value is 0) as coming before the -180 :
```
for (instanceI = ts.size()-1; instanceI ...During decomposing the individual processors cannot find the constant directory. fileOperation::findInstance does not see the 'constant' directory (value is 0) as coming before the -180 :
```
for (instanceI = ts.size()-1; instanceI >= 0; --instanceI)
{
if (ts[instanceI].value() <= startValue)
{
break;
}
}
```
Workaround: start off with a 'normal' time directory and rename later on.