Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-08-31T20:46:08Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1368Binary option for vtk surface format2019-08-31T20:46:08ZAdminBinary option for vtk surface formatIn my understanding, there is no option to write surfaces from functionObjects, e.g. iso-surfaces, in a binary vtk format.
I believe this would be quite useful to reduce the size of each single file and speed up the reading in Paraview....In my understanding, there is no option to write surfaces from functionObjects, e.g. iso-surfaces, in a binary vtk format.
I believe this would be quite useful to reduce the size of each single file and speed up the reading in Paraview. For example, the iso-surface of Lambda2 in a 10M cells mesh from an external aero application is as big as 500M and it takes more than 10 seconds to be read.
Would this be possible or is there any constraint regarding the vtk format preventing this option to be implemented?
Thanks,
RiccardoMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1405typo in Descriptions of reactingEulerFoam2023-12-07T19:05:01ZAdmintypo in Descriptions of reactingEulerFoamTypos in Disctriptions of `reactingTwoPhaseEulerFoam.C:37` and `reactingMultiPhaseEulerFoam.C:34`.
`momentun` -> `momentum`Typos in Disctriptions of `reactingTwoPhaseEulerFoam.C:37` and `reactingMultiPhaseEulerFoam.C:34`.
`momentun` -> `momentum`https://develop.openfoam.com/Development/openfoam/-/issues/293STYLE: checkMesh header lists writeSets twice. Also use of both \par and \param2020-01-08T14:28:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comSTYLE: checkMesh header lists writeSets twice. Also use of both \par and \paramThere are more utilities:
(util; git grep '\\par')
(util ; git grep '\\param' )There are more utilities:
(util; git grep '\\par')
(util ; git grep '\\param' )AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/422STL ascii being detected as binary2018-05-03T18:08:12ZMark OLESENSTL ascii being detected as binaryMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1355faceZones option ignored in foamToEnsight v18062019-08-31T20:45:12ZAdminfaceZones option ignored in foamToEnsight v1806This works correctly in v1712, and v1906. But in v1806 the "faceZones" option in foamToEnsight is treated as an on/off flag rather than obeying the input.
foamToEnsight -latestTime -fields U -faceZones '(face_zone_name)' -patches '(wall...This works correctly in v1712, and v1906. But in v1806 the "faceZones" option in foamToEnsight is treated as an on/off flag rather than obeying the input.
foamToEnsight -latestTime -fields U -faceZones '(face_zone_name)' -patches '(wall_radiator)'
On any case you can run something like the above, and the ensight file will contain ALL the faceZones rather than just the listed ones. Using a list, or just naming a single faceZone, the behavior is the same.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1404correctBoundaryConditions documentation2020-03-13T13:30:55ZAdmincorrectBoundaryConditions documentationIt is difficult to know the correct usage of the GeometricField member function correctBoundaryConditions as the documentation is sparse. My understanding is that it should be called for a volume field if that field is not modified by a ...It is difficult to know the correct usage of the GeometricField member function correctBoundaryConditions as the documentation is sparse. My understanding is that it should be called for a volume field if that field is not modified by a call to a solve function but by other means such as an assignment statement. But my understanding may not be correct as I can see places in the OpenFOAM code where correctBoundaryConditions is not called despite volume variables being changed by assignments. For example, in the interPhaseChangeFoam
solver:
1) pEqn.H
near the end p_rgh is in some cases updated as
p_rgh = p - rho*gh;
2) alphaEqn.H
alpha1 is updated as
alpha1 = 0.5*alpha1 + 0.5*alpha10;
Some clarification of the correct usage of correctBoundaryConditions would be helpful. In particular, when it should be called and when not.
\## Reattaching the author to the issue ticket: @pacificesi ##Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/516foamToVTK produces illegal (binary) files2017-07-04T13:08:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToVTK produces illegal (binary) files[fineMesh.tgz](/uploads/ed96068fdeb0d2f606129fdfdf5a321b/fineMesh.tgz)
I did
- lid driven cavity
- in setSet:
cellSet c0 new labelToCell ( 10 12 5)
cellSet c1 new cellToCell c0
cellSet c1 invert
- foamToVTK -cellSet c0
- foamToVTK -cel...[fineMesh.tgz](/uploads/ed96068fdeb0d2f606129fdfdf5a321b/fineMesh.tgz)
I did
- lid driven cavity
- in setSet:
cellSet c0 new labelToCell ( 10 12 5)
cellSet c1 new cellToCell c0
cellSet c1 invert
- foamToVTK -cellSet c0
- foamToVTK -cellSet c1
and VTK/c0_0.vtk is unreadable. c1_0 is fine.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1388Interpolation scheme for electric current / heat flux2020-03-13T13:20:48ZAdminInterpolation scheme for electric current / heat flux### Functionality to add/problem to solve
An electric current is calculated as
```math
J = \sigma\cdot\nabla\varphi.
```
The gradient of the electric potential can not be calculated using the Gauss theorem with LINEAR interpolation of...### Functionality to add/problem to solve
An electric current is calculated as
```math
J = \sigma\cdot\nabla\varphi.
```
The gradient of the electric potential can not be calculated using the Gauss theorem with LINEAR interpolation of the potential . A special interpolation scheme is necessary. As described below, the potential at the face needs to be weighted by the conductivity of both cells.
![gradient](/uploads/a3f4ad605e37e98d3d0c97aaae1c5002/gradient.png)
### Target audience
The mentioned interpolation scheme is necessary for computing the gradient of
* electric potential (i.e. electric current)
* temperature (i.e. heat flux)
### What does success look like, and how can we measure that?
I use the mentioned interpolation scheme for several years. It is already validated and published.
### Links / references
Weber, N.; Beckstein, P.; Galindo, V.; Starace, M.; Weier, T.: Electro-vortex flow simulation using coupled meshes, Computers and Fluids 168(2018) 101-109
It is Eqn. 16/17 in the [Arxiv version. ](https://arxiv.org/pdf/1707.06546.pdf)
### Funding
I can provide the source code.
\## Reattaching the author to the issue ticket: @dl6tud ##Sergio FerrarisSergio Ferrarishttps://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)