Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-07T19:05:02Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1414provide command-line library loading2023-12-07T19:05:02ZMark OLESENprovide command-line library loadingCan be useful to load additional libraries without using a system/controlDict. With foamDictionary for example, or surface conversion utilities that do not use a system/controlDict. Or to inject additional functionality. Cross-ref: EP116...Can be useful to load additional libraries without using a system/controlDict. With foamDictionary for example, or surface conversion utilities that do not use a system/controlDict. Or to inject additional functionality. Cross-ref: EP116.
@Stefan, @PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/243incorrect component order of symmTensor for some ensight output2019-12-09T22:04:13ZMark OLESENincorrect component order of symmTensor for some ensight output- affects foamToEnsightParts, sampled surfaces- affects foamToEnsightParts, sampled surfacesVersion v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/337ParaView reader module(s) need upgrade2018-05-29T05:39:49ZMark OLESENParaView reader module(s) need upgradeThe custom properties panels are derived from a `pqAutoGeneratedObjectPanel` which is not supported with paraview-5.1 and newer (http://www.paraview.org/ParaView3/Doc/Nightly/www/cxx-doc/MajorAPIChanges.html). Instead need to use a `pqPr...The custom properties panels are derived from a `pqAutoGeneratedObjectPanel` which is not supported with paraview-5.1 and newer (http://www.paraview.org/ParaView3/Doc/Nightly/www/cxx-doc/MajorAPIChanges.html). Instead need to use a `pqPropertyWidget` as outlined:
- http://www.paraview.org/Wiki/Plugin_HowTo#Adding_Customizations_for_Properties_Panel
- http://www.paraview.org/Wiki/ParaView/Properties_Panel
Need to check details about the current method of integrating.Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1452solverInfo functionObject: writeResidualFields only works for pressure and no...2021-06-09T14:37:34ZAdminsolverInfo functionObject: writeResidualFields only works for pressure and not for other fields<!--
*** 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
The problem is encountered with the functionObject 'solverInfo'.
The residuals are written as volScalarField only for p and not for other variables like e.g. U, k or omega.
### Steps to reproduce
The bug can be reproduced, for example by running the LES motorbike tutorial by adding 'U' in the fields in file "system/stabilizationSchemes" (in the original file only U is present):
residuals
{
type solverInfo;
libs ("libutilityFunctionObjects.so");
writeResidualFields true;
writeControl outputTime;
fields (p U);
}
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
The residuals are written as volScalarField only for p and not for other variables like e.g. U, k or omega. Actually, if another variables than p, e.g. k, is present in the field list it is initialized for the different patches only but the cell values are not written to the file in the corresponding time directory.
### What is the expected *correct* behavior?
The functionObject should write all listed fields as volScalarField in each cell.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v1906
- Operating system :Ubuntu 16.04
- 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
-->
\## Reattaching the author to the issue ticket: @marluc ##Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1441Flawed behaviour of cAlphas in icoReactingMultiphaseInterFoam2021-03-30T17:34:18ZAdminFlawed behaviour of cAlphas in icoReactingMultiphaseInterFoam<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The cAlphas values between two interacting phases seem to get overwritten by a third phase, which is specified, but not actually involved in the calculation.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
2 minimal examples are attached. The correct one shows the correct behavior and the wrong one shows the wrong behavior. The difference between the two cases is the following representation of the linear solvers for alpha in fvSolution.
For the wrong example:
```
"alpha.*"
{
nAlphaCorr 2;
nAlphaSubCycles 1;
cAlphas (
(solid and water) 0
(air and solid) 0
(air and water) 1
);
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-6;
relTol 0;
}
```
For the correct example:
```
"alpha.*"
{
nAlphaCorr 2;
nAlphaSubCycles 1;
cAlphas (
(solid and water) 1
(air and solid) 1
(air and water) 1
);
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-6;
relTol 0;
}
```
### 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
-->
A small case with a single sphere in a cube is provided in the correct and wrong version. Both cases are attached as described above.
[cAlphasBugCases.tar.gz](/uploads/62ee9c2faa9e01c662e296d4ada6684c/cAlphasBugCases.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The bug occurred in the solver icoReactingMultiphaseInterFoam when 3 or more phases are present (e.g. water, air and solid), even when only 2 are involved in the calculation (water and air). If the interface compression value cAlphas between the third phase (solid) and the calculated two phases (water and air) is set to 0, the interface compression between the calculated two phases (water and air) seems to become 0 as well. This results in incorrect blurring of the interface.
### What is the expected *correct* behavior?
Since cAlphas for (air and water) is 1 in both cases, the interface should behave equal and stay sharp. But it does not. The cAlphas between (air and solid) or (water and solid) changes the behavior of the interface between (air and water).
### 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.
-->
Initial:
![initial](/uploads/23090982318865fd9e7e7f7e7ffff86c/0.png)
Correct:
![correct](/uploads/74ba757cf24485b8ede282c83119bfbf/50.png)
Wrong:
![wrong](/uploads/c0d60a80f789ab3aa059cc8338b9acc8/60.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1906
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1906
- Operating system : ubuntu
- Hardware info :
- Compiler : gcc
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
I think, the cAlphas value of the two calculated phases gets overwritten by the third phase. If this is the case, it should be prevented. But I could not find where that happens in the code and I am not sure if this is the actual problem either.
## Reattaching the author to the issue ticket: @Basti ##https://develop.openfoam.com/Development/openfoam/-/issues/1277Calculated pressures change based on domain elevation using interFoam and int...2019-08-19T21:29:30ZAdminCalculated pressures change based on domain elevation using interFoam and interIsoFoam.### Summary
Calculated pressures change based on domain elevation using interFoam and interIsoFoam. As the domain is moved up in the gravity direction, pressures decrease with negative pressures forming within the water phase.
### Step...### Summary
Calculated pressures change based on domain elevation using interFoam and interIsoFoam. As the domain is moved up in the gravity direction, pressures decrease with negative pressures forming within the water phase.
### Steps to reproduce
Reproducible using weirOverflow tutorial (~/tutorials/multiphase/interFoam/RAS/weirOverflow)
Case 1:
Run weirOverflow tutorial without any changes.
Case 2:
Change the location of the weirOverflow domain by adding 500 to all Y-values in the blockMeshDict (y is the gravity direction for this tutorial).
Run both cases to 60 seconds. Create isoVolumes of the water phase (a=0.5). Color by "p" with a range -1 to 0. Case 2 will have negative pressures in the water phase near the free-surface. Comparison of pressures at bottom of water column also differ.
### Example case
Reproducible using weirOverflow tutorial (~/tutorials/multiphase/interFoam/RAS/weirOverflow)
### What is the current *bug* behaviour?
The pressures in the domain change based on the location of the domain with respect to the gravity direction.
### What is the expected *correct* behavior?
I think "p" should be independent of the domain location?
### Relevant logs and/or images
See attached for image comparing Case 1 and Case 2. Also reproduced in a different domain to further highlight the issue in attached image "Example2".
![Example1_weirOverflow](/uploads/2442f52530949ac7851815710e5e0747/Example1_weirOverflow.PNG)
![Example2](/uploads/67403ba302f755c15dcdc3a00094c041/Example2.PNG)
### Environment information
Have reproduced on 2 systems
OpenFOAM version : v1806|v1812
Operating system : ubuntu|openSUSE
Compiler : gcc|intel
### Possible fixes
Not sure....https://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/1399Suggestion for improvement of Code development guide2021-08-27T14:40:15ZJohan RoenbySuggestion for improvement of Code development guideCommunity contributors who want to fix a bug or make an improvement to OpenFOAM will often have an older compiled version of the OpenFOAM-plus develop branch on their local computer. The proper workflow for such people would (as I unders...Community contributors who want to fix a bug or make an improvement to OpenFOAM will often have an older compiled version of the OpenFOAM-plus develop branch on their local computer. The proper workflow for such people would (as I understand it) be to git pull the latest OpenFOAM-plus, recompile it and then introduce their changes in a bug-fix/feature branch derived from there.
However, if API changes have occurred since their last git pull, the recompilation will fail due to outdated dep files etc. Having to wait for a full recompilation of everything every time I wanted to contribute has been a source of frustration for me until I discovered the -u/-update flag of the Allwmake script, which removes deprecated files and directories so the updating becomes much faster.
I therefore suggest to make contributors aware of this flag in the code development guide [here](https://develop.openfoam.com/Development/OpenFOAM-plus/wikis/page-code-development).Mark OLESENMark OLESENhttps://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]);
}