Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-11-26T01:16:19Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1893Installing on Fedora 32: dnf conflicting requests - nothing provides libmpi.s...2020-11-26T01:16:19ZPhilipInstalling on Fedora 32: dnf conflicting requests - nothing provides libmpi.so.40()(64bit) needed by openfoam2006-201012-201012.fc32.x86_64This is different than the closed https://develop.openfoam.com/Development/openfoam/-/issues/1815
### Summary
<!-- Summarize the bug encountered concisely -->
dnf install openfoam2006 # FAILS! With
```
Error:
Problem: conflicting re...This is different than the closed https://develop.openfoam.com/Development/openfoam/-/issues/1815
### Summary
<!-- Summarize the bug encountered concisely -->
dnf install openfoam2006 # FAILS! With
```
Error:
Problem: conflicting requests
- nothing provides libmpi.so.40()(64bit) needed by openfoam2006-201012-201012.fc32.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
Note that libmpi.so.40 exists in /usr/lib64/openmpi/lib/
ll /usr/lib64/openmpi/lib/libmpi.so*
lrwxrwxrwx. 1 root root 17 Jun 18 11:49 /usr/lib64/openmpi/lib/libmpi.so -> libmpi.so.40.20.4
lrwxrwxrwx. 1 root root 17 Jun 18 11:49 /usr/lib64/openmpi/lib/libmpi.so.40 -> libmpi.so.40.20.4
-rwxr-xr-x. 1 root root 1169088 Jun 18 11:50 /usr/lib64/openmpi/lib/libmpi.so.40.20.4
```
### Steps to reproduce
dnf copr enable openfoam/openfoam
dnf install openfoam2006
dnf install openfoam2006 --skip-broken
### Example case
see above.
### What is the current *bug* behaviour?
<!-- What actually happens -->
```
# dnf install openfoam2006 # CFD OpenFOAM
Last metadata expiration check: 0:59:38 ago on Thu 22 Oct 2020 05:09:25 PM HKT.
Error:
Problem: conflicting requests
- nothing provides libmpi.so.40()(64bit) needed by openfoam2006-201012-201012.fc32.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
# dnf install openfoam2006 --skip-broken # CFD OpenFOAM
Last metadata expiration check: 0:51:03 ago on Thu 22 Oct 2020 05:09:25 PM HKT.
Dependencies resolved.
Problem: conflicting requests
- nothing provides libmpi.so.40()(64bit) needed by openfoam2006-201012-201012.fc32.x86_64
=============================================================================================
Package Arch Version Repository Size
=============================================================================================
Skipping packages with broken dependencies:
openfoam2006
x86_64 201012-201012.fc32 copr:copr.fedorainfracloud.org:openfoam:openfoam 83 M
Transaction Summary
=============================================================================================
Skip 1 Package
Nothing to do.
Complete!
```
### What is the expected *correct* behavior?
dnf install should complete successfully.
### 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
- OpenFOAM version : openfoam2006-common-201012-201012.fc32.noarch
- Operating system : fedora32 5.8.15-201.fc32.x86_64 #1 SMP Thu Oct 15 15:56:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
- Hardware info : x86_64
- Compiler : gccPawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/1927Possible typo in solidProperties.C variable name definition2020-11-26T01:16:19ZRobin KnowlesPossible typo in solidProperties.C variable name definition<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
Possible typo in the solidProperties.C in the `Hf` variable name
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2006
### Possible fixes
```diff
.../solidProperties/solidProperties/solidProperties.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidProperties.C b/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidPr
operties.C
index 3c12e9733f..9ae8cd1bc9 100644
--- a/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidProperties.C
+++ b/src/thermophysicalModels/thermophysicalProperties/solidProperties/solidProperties/solidProperties.C
@@ -77,7 +77,7 @@ void Foam::solidProperties::readIfPresent(const dictionary& dict)
dict.readIfPresent("rho", rho_);
dict.readIfPresent("Cp", Cp_);
dict.readIfPresentCompat("kappa", {{"K", 1612}}, kappa_);
- dict.readIfPresent("Hf_", Hf_);
+ dict.readIfPresent("Hf", Hf_);
dict.readIfPresent("emissivity", emissivity_);
dict.readIfPresent("W", W_);
}
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1933extrudeToRegionMesh generates non-uniform offsets2020-11-26T11:13:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comextrudeToRegionMesh generates non-uniform offsets### Functionality to add/problem to solve
extrudeToRegionMesh always generates non-uniform offsets due to truncation errors. This can lead to problems later on (e.g. redistributePar)
[extrudeToRegionMesh.C](/uploads/c2253795af6943515113...### Functionality to add/problem to solve
extrudeToRegionMesh always generates non-uniform offsets due to truncation errors. This can lead to problems later on (e.g. redistributePar)
[extrudeToRegionMesh.C](/uploads/c2253795af6943515113ddc2c8ce44a8/extrudeToRegionMesh.C)
### Proposal
Attached. Detect if uniformish offsets.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1757dash bug with string expansion and assignment of default values2020-11-26T13:55:23ZMark OLESENdash bug with string expansion and assignment of default valuesNoticed when compiling OpenFOAM-v2006 modules with ubuntu _bionic_ (18.04) that the module prefix is not being correctly set. Seems to be a weird bug in the `dash` shell expansions.
Starting from any non-root directory
```
echo "$PWD"
-...Noticed when compiling OpenFOAM-v2006 modules with ubuntu _bionic_ (18.04) that the module prefix is not being correctly set. Seems to be a weird bug in the `dash` shell expansions.
Starting from any non-root directory
```
echo "$PWD"
-> /home/user/openfoam/BuildEnv/scratch
```
dash 0.5.8-2.10 (bionic) shows this
```
unset test1
echo "${test1:=${PWD%/*}}"
-> /home/user/openfoam/BuildEnv/scratch <-- WHAT?? Not what we expected
```
The additional quotes cause incorrect expansion. Whereas
```
unset test1
echo ${test1:=${PWD%/*}}
-> /home/user/openfoam/BuildEnv <-- Expected
```
- bash and dash 0.5.10.2-6 (focal) work as expected, with/without quotes
- quoted expansion with `:-` works as expected.
Possible fixes?
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=48ca00863af909461d1372998bb90549f27abaaf
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=a29e9a1738a4e7040211842f3f3d90e172fa58ce
- https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=878514712c5d21f675c45d99d2f8a04098ea4a19
Possible workarounds
- use unqoted version, but risk fixing it on the next shellcheck
- explicit `if [ -z VAR ]; then ...; fi` construct
- with dirname as `: "${VAR:=$(dirname xxx)}`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1934A minus sign is missing in Lee.C of icoReactingMultiphaseInterFoam2020-11-28T03:48:10ZMamoru TamuraA minus sign is missing in Lee.C of 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 re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
I think there is a bug in Lee.C of icoReactingMultiphaseInterFoam.<BR>
The line 162 of Lee.C: `coeff*pos(Tactivate_ - refValue)` is incorrect, thus, the solidification process does not work.<BR>
A minus sign is missing. `-coeff*pos(Tactivate_ - refValue)` would be correct.
Previously, I posted a same topic at CFD online.<BR>
[https://www.cfd-online.com/Forums/openfoam-bugs/231579-bug-lee-c-icoreactingmultiphaseinterfoam.html](https://www.cfd-online.com/Forums/openfoam-bugs/231579-bug-lee-c-icoreactingmultiphaseinterfoam.html)<BR>
There, I wrote the reason why the minus sign is required.<BR>
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Try a simulation with Lee type massTransferModel.
Use parameter C < 0.
### Example case
[solidMelting2D_heating_cooling.zip](/uploads/abb06024a2b47672e894e107bc4c8107/solidMelting2D_heating_cooling.zip)<BR>
I attached the example case.
It is originally solidMelting2D tutorial.
I changed its parameters, as follows.
In system/controlDict, endTime and writeInterval were changed.<BR>
endTime 200;<BR>
writeInterval 2;<BR>
In 0/T, left and right boundaryField were changed.<BR>
The left wall heats their with 1000 W for first 50 sec.<BR>
After 50 sec, left wall cools their with -1000 W.<BR>
For right wall, the fixedValue is set.<BR>
In constant/phaseProperties, massTransferModel for a phase change from liquid to solid was add, like as,<BR>
(liquid to solid)<BR>
{<BR>
type Lee;<BR>
C -40;<BR>
Tactivate 302.78;<BR>
}<BR>
### What is the current *bug* behaviour?
<!-- What actually happens -->
![by_default_Lee](/uploads/6d02b6b52b4a01a77bf344a7ed283ba0/by_default_Lee.gif)<BR>
The figure shows alpha.solid.
First, as expected, the solid phase showed a melt.
However, in the middle of simulation (after t = 36s), the simulation failed.
### What is the expected *correct* behavior?
![by_modified_Lee](/uploads/cd9c84031451b55754da20f64e8d37ef/by_modified_Lee.gif)<BR>
This simulation was carried out by modified Lee.C.
For first 50 sec, the solid phase showed a melt.
After 50 sec, the liquid phase showed a solidification.
<!-- What you should see instead -->
### Environment information
- OpenFOAM version : v2006
- Operating system : ubuntu
- Compiler : gcc
### Possible fixes
Modify the line 162 of Lee.C, like as `-coeff*pos(Tactivate_ - refValue)` would be correct.
Best regards
<!--
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
-->Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1930Support multiple weights on some field function objects2020-11-30T14:35:30ZMark OLESENSupport multiple weights on some field function objectsRaised on EP1453, but it would also partly cover the derivedFields workaround as well. Support 0-N scalar weight fields and 0-1 vector weight fields (for surface weighting). Multiplicative weighting, with legacy handling of "none" and tr...Raised on EP1453, but it would also partly cover the derivedFields workaround as well. Support 0-N scalar weight fields and 0-1 vector weight fields (for surface weighting). Multiplicative weighting, with legacy handling of "none" and treat "rho" as unity for incompressible cases.
If implemented could have `(rho U)` weighting.v2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1942Document surfaceFieldValue update header2020-12-03T08:05:04ZMark OLESENDocument surfaceFieldValue update header#1556 added selective enable/disable of updating the header but the documentation may be lacking
Ref https://www.cfd-online.com/Forums/openfoam-post-processing/227989-postprocessing-want-stop-headers-repeating-surfacefieldvalue-dat.html#1556 added selective enable/disable of updating the header but the documentation may be lacking
Ref https://www.cfd-online.com/Forums/openfoam-post-processing/227989-postprocessing-want-stop-headers-repeating-surfacefieldvalue-dat.htmlMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1600improve handling of sampled meshed surfaces2020-12-04T07:17:19ZMark OLESENimprove handling of sampled meshed surfaces* [x] Rename starcd input files. Pending name collision between the STARCD cel/vrt/inp naming and that of ABAQUS (`.inp`).
* [x] Abaqus input for shells elements
* [x] Abaqus output for shells elements
* [x] Abaqus input of element-based...* [x] Rename starcd input files. Pending name collision between the STARCD cel/vrt/inp naming and that of ABAQUS (`.inp`).
* [x] Abaqus input for shells elements
* [x] Abaqus output for shells elements
* [x] Abaqus input of element-based surfaces
* [x] Abaqus output of element-based surfaces? Not sure how possible this is
* [x] Prevent automatic triangulation (triSurface behaviour) when reading surfaces for sampling
* [x] Preserve original surface face ids for output
* [x] Handling of surface "zones" on output might need improvement. For starcd these are the cellTableId. For nastran, a PID (property Id). For Abaqus numbers don't appear to be used, just the names, but these are currently lost during the sampling.
* [x] Allow sampling on a surface sub-region. Eg, a surface file might have many named sections, but we only want to retain a subset of those.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1900v2006 atmWallConditions produce double value entries2020-12-08T09:38:07ZMark Van Cv2006 atmWallConditions produce double value entries<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
When running a case utilizing some of the new atmBoundaryLayer wall functions (I verified this for atmOmegaWallFunction and atmNutkWallFunction but others might present the same issue), the patches defined by these functions contain double value field entries causing an error upon opening in ParaView (5.8.1 on Windows 10).
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run any case using either the atmNutkWallFunction or atmOmegaWallFunction boundary definitions.
### 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 boundary fields defined with either of these wall functions contain duplicate <value> entries, causing errors when opening the case in ParaView. In case of the atmNutkWallFunction for example:
```
boundaryField
{
bottom
{
type atmNutkWallFunction;
value nonuniform List<scalar>
19200
(
...
)
;
boundNut false;
z0 0.003;
value nonuniform List<scalar>
19200
(
...
)
;
};
```
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The value entry should be written only once per boundary patch.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2006
- Operating system : WSL 20.04 (Ubuntu 20.04 shell on Windows 10 1909)
- Hardware info : N/A
- Compiler : gcc 6.3.0
### 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
-->
[atmNutkWallFunctionFvPatchScalarField.C L201](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v2006/src/atmosphericModels/derivedFvPatchFields/wallFunctions/atmNutkWallFunction/atmNutkWallFunctionFvPatchScalarField.C#L201)
[atmOmegaWallFunctionFvPatchScalarField.C L199](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2006/src/atmosphericModels/derivedFvPatchFields/wallFunctions/atmOmegaWallFunction/atmOmegaWallFunctionFvPatchScalarField.C#L199)
A possible workaround might be to change `nutkWallFunctionFvPatchScalarField::write(os);` and `omegaWallFunctionFvPatchScalarField::write(os);` to `fvPatchField<scalar>::write(os);`.
I extracted this potential fix from [atmAlphatkWallFunctionFvPatchScalarField.C](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2006/src/atmosphericModels/derivedFvPatchFields/wallFunctions/atmAlphatkWallFunction/atmAlphatkWallFunctionFvPatchScalarField.C#L288).v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1938potential compiler issue with lemon2020-12-08T17:05:40ZMark OLESENpotential compiler issue with lemonReported as a [spack issue](https://github.com/spack/spack/issues/20120) with gcc 10.2.0
Failure with
```
lemon: lemon.c:5139: SetAdd: Assertion `e>=0 && e<size' failed.
```
This really should not happen and haven't seen it happen elsew...Reported as a [spack issue](https://github.com/spack/spack/issues/20120) with gcc 10.2.0
Failure with
```
lemon: lemon.c:5139: SetAdd: Assertion `e>=0 && e<size' failed.
```
This really should not happen and haven't seen it happen elsewhere.
Possible remedy would be to drop the optimization level for C sources in the wmake toolchain, which now only include lemon.
For example, in the wmake/src/Makefile:
```
# Locally set optimized compilation
WM_COMPILE_OPTION = Opt
GENERAL_RULES = $(WM_DIR)/rules/General
include $(GENERAL_RULES)/general
# Override -O3 with something less aggressive?
cOPT = -O2
```
Could even drop this down further since it only affects this one tool and does not affect OpenFOAM or the speed of the generated code.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1568waveModel.C fails in debug mode2020-12-10T19:25:20ZPer JørgensenwaveModel.C fails in debug mode<!--
*** 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
In debug mode a size check failing in src/waveModels/waveModel/waveModel.C
### Steps to reproduce
just run a waves tutorial in debug mode.
It fails in
const vectorField CfLocal(Rgl_ & Cf);
### Example case
e.g. the stokesV tutorial
### What is the current *bug* behaviour?
I don't know what happens and if it matters, but you can't run wave generation in debug mode.
### What is the expected *correct* behavior?
that size should be equal
### 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 :1906
- Operating system :ubuntu 1804
- Hardware info :intel i7-8700K
- Compiler :gcc 7.4
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1948BUG: First extrapolated value of the merit function is computed wrongly2020-12-11T17:37:37ZVaggelis PapoutsisBUG: First extrapolated value of the merit function is computed wrongly### Summary
In an adjoint-based optimisation, if the step value (eta) is not set explicitly, it is computed after evaluating the
directional derivative of the merit function, which, in turn, is computed
wrongly, leading to an erroneous ...### Summary
In an adjoint-based optimisation, if the step value (eta) is not set explicitly, it is computed after evaluating the
directional derivative of the merit function, which, in turn, is computed
wrongly, leading to an erroneous value of the extrapolated merit
function value.
Affects only the first optimisation cycle, if line search is enabled, so the bug should appear rather rarely.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1949BUG: globalSum needed in the directional derivative of the merit function2020-12-11T17:39:02ZVaggelis PapoutsisBUG: globalSum needed in the directional derivative of the merit function### Summary
When the derivative of the merit function is computed the global (instead of the local) sum of the objective derivative and the correction should be calculated.
This bug does not actually affect the current functionality o...### Summary
When the derivative of the merit function is computed the global (instead of the local) sum of the objective derivative and the correction should be calculated.
This bug does not actually affect the current functionality of the code since, with volumetric B-Splines, all design variables (and their derivatives and corrections) are known by all processors. It will, however, affect cases in which the design variables are distributed, like topology optimisation or when considering the movement of each boundary point as a design variable in shape optimisation.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1943Accessing field in codedSource with codeCorrect2020-12-14T14:40:37ZCarlos Peña-MonferrerAccessing field in codedSource with codeCorrectHi,
The documentation for [`codedSource`](https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1fv_1_1codedSource.html#details) mentions the following arguments:
- codeCorrect: field
- codeAddSup: eqn, fieldi
- codeCons...Hi,
The documentation for [`codedSource`](https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1fv_1_1codedSource.html#details) mentions the following arguments:
- codeCorrect: field
- codeAddSup: eqn, fieldi
- codeConstrain: eqn, fieldi
I can use `eqn` and `fieldi` from codeAddSup, however when trying to use `field` from `codeCorrect` it complains about not being declared. Is there something missing in the following code?
```
codedSource
{
type vectorCodedSource;
selectionMode all;
fields (U);
name testing;
codeCorrect
#{
vectorField& testField = field;
#};
codeAddSup
#{
vectorField& fieldSource = eqn.source();
label fieldLabel = fieldi;
#};
codeConstrain
#{
#};
}
```
Thanks.https://develop.openfoam.com/Development/openfoam/-/issues/1947BUG: problem with collated format and writing of NURBS3DVolume control points2020-12-14T18:07:05ZVaggelis PapoutsisBUG: problem with collated format and writing of NURBS3DVolume control points### Summary
adjointOptimisationFoam crashes when attempting to write the volumetric B-Splines control points into an IOdictionary when using the collated file format.
In specific, the if(Pstream::master()) clause in NURBS3DVolume::wri...### Summary
adjointOptimisationFoam crashes when attempting to write the volumetric B-Splines control points into an IOdictionary when using the collated file format.
In specific, the if(Pstream::master()) clause in NURBS3DVolume::writeCpsInDict() is
causing the fileName of the regIOobject not to be allocated in all
processors, giving problems when masterUncollatedFileOperation::masterOp
is called by collatedFileOperation::writeObject for the mkDirOp.
### Steps to reproduce
Running the case under $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/laminar/opt/unconstrained/BFGS using the collated file format gives
```
--> FOAM FATAL IO ERROR:
Bad token - could not get string
```
A serial execution gives no error.
### Possible fixes
Removing the
`if (Pstream::master())`
clause from line 1915 of NURBS3DVolume.C fixes the issue.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/354runTimePostProcessing : Error Message : when run finishes2020-12-16T10:27:02ZPawan GhildiyalrunTimePostProcessing : Error Message : when run finishesHi
Case: tutorials/incompressible/pisoFoam/LES/motorBike/motorBike
Version : OpenFOAM-dev
OS: OpenSUSE:42.1 leap
VTK: 7.1.0
OpenMPI: 1.10.4
systemGCC: 4.8.5
Issue: After finishing the run following...Hi
Case: tutorials/incompressible/pisoFoam/LES/motorBike/motorBike
Version : OpenFOAM-dev
OS: OpenSUSE:42.1 leap
VTK: 7.1.0
OpenMPI: 1.10.4
systemGCC: 4.8.5
Issue: After finishing the run following message is thrown for both single processor and for multiprocessor. However the image file is dumped in normal way and is fine .
```
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonExecutionModel-7.1.so.1: undefined symbol: _ZN33vtkFilteringInformationKeyManager13ClassFinalizeEv
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonExecutionModel-7.1.so.1: undefined symbol: _ZN33vtkFilteringInformationKeyManager13ClassFinalizeEv
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
-------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
-------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[63468,1],2]
Exit code: 127
==================================================================================================
```
https://develop.openfoam.com/Development/openfoam/-/issues/1853BUG: volFieldValue: writes empty fields2020-12-16T18:16:52ZKutalmış BerçinBUG: volFieldValue: writes empty 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 re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
`volFieldValue` FO writes empty fields when the input entry is `writeFields=true`.
It is due to the `weightField` being empty when there are no weights, which caused the entire output to be empty instead of simply being unweighted.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- Download/extract [cavity.zip](/uploads/bc44ba559eeaeb8d8f704038ab1bdf70/cavity.zip)
- ./Allrun
- Inspect `p_all` in the time directories.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
`volFieldValue` FO should write non-empty fields.
### 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 : 18c68e6b74v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1960scaledFixedValue error with pimpleFoam2020-12-17T15:46:15ZCarlos Peña-MonferrerscaledFixedValue error with pimpleFoam<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
Crash at second iteration when testing `scaledFixedValue` BC in `pitzDaily`.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `$WM_PROJECT_DIR/tutorials/incompressible/pimpleFoam/RAS/pitzDaily` with the following change on `0/U`:
```
- inlet
- {
- type fixedValue;
- value uniform (10 0 0);
- }
+ inlet
+ {
+ type scaledFixedValue;
+
+ scale table
+ (
+ ( 0 0)
+ ( 1.0 1.0)
+ (100.0 1.0)
+ );
+
+ refValue
+ {
+ type fixedValue;
+ value uniform (10 0 0);
+ }
+ }
```
### 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.
-->
```
Courant Number mean: 6.1914e-05 max: 0.00111829
deltaT = 0.000145287
Time = 0.000265769
PIMPLE: iteration 1
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in <path>/OpenFOAM-v2006/platforms/linuxPPC64leGccDPInt64Opt/lib/libOpenFOAM.so
#3 ? in <path>/OpenFOAM-v2006/platforms/linuxPPC64leGccDPInt64Opt/lib/libOpenFOAM.so
#4 Foam::Function1Types::TableBase<double>::value(double) const at ??:?
#5 Foam::PatchFunction1Types::UniformValueField<double>::value(double) const at ??:?
#6 Foam::scaledFixedValueFvPatchField<Foam::Vector<double> >::operator==(Foam::fvPatchField<Foam::Vector<double> > const&) at ??:?
#7 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::operator==(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary const&) at ??:?
#8 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::operator==(Foam::tmp<Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> > const&) at ??:?
#9 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::storeOldTime() const at ??:?
#10 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::storeOldTimes() const at ??:?
#11 Foam::fvMatrix<Foam::Vector<double> >::fvMatrix(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet const&) at ??:?
#12 Foam::fv::EulerDdtScheme<Foam::Vector<double> >::fvmDdt(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
#13 ? at ??:?
#14 ? at ??:?
#15 ? in /lib64/libc.so.6
#16 __libc_start_main in /lib64/libc.so.6
Segmentation fault
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2006
- Operating system : centos
- Hardware info :
- Compiler : gccKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1920Issue with SRFSimpleFoam2020-12-18T15:52:52ZLorenzo CozziIssue with SRFSimpleFoamDear developers,
I am running a benchmark OpenFOAM case to compare its results with a reference run performed with Starccm+, adopting the same polyhedral mesh. The steady-state case involves the impeller of a centrifugal pump and the me...Dear developers,
I am running a benchmark OpenFOAM case to compare its results with a reference run performed with Starccm+, adopting the same polyhedral mesh. The steady-state case involves the impeller of a centrifugal pump and the mesh includes just one blade and conformal periodicity surfaces. Boundary conditions have been imposed to be coherent with the ones of Starccm+. The solver adopted is SRFSimpleFoam.
The problem is that the case seems to converge in less that 3000 steps, but the results that I get are totally surrealistic. Just to give you an idea, the pump is predicted to work as a turbine with static pressure reducing its value moving downstream in the meridional flow-path. Also the pressure field has a range spanning from really low to really high values.
I tried several settings in terms of fvSchemes and fvSolution without any improvement.
As I am not sure what is the exact issue afflicting the run (cyclicAMI, SRF model, etc.), I have uploaded all the case on Dropbox, you can find the link here: [link](https://www.dropbox.com/s/pb2vst6nvzolj10/impellerSRFSimpleFoam_SHARE.tar?dl=0)
I hope you can find a way to fix the solver behavior for this case,
thanks in advance.
Lorenzohttps://develop.openfoam.com/Development/openfoam/-/issues/1965Attempt to cast type zeroGradient to type nutWallFunction2020-12-21T14:15:42ZRichard LoveAttempt to cast type zeroGradient to type nutWallFunction<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When trying to simulate turbulent flow over open terrain using a k-epsilon model and RAS turbulence with inlet and outlet as type patch, the solver begins to solve for ux, uy, uz and it then fails with the warning 'FOAM FATAL ERROR:
Attempt to cast type zeroGradient to type nutWallFunction
However when the patch types in constant are changed to wall, the solution begins to run. As I am trying to simulate turbulent flow over terrain, these patch types are not suitable
![SimulationFail](/uploads/89dff3d7c72be324041e1528d3403596/SimulationFail.png)
If there is any more information you require, please get in touch at love-r3@ulster.ac.uk
### Steps to reproduce
The boundary file setup is seen at this link https://www.cfd-online.com/Forums/openfoam-solving/232526-attempt-cast-type-zerogradient-type-nutwallfunction.html.
It is being simulated through a simple cuboid blockMesh with an STL file connected via snappyHexMesh, however it does not run, even without the STL
[blockMeshDict](/uploads/c54f08fb6b054b745534c1d24765669d/blockMeshDict)
[fvSchemes](/uploads/bfb95abd1186f0eed24e22fc08c634bb/fvSchemes)
[fvSolution](/uploads/70590e40f1c178ddc7e3d73271465095/fvSolution)
[controlDict](/uploads/d187d57856b4434bc44876caba6e54b7/controlDict)[turbulenceProperties](/uploads/ace56000d2f453002e6c84d7d0060e02/turbulenceProperties)
[transportProperties](/uploads/8322db7b9ce95ed211e41a7053d4bf7d/transportProperties)
[RASProperties](/uploads/a704d4b90b9d423c13384072029988b4/RASProperties)
### 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?
It creates an error when I try and have nut type as 'zeroGradient' inside the nut file when inlet/outlet/top is type patch
### What is the expected *correct* behavior?
It should run without cancelling when the polymesh/boundary is type patch
### Relevant logs and/or images
dimensions [0 2 -1 0 0 0 0];
internalField uniform 0;
boundaryField
{
#include "include/ABLConditions"
inlet
{
type zeroGradient;
//value uniform 0.0;
}
outlet
{
type zeroGradient;
//value uniform 0;
}
top
{
type zeroGradient;
//value uniform 0;
}
DuneField
{
type nutkAtmRoughWallFunction;
z0 $z0;
value uniform 0;
}
}
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v7
Operating system : ubuntu
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :7
- Operating system :ubuntu
- Hardware info :
- Compiler :
### Possible fixes
<!--
'--> FOAM FATAL ERROR:
Attempt to cast type zeroGradient to type nutWallFunction
From function To& Foam::refCast(From&) [with To = const Foam::nutWallFunctionFvPatchScalarField; From = const Foam::fvPatchField<double>]
in file /home/ubuntu/OpenFOAM/OpenFOAM-7/src/OpenFOAM/lnInclude/typeInfo.H at line 114'
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->