Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-12-06T13:23:13Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2451contactAngleForce parallel bug2022-12-06T13:23:13ZQuentin RoyercontactAngleForce parallel bug<!--
*** 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 using the finiteArea to study thin films, it is possible to use the 'perturbedTemperatureDependantContactAngle' force, but when using parallelization, a problem occurs at the boundary between processors; the contactAngle boundary condition between processors is set to 'uniform (0 0 0)' instead of 'nonuniform List...'.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Using the 'perturbedTemperatureDependantContactAngle' force with the finiteArea method and using parallelization.
### 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
-->
Open the tutorial 'incompressible/pimpleFoam/laminar/inclinedPlaneFilm', set the Ccf in 0/U to 1 then use Allrun-parallel.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Some fluid seems to be imprisoned at the boundary between processors, but if you observe the 'contactAngle:contactForce' in Paraview, you will notice it is set to 0 at the boundary.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The film behavior should not be changed by the communication between processors.
### 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.
-->
This picture is the simulation of a falling thin film, the domain is decomposed in 6 regions you can clearly see. Red/blue is the film height scale and dark is the contactAngleForce scale. ![Angle_contact](/uploads/8cd706cb3e83363b1545feb275e88415/Angle_contact.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
- Operating system : centos
- 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
-->
I don't know if the problem comes from the angle itself or from the force, but changing the boundary condition between processor should be the solution.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2450Errors when using post-processing function for PLIC interfaces in InterIsoFoam2022-05-02T20:02:33Zwu erjunErrors when using post-processing function for PLIC interfaces in InterIsoFoamI used the post-processing function in InterIsoFoam to get the PLIC interfaces. Interfaces were successfully generated at the beginning. But after some time steps, there are some errors showing the failure of the generation process. The ...I used the post-processing function in InterIsoFoam to get the PLIC interfaces. Interfaces were successfully generated at the beginning. But after some time steps, there are some errors showing the failure of the generation process. The code I added in controlDict and the error prompted by the terminal are as follows.
The post-processing function in controlDict:
```
functions
{
surfaces
{
type surfaces;
libs (geometricVoF sampling);
writeControl writeTime;
surfaceFormat vtp;
fields (p U);
interpolationScheme cell;
surfaces
{
freeSurf
{
type interface;
interpolate false;
}
}
}
}
```
Errors prompted by the terminal:
```
Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in /lib64/libpthread.so.0
#3 Foam::cutCell::calcIsoFacePointsFromEdges(Foam::Vector<double> const&, Foam::Vector<double> const&, Foam::DynamicList<Foam::DynamicList<Foam::Vector<double>, 16>, 16> const&, Foam::DynamicList<Foam::Vector<double>, 16>&) at ??:?
#4 Foam::cutCellPLIC::facePoints() at ??:?
#5 Foam::reconstructionSchemes::surface() at ??:?
#6 Foam::sampledInterface::updateGeometry() const at ??:?
#7 Foam::sampledSurfaces::performAction(unsigned int) at ??:?
#8 Foam::functionObjects::timeControl::write() at ??:?
#9 Foam::functionObjectList::execute() at ??:?
#10 Foam::Time::run() const at ??:?
#11 ? at ??:?
#12 __libc_start_main in /lib64/libc.so.6
#13 ? at ??:?
/var/spool/slurm/d/job2377338/slurm_script: line 7: 22486 Segmentation fault interIsoFoam
```https://develop.openfoam.com/Development/openfoam/-/issues/2449OpenFOAM 2112 build issues - ld.lld: error: undefined symbol:referenced by MP...2022-06-03T13:21:46ZNaina PatilOpenFOAM 2112 build issues - ld.lld: error: undefined symbol:referenced by MPPICInterFoam.C<!--
*** 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
OpenFOAM 2112 completes the build with the following error-ld.lld: error: undefined symbol: typeinfo for Foam::regionModels::regionFaModel
referenced by MPPICInterFoam.C
This doesn't result in desired number of binaries end of build
### Steps to reproduce
```
export OPENFOAMROOT=<Path_to_OpenFOAM_Installtion> ##current working directory/ PWD ##
wget https://dl.openfoam.com/source/v2112/OpenFOAM-v2112.tgz
wget https://dl.openfoam.com/source/v2112/ThirdParty-v2112.tgz
cd $OPENFOAMROOT
tar -xzf OpenFOAM-v2112.tgz
tar -xzf ThirdParty-v2112.tgz
export WM_CXXFLAGS="$CFLAGS"
export WM_CFLAGS="$CXXFLAGS"
```
##### Edit/Modify these files as per AOCC
```
$OPENFOAMROOT/OpenFOAM-v2112/etc/bashrc
sed -i 's/WM_COMPILER=Gcc/WM_COMPILER=Amd/' $OPENFOAMROOT/OpenFOAM-v2112/etc/bashrc
$OPENFOAMROOT/OpenFOAM-v2112/etc/config.sh/mpi
export MPI_ARCH_PATH= Path to OpenMPI installation
source $OPENFOAMROOT/OpenFOAM-v2112/etc/bashrc
echo $WM_PROJECT_DIR
```
##### Build OpenFOAM-v2112
```
cd $OPENFOAMROOT/OpenFOAM-v2112
time ./Allwmake -j 64 all -k 2>&1 |tee OpenFOAM_AOCC_install.log
source $OPENFOAMROOT/OpenFOAM-v2112/etc/bashrc
```
### What is the current *bug* behaviour?
ldd error referencing MPPICInterFoam.C during build. This results in incorrect number of binaries.
### What is the expected *correct* behavior?
clean build without ldd error. 312 binaries are expected. But 311 entries are generated.
### Relevant logs and/or images
ld.lld: error: undefined symbol: typeinfo for Foam::regionModels::regionFaModel
referenced by MPPICInterFoam.C
v2112/build/linux64AmdDPInt32Opt/applications/solvers/multiphase/MPPICInterFoam/MPPICInterFoam.ovoid Foam::SurfaceFilmModel<Foam::KinematicCloud<Foam:: Cloud<Foam::KinematicParcel<Foam:article> > > >::inject<Foam::KinematicCloud<Foam::Cloud<Foam::K inematicParcel<Foam:article> > > >(Foam::KinematicCloud<Foam::Cloud<Foam::Kinematic Parcel<Foam:article> > >&))
referenced by MPPICInterFoam.C
### Environment information
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112
Operating system : centos 8.3
Hardware info : AMD Epyc 7763
Compiler : clang/Aocc 3.2
### Possible fixes
We have currently found a workaround by linking -lregionFaModels in the line
"LINK_LIBS = $(c++DBUG) -Wl,--as-needed **-lregionFaModels**"
path - OpenFOAM-v2112/wmake/rules/General/Amd/link-c++
do we have any official fix for this ?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2448chemFoam solver gets wrong results when using second order time scheme2022-05-17T04:32:25ZHaochen LiuchemFoam solver gets wrong results when using second order time scheme<!--
*** 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 using the chemFoam solver to to run the corresponding tutorial case, we found that using "Euler" as the ddt scheme leads to correct results, which is the same as the CHEMKIN result (the final temperature is 2660K). While using "backward" or the other second order schemes leads to a much lower final temperature. We are not sure if this issue still exists in reactingFoam, which has been widely used in turbulent combustion simulations by OpenFOAM. This question is very important for us.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
1. Run the tutorial case with default settings and plot the results. The case dictionary is: /tutorials/combustion/chemFoam/gri
2. Change the ddt scheme from "Euler" into "backward" and run the case again.
3. Plot the results and compare them with the CHEMKIN result provided in the tutorial case: /tutorials/combustion/chemFoam/gri/chemkin/senk.out
(The OpenFOAM version we use is v2112)
<!-- 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?
The final temperature does not agree with the CHEMKIN result for second order ddt schemes.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The final temperature agree with the CHEMKIN result for different ddt schemes.
<!-- 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 : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2112
- Operating system :Linux
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2447triSurfaceMesh does not detect inconsistent face orientation2022-05-25T07:12:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comtriSurfaceMesh does not detect inconsistent face orientation### Functionality to add/problem to solve
triSurfaceMesh on-demand detects if it is open or closed (all edges have 2 faces). However it does not check whether all faces use the edge in opposite order. This is necessary for some algorith...### Functionality to add/problem to solve
triSurfaceMesh on-demand detects if it is open or closed (all edges have 2 faces). However it does not check whether all faces use the edge in opposite order. This is necessary for some algorithms, not for others.
### Proposal
Compare edge orientation when finding edge again.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2446dry-run support for multi-region2022-06-28T10:53:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdry-run support for multi-region### Functionality to add/problem to solve
The multi-region solvers (e.g. chtMultiRegionFoam) do not support the -dry-run or -dry-run-write option### Functionality to add/problem to solve
The multi-region solvers (e.g. chtMultiRegionFoam) do not support the -dry-run or -dry-run-write optionMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2445array sampledSet does not check input2023-05-31T11:10:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comarray sampledSet does not check input### Functionality to add/problem to solve
sampling using an 'array' of seed points is not robust.
- not being used in any tutorial
- does not check for pointsDensity having >0 elements only
- uses origin+span instead of centre+bidirect...### Functionality to add/problem to solve
sampling using an 'array' of seed points is not robust.
- not being used in any tutorial
- does not check for pointsDensity having >0 elements only
- uses origin+span instead of centre+bidirectional span
- if coordinateSystem is not specified in dictionary it assumes the 'axis' specification is part of the coordinate system (instead of describing how the output samples should be ordered and output)https://develop.openfoam.com/Development/openfoam/-/issues/2444vectorField normalise2022-04-30T14:48:23ZMark OLESENvectorField normalise- further to today's discussions, should add in a normalise() method to vectorField and GeometricFields.
Default implementation would be a no-op. For a specialised `vectorField` would forward to calling vector::normalise on each entry. ...- further to today's discussions, should add in a normalise() method to vectorField and GeometricFields.
Default implementation would be a no-op. For a specialised `vectorField` would forward to calling vector::normalise on each entry. FieldFields - same thing.
@kuti expressed the wish to have an optional tolerance parameter. Which is ok, except that we would probably want to unroll the function calls to determine the mag directly (within the loop) instead of forwarding to vector::normalise for that.
Not really sure if we want to have a top-level normalise function (eg, taking a field and returning a tmp). Could get a bit weird, not sure we need it.
Main benefits:
- simpler to write ; Eg, `fld.normalise()` vs. `field /= mag(fld)`
- while _not_ forgetting to handle divide by zero. Eg, `fld.normalise()` vs. `field /= mag(fld) + VSMALL`
- code efficiency. More efficient to loop over and re-assign the existing field instead of allocating a tmp (for the mag) adding VSMALL and then dividing (another tmp) to replace the original field.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2443thermophysicalFunctions/integratedNonUniformTable <revised>2022-04-15T02:07:26ZScurry GunHong KimthermophysicalFunctions/integratedNonUniformTable <revised><!--
*** 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 -->
This code-bug is a simple mistake, but it can produce a serious problem at least for me.
For several monthes, I've tried to test a tabulated thermo-data and found this bug.
Today I found there is a worng formula to integrate the tabulated data to calculate the enthalpy of specie, for example table(T, Cp).
The bug is in "integratedNonUniformTableThermophysicalFunction.C" under src/thermophysicalProperties/thermophysicalFunctions/integratedNonUniformTable/.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Just look the Constructor of "integratedNonUniformTable" or the fuction of "intfdT".
- integral formula:
Integral from Tst to Ti = Integral[i-1] + intfdT(Ti)*dT
- in "intfdT" function, it returns the full integral value from Tst to Ti.
return-value = intf_[i] + (fi + 0.5*lambda*(values()[i + 1].second() - fi))*dT
### 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
-->
- There are 2 tutorials in $FOAM_TUTORIALS, they use the thermo-type of tabulation.
multiphase/icoReactingMultiphaseInterFoam/inertMultiphaseMultiComponent
multiphase/icoReactingMultiphaseInterFoam/mixerVesselAMI2D
- the bug is related only to calculate the enthalpy of hTabulated-thermo.
Actually, two cases work. However if you use a large table of Cp, then a serious error occur to stop.
### What is the current *bug* behaviour?
- If the element-number of tabulated data is small, then it might not produce a serious problem.
Therefore, nobody notice any wrong result.
- for a large tabulated data, in most cases, the calculation must stop to say wrong temperature.
<!-- 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 : v2112|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112(or any)
- Operating system : ubuntu
- Hardware info : any
- Compiler : any
### Possible fixes
- code:
https://www.openfoam.com/documentation/guides/latest/api/integratedNonUniformTableThermophysicalFunction_8C_source.html
- one simple suggestion for constructor "integratedNonUniformTable"
original code
for (label i = 1; i < intf_.size(); ++i)
{
intf_[i] = intf_[i-1] + intfdT(0, values()[i].first());
intfByT_[i] = intfByT_[i-1] + intfByTdT(0, values()[i].first());
}
suggestion
for (label i = 1; i < intf_.size(); ++i)
{
intf_[i] = intfdT(0, values()[i].first());
intfByT_[i] = intfByTdT(0, values()[i].first());
}
<!--
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/2442chtMultiRegionFoam with anistropic diffusivity2023-12-07T05:40:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comchtMultiRegionFoam with anistropic diffusivity### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the proper...### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the properties
- if the thermo properties change (e.g. temperature varying alpha)
- if the coordinate system changes (e.g. cylindrical coordinate system, pivoting across second axis)
### Target audience
Anyone using cht with changing solid properties.
### Proposal
Two possibilities:
- have option to update/correct coordinate system and update anisotropic diffusivity accordingly
- not cache aniAlphas but calculate it on-the-fly
@mark @Sergiohttps://develop.openfoam.com/Development/openfoam/-/issues/2441Give subclasses of pyrolysisChemistryModel to the solid concentrations2022-06-23T08:41:34ZBernhard GschaiderGive subclasses of pyrolysisChemistryModel to the solid concentrationsWhile the reaction rates can be easily read or manipulated by subclasses of this class they can not access the initial solid concentrations (not event for reading)
This is fixed by the attached trivial patch by moving the field from `pr...While the reaction rates can be easily read or manipulated by subclasses of this class they can not access the initial solid concentrations (not event for reading)
This is fixed by the attached trivial patch by moving the field from `private`to `protected`
[0003-Allow-accesing-the-solid-concentrations-from-sub-cla.patch](/uploads/4b46d356bfbd65e567d44f4797f159be/0003-Allow-accesing-the-solid-concentrations-from-sub-cla.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2440Parser for chemical reactions silently accepts faulty equations2022-06-23T08:41:34ZBernhard GschaiderParser for chemical reactions silently accepts faulty equations
### Summary
The parser for chemical reactions accepts chemical reactions with typos, ignores the parts it doesn't understand and the simulations then run with chemical reactions that are different from what the user expects
The two m...
### Summary
The parser for chemical reactions accepts chemical reactions with typos, ignores the parts it doesn't understand and the simulations then run with chemical reactions that are different from what the user expects
The two main issues are
- punctuation tokens that don't make sense
- species that are not in the species list are ignored
### Steps to reproduce
Use the tutorial case `combustion/fireFoam/LES/simplePMMApanel` and edit the file `constant/reactions` to modify the reaction in
```
reactions
{
methaneReaction
{
type irreversibleArrheniusReaction;
reaction "CH4 + 2O2 = CO2 + 2H2O";
A 5.2e16;
beta 0;
Ta 14906;
}
}
```
Possible problems are
```
reaction "CH4 + 2O2 = CO2 - 2H2O";
```
(wrong punctuation token) and
```
reaction "CH4 + 2O2 = COO2 + 2H2O";
```
(unknown species COO2).
### What is the current *bug* behaviour?
The simulation runs without a hint that there is a problem but the used chemical equation is fundamentally different)
### What is the expected *correct* behavior?
Program should crash while reading the faulty equation to give the user a chance to fix it
### Environment information
- OpenFOAM version : any OF version of the last year. Tested on the current git-version
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
Attached there are 2 patches to fix these problems. One to fail on unknown punctuation tokens. The other one to fail if there is an unknown species (this patch slightly changes the API of the speciesCoeffs-class because for solid reactions when calling the base class the parser should **not** fail for unknown species because these might be from the "other" phase
[0001-Failing-on-extra-punctuation-tokens-in-chemical-equa.patch](/uploads/597174737fe7a34add8b46e9e6351617/0001-Failing-on-extra-punctuation-tokens-in-chemical-equa.patch)[0002-Fail-for-unknown-species.patch](/uploads/3123211e6c89b382c24b490f1986ec2e/0002-Fail-for-unknown-species.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2439WM_SCHEDULER breaks compilation generated sources (flex, bison etc)2022-06-03T11:43:26ZBernhard GschaiderWM_SCHEDULER breaks compilation generated sources (flex, bison etc)
### Summary
When using a wrapper for the compiler with WM_SCHEDULER the compilation of sources where another utility generates the sources breaks
### Steps to reproduce
I use `ccache` speed up re-compilation. When I enable it and co...
### Summary
When using a wrapper for the compiler with WM_SCHEDULER the compilation of sources where another utility generates the sources breaks
### Steps to reproduce
I use `ccache` speed up re-compilation. When I enable it and compile a library I get an error message for one of the flex-files
```
> export WM_SCHEDULER=ccache
> wmake libso src/fileFormats
ccache flex -+ -f -o /slowdata/OpenFOAMInstallations/OpenFOAM-Ubuntu/OpenFOAM-plus/build/linux64Clang120DPInt32Opt/src/fileFormats/stl/STLAsciiParseFlex.L.C stl/STLAsciiParseFlex.L '&&' clang++ -std=c++14 -m64 -pthread -DOPENFOAM=2202 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-undefined-var-template -Wno-unknown-warning-option -O3 -DNoRepository -ftemplate-depth-100 -iquote. -IlnInclude -I/slowdata/OpenFOAMInstallations/OpenFOAM-Ubuntu/OpenFOAM-plus/src/OpenFOAM/lnInclude -I/slowdata/OpenFOAMInstallations/OpenFOAM-Ubuntu/OpenFOAM-plus/src/OSspecific/POSIX/lnInclude -fPIC -Wno-old-style-cast -Wno-unused-local-typedefs -Wno-tautological-undefined-compare -Wno-shift-negative-value -Wno-null-pointer-arithmetic -Wno-null-pointer-subtraction -Wno-unknown-warning-option -Wno-deprecated-copy-with-user-provided-copy -Wno-tautological-overlap-compare -Wno- -c /slowdata/OpenFOAMInstallations/OpenFOAM-Ubuntu/OpenFOAM-plus/build/linux64Clang120DPInt32Opt/src/fileFormats/stl/STLAsciiParseFlex.L.C -o /slowdata/OpenFOAMInstallations/OpenFOAM-Ubuntu/OpenFOAM-plus/build/linux64Clang120DPInt32Opt/src/fileFormats/stl/STLAsciiParseFlex.o
/usr/bin/flex: can't open &&
/usr/bin/m4:stdin:7265: ERROR: end of file in string
```
### Example case
Not applicable
### What is the current *bug* behaviour?
Compilation fails for this and similar files (Lemon, Bison etc)
### What is the expected *correct* behavior?
Compilation should work
### Relevant logs and/or images
See above
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : current git-version. But also any other release from the last years
- Operating system : Ubuntu 18.04
- Compiler : Clang 12 (but happens with other compilers as well)
The problem **might** be that Ubuntu doesn't use for `/bin/sh` not `bash` like most distros but they use `dash`which has some small incompatibilities and one of them might be a different treatment of `'&&'` that is used if WM_SCHEDULER is set
### Possible fixes
Attached there is a patch that fixes this by moving the WM_SCHEDULER immediately before the compiler call not the call of the utility that generates the source code. This makes sense as utilities like ccache (or distcc - which is the other application for WM_SCHEDULER that I've seen) only know how to wrap the compiler calls anyway
[0001-WM_SCHEDULER-breaks-compilation.patch](/uploads/096193d2b341d208d8c696eb835a4506/0001-WM_SCHEDULER-breaks-compilation.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2438sets started to produce different number of output files2022-04-12T15:00:43ZKutalmış Berçinsets started to produce different number of output filesI am not sure the following change was intentional or not. Some of my VV cases started to break down at the level of plot production, hence realised the following behaviour change.
Minimal test case: [sample-issue.zip](/uploads/ff257560...I am not sure the following change was intentional or not. Some of my VV cases started to break down at the level of plot production, hence realised the following behaviour change.
Minimal test case: [sample-issue.zip](/uploads/ff2575606f95a03105b084492172cc29/sample-issue.zip) - to reproduce the issue, just execute `Allrun` and inspect `postProcessing` content for different HEADs.
The following `system/sample` file yields different number of output files for v2112 (14aeaf8dab) vs dev (d7c873902c) for the minimal test case:
```
type sets;
libs (sampling);
fields
(
U
turbulenceProperties:k
turbulenceProperties:R
);
...
```
For v2112 (14aeaf8dab) or for the develop at least six weeks ago (1a55829ef9), three files were produced:
```
y_turbulenceProperties:k.xy
y_turbulenceProperties:R.xy
y_U.xy
```
For dev (d7c873902c), a single file was produced:
```
y_turbulenceProperties:k_U_turbulenceProperties:R.xy
```
Could you tell me if this output change is intentional or not? @andy @mark @Prashanthttps://develop.openfoam.com/Development/openfoam/-/issues/2437Loading external library (preCICE coupling library)2022-04-23T07:49:26ZPaul BrousseauLoading external library (preCICE coupling library)Hi,
We are trying to use the coupling-codes-library preCICE with Openfoam-v2112, compiled from source and without `thirdParty`, on a cluster with this distribution:
```
Distributor ID: CentOS
Description: CentOS Linux release 7.8.2003 ...Hi,
We are trying to use the coupling-codes-library preCICE with Openfoam-v2112, compiled from source and without `thirdParty`, on a cluster with this distribution:
```
Distributor ID: CentOS
Description: CentOS Linux release 7.8.2003 (Core)
Release: 7.8.2003
Codename: Core
```
PreCICE developers seem to think that our Openfoam compilation is the cause of the problem. Indeed this error occurs when loading the external library in the `controlDict`:
```
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib64/libpthread.so.0
#3 ? in /opt/ohpc/pub/libs/gnu8/openmpi3/trilinos/12.14.1/lib/libteuchoscore.so.12
#4 ? in /lib64/ld-linux-x86-64.so.2
#5 ? in /lib64/ld-linux-x86-64.so.2
#6 ? in /lib64/ld-linux-x86-64.so.2
#7 ? in /lib64/ld-linux-x86-64.so.2
#8 ? in /lib64/libdl.so.2
#9 ? in /lib64/ld-linux-x86-64.so.2
#10 ? in /lib64/libdl.so.2
#11 dlopen in /lib64/libdl.so.2
#12 Foam::dlOpen(Foam::fileName const&, bool) at ??:?
#13 Foam::dlOpen(Foam::fileName const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) at ??:?
#14 Foam::dlLibraryTable::openLibrary(Foam::fileName const&, bool) at ??:?
#15 Foam::dlLibraryTable::open(Foam::fileName const&, bool) at ??:?
#16 bool Foam::dlLibraryTable::open<Foam::HashTable<Foam::autoPtr<Foam::functionObject> (*)(Foam::word const&, Foam::Time const&, Foam::dictionary const&), Foam::word, Foam::Hash<Foam::word> >*>(Foam::dictionary const&, Foam::word const&, Foam::HashTable<Foam::autoPtr<Foam::functionObject> (*)(Foam::word const&, Foam::Time const&, Foam::dictionary const&), Foam::word, Foam::Hash<Foam::word> >* const&, bool) at ??:?
#17 Foam::functionObject::New(Foam::word const&, Foam::Time const&, Foam::dictionary const&) at ??:?
#18 Foam::functionObjectList::read() at ??:?
#19 Foam::Time::run() const at ??:?
#20 ? at ??:?
#21 __libc_start_main in /lib64/libc.so.6
#22 ? at ??:?
Exception en point flottant
```
In fact, simply loading the preCICE library (and not using it) makes OF crashes. Of course, OF works well alone.
Do you have any guess on where to look and how to debug this ?
Thanks !
Paulhttps://develop.openfoam.com/Development/openfoam/-/issues/2436extended capability of redistributePar2022-06-15T09:52:04ZMark OLESENextended capability of redistributeParCurrently does not properly handle point fields (pointMesh) or area/edge fields (finiteArea)
Ref: EP1722 (@mark and @mattijs)Currently does not properly handle point fields (pointMesh) or area/edge fields (finiteArea)
Ref: EP1722 (@mark and @mattijs)https://develop.openfoam.com/Development/openfoam/-/issues/2435Minor error with mappedFile PatchFunction12022-04-08T14:50:49ZBen MalinMinor error with mappedFile PatchFunction1
### Summary
When a field name is specified other than the default, the format of the write function is incorrect
### Steps to reproduce
Run a case using the PatchFunction1 mappedFile with a non-default fieldTable entry. The result is...
### Summary
When a field name is specified other than the default, the format of the write function is incorrect
### Steps to reproduce
Run a case using the PatchFunction1 mappedFile with a non-default fieldTable entry. The result is then output in the format:
```
patch
{
type ...;
fieldTable "[non-default name]";
value
{
type mappedField;
...
}
}
```
If this result is then used to run another case, the fieldTable entry gets missed and an error will be thrown that the field can't be found at constant/boundaryData/patch/...
The correct behavior is:
```
patch
{
type ...;
value
{
type mappedField;
fieldTable "[non-default name]";
...
}
}
```
### Possible fixes
Easy fix, minor change to writeData function. Just need to move the os.writeEntryIfDifferent("fieldTable") to be within the os.beginBlock(word(this->name() + "Coeffs")) section.https://develop.openfoam.com/Development/openfoam/-/issues/2434Issue when Executing Simulation in Parallel2024-01-03T14:11:37ZTamas EgeresiIssue when Executing Simulation in Parallel### Summary
Recently I updated my system to Ubuntu 21.10. Then I installed the pre-compiled OpenFOAM v2112 based on the information on the webpage. When I started any case from the tutorials in parallel mode, it diverged rapidly. I've a...### Summary
Recently I updated my system to Ubuntu 21.10. Then I installed the pre-compiled OpenFOAM v2112 based on the information on the webpage. When I started any case from the tutorials in parallel mode, it diverged rapidly. I've attached the log.simpleFoam from the motorBike case.
In order to overcome of this problem, I changed maxThreadFileBufferSize from 0 to 1e9 in the global controlDict. The motorBike case went smoothly after this.
However, the more complex solvers such as compressibleInterDyMFoam in the sphereDrop setup or the DTCHullMoving setup diverged immediately no matter how I set maxThreadFileBufferSize. I also attached those 2 log files (log.compressibleInterDyMFoam and log.interFoam).
To reproduce this behavior, use Ubuntu 21.10 with motorBike or sphereDrop tutorial. You can check that maxThreadFileBufferSize is set to 0 in $FOAM_ETC/controlDict initially.
### Relevant logs and/or images
[log.simpleFoam](/uploads/c1c36b5cf2e8bb78743226b28302f2ea/log.simpleFoam)
[log.compressibleInterDyMFoam](/uploads/728a1b88dc28519ba6b8aafae4bf5f3c/log.compressibleInterDyMFoam)
[log.interFoam](/uploads/e456021e437ad5f5c1f5d27c8de5dcfd/log.interFoam)
### Environment information
OpenFOAM version : v2112
Operating system : ubuntu 21.10
Hardware info : Intel(R) Core(TM) i9-10900 CPU @ 2.80GHz
Compiler : gcc
- OpenFOAM version : v2112
- Operating system : ubuntu 21.10
- Hardware info : Intel(R) Core(TM) i9-10900 CPU @ 2.80GHz
- Compiler : gcc
### Possible fixes
Partially fixing: I changed maxThreadFileBufferSize from 0 to 1e9 which fixed 1 of the 3 cases.https://develop.openfoam.com/Development/openfoam/-/issues/2433issue with compiling runTimePostprocessing:2022-04-30T14:49:01ZPawan Ghildiyalissue with compiling runTimePostprocessing:Hi @mark
Operating system: Redhat7.9
I compiled VTK-9.2 from Paraview as shipped with ThirdParty/sources/Paraview-5.10.0.
with mesa+llvm successfully.
`./makeVTK -mpi=0 -osmesa -mesa-prefix /home/pawan/OpenFOAM/OpenFOAM-v2112/Thi...Hi @mark
Operating system: Redhat7.9
I compiled VTK-9.2 from Paraview as shipped with ThirdParty/sources/Paraview-5.10.0.
with mesa+llvm successfully.
`./makeVTK -mpi=0 -osmesa -mesa-prefix /home/pawan/OpenFOAM/OpenFOAM-v2112/ThirdParty/platforms/linux64Gcc/mesa-17.1.1`
However while compiling the runTimePostProcessing, it fail ![Untitled](/uploads/ec2ccd42f2c1139416de84e9f2a74646/Untitled.png)https://develop.openfoam.com/Development/openfoam/-/issues/2432Parallel simulation diverges always2022-03-31T19:14:05ZTamas EgeresiParallel simulation diverges alwaysDear Support,
All of my parallel cases diverges when running them on my workstation. I've tested all of the available OpenFOAM.com OpenFOAM versions, and all of them gives the same problem. Hovewer, when I run the OpenFOAM.org OpenFOAM ...Dear Support,
All of my parallel cases diverges when running them on my workstation. I've tested all of the available OpenFOAM.com OpenFOAM versions, and all of them gives the same problem. Hovewer, when I run the OpenFOAM.org OpenFOAM version 9, it goes without any problem.
My system is:
LSB Version: core-11.1.0ubuntu3-noarch:security-11.1.0ubuntu3-noarch
Distributor ID: Ubuntu
Description: Ubuntu 21.10
Release: 21.10
Codename: impish
I've attached my log file for the motorBike test case.
[log.simpleFoam](/uploads/be3b40d4632233e19212b1f61bab6a09/log.simpleFoam)