View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3582 [OpenFOAM] Bug trivial always 2020-10-25 17:04 2020-10-25 18:15
Reporter: blttkgl Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 15.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Deprecated importantSpecies subDict in chemistryProperties
Description: SandiaD_LTS and DLR_A_LTS tutorials under reactingFoam has a subDict called importantSpecies under chemistryProperties, which is not read by any model. I am guessing that they are deprecated or included by mistake when they are introduced as tutorials.

https://github.com/OpenFOAM/OpenFOAM-dev/search?q=importantSpecies

Best,

Bulut
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011640)
henry   
2020-10-25 18:15   
Resolved by commit 5e3c5a9698e8be746e3c951fa18cc4a0ddd13894


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3581 [OpenFOAM] Bug major always 2020-10-22 16:12 2020-10-22 18:29
Reporter: vitor.geraldes@tecnico.ulisboa.pt Platform: Unix  
Assigned To: OS: Other  
Priority: normal OS Version: (please specify)  
Status: new Product Version: 8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: bug in externalWallHeatFluxTemperature BC
Description: The radiation effect is not well implemented. When emissivity > 0, the temperature distribution is not well computed.
In the attached testing case is based on the following case,
OpenFOAM-8/tutorials/multiphase/compressibleInterFoam/laminar/depthCharge2D/

The scale of the mesh was reduced by a factor of 0.01, and the bubble was removed. The external temperature was increased to 400 K.

As we can see by the simulation, before one 1 s, the internal temperature increases beyond 400 K, which is a violation of the energy balance.
Tags:
Steps To Reproduce: Run the scipt "Allrun" in the attached case, which uses the solver "compressibleInterFoam".
Additional Information:
System Description
Attached Files: emissivityErrorTestCase.tar.gz (593,018 bytes) 2020-10-22 16:12
https://bugs.openfoam.org/file_download.php?file_id=3078&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3566 [OpenFOAM] Bug minor always 2020-10-06 12:54 2020-10-20 14:34
Reporter: aleixandre Platform: GNU/Linux  
Assigned To: henry OS: Other  
Priority: low OS Version: (please specify)  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: Unable to run Docker image openfoam8-linux in Raspberry pi 4 with Ubuntu 20.04.1 LTS
Description: hello,

I run openfoam8-linux, everything is downloaded but after the promt sais
"standard_init_linux.go:211: exec user process caused "exec format error"

Tags:
Steps To Reproduce: I have installed the .img "ubuntu-mate-20.04.1-beta2-desktop-arm64+raspi" on a Raspberry 4 b 8GB

i have followed all the instructions at https://openfoam.org/download/8-linux/

I am able to run Docker hello world

I tried many time to remove the image and reload it with no success

Any help?
Thanks a lot
Additional Information:
System Description
Attached Files: log.makePV (32,254 bytes) 2020-10-14 14:09
https://bugs.openfoam.org/file_download.php?file_id=3069&type=bug
log.makePVb (19,208 bytes) 2020-10-14 18:16
https://bugs.openfoam.org/file_download.php?file_id=3070&type=bug
Notes
(0011572)
wyldckat   
2020-10-08 09:42   
So two things:
1. If you have Ubuntu installed, you should have been able to simply install from Deb... but that won't work, because Raspberry Pi uses an ARM CPU, not an x86_64.

2. Installing via Docker would only work if you had installed the virtual machine based Docker.

I believe that the best option to get it up and running would be to build from source code: https://openfoam.org/download/source/ - given that you have Ubuntu, it should be straight forward... even though it might take the RaspberryPi some 24h or so to do the build...
(0011573)
aleixandre   
2020-10-08 10:41   
Many thanks for the answer ¡
Since I wrote the message I found that I could run "sudo apt-get install openfoam" and "sudo apt-get install paraview" directly from the prompt, so I was happy (I am pretty new in linux ...)
After install both of them paraview is working perfectly but openfoam seems to NOT to be ok at all
I sow the files and only /usr/share/openfoam/etc was created with files but nothing else, and I didnt know what to do else
I followed the instruction on https://openfoam.org/download/source/ but many problems during the compilation of ThirdPartySW/Paraview (./Allwmake was ok but ./makeParaview stopet always at 87% Built target vtkPVServerManagerRenderingCS Error 2 non-zero status 2) so I quit that idea as paraview was working well
Then I found, downloaded and extracted openfoam 1906.191111 +....tar it in the created folder /home/user/OpenFOAM/OpenFOAM-v1906
I added "source /home/user/OpenFOAM/OpenFOAM-v1906/etc/bashrc" to ./bashrc file and execute also from the term to update the variables
Finally I executed ./Allwmake (in /home/user/OpenFOAM/OpenFOAM-v1906/) and still running (I have also to install via apt-get flex bison and zlib1g-dev)
Now it seems that it is compiling but I don't know why it is only using 25-30% of the CPU (I see with top) because when I followed https://openfoam.org/download/source/ it was running at 97% (I have Raspberry pi 4 b 8GBs) so still running since yesterday
Now my only hope it is to have it working once finished and paraview would be properly "linked" to openfoam ....
I will let you know once finish, but if I missed something please let me know
Once again thanks for your support

by the way, I tried Docker option was seems to me much complicated....
(0011574)
aleixandre   
2020-10-08 22:01   
After 24hours compiling it seems taht OpenFoam is Ok, :-))))
I ran the first example, blockMesh was ok, but when I ran OpenFoam I have this:
 
user@ub:~/OpenFOAM/user-v1906/run/pitzDaily$ paraFoam
Cannot use ParaView reader module library (PVFoamReader)
The PV_PLUGIN_PATH environment value is not set

Continuing with builtin reader: paraFoam -vtk

Created temporary 'pitzDaily.foam'
/home/aleix/OpenFOAM/OpenFOAM-v1906/bin/paraFoam: 328: paraview: not found

if I launch "paraview" alone in the term it works perfectly

What can I do??
Thanks ¡¡
(0011575)
aleixandre   
2020-10-08 22:20   
For unknown reason it seems that paraview disappeared from the systems, however I just run "sudo apt install open paraview" again and now everything seems to be working well.

Thanks a lot ¡¡¡
(0011576)
henry   
2020-10-09 08:39   
OpenFOAM-v1906 is a fork of OpenFOAM produced by ESI and not a release by the OpenFOAM Foundation:

The OpenFOAM Foundation is the organisaton which holds the copyright of the OpenFOAM software and documentation, whose purpose is to manage and distribute OpenFOAM as free, open source software for the benefit of its users. It is a registered company, limited by guarantee based in England. As such, it has no share capital or shareholders, but has individual members committed to free, open source software, who run the organisation on a voluntary basis. It has no employees and any annual profit is retained within the organisation and cannot be distributed to members. OpenFOAM® is a registered trademark of OpenCFD Ltd, licensed to the OpenFOAM Foundation in 2011 so that it could distribute its software under under that name.

To obtain version 8, the latest release from the OpenFOAM Foundation download from

https://openfoam.org/version/8/
(0011577)
aleixandre   
2020-10-09 09:30   
Thanks Henry,
Afer seeing you message I have reseted the Rasp4 and now I have followed your instruction and openfoam8 copiling is in progress
I think the main issue was with Paraview not with openfoam and paraview can be directly installed by apt-get so I think it will be ok
Once finish I will let you know
Again thanks for your work and support
(0011578)
chris   
2020-10-09 10:14   
OpenFOAM-v1906 was released by ESI Group with false copyright statements.
Distribution of OpenFOAM-v1906 violates the GPL v3.
(0011579)
aleixandre   
2020-10-09 10:21   
Sorry Chris,
I didnt know that, as I said v1906 is removed and now openfoam8 is being compiled
I will let you know once it finish
Thanks ¡
(0011580)
aleixandre   
2020-10-09 13:28   
I realized that I am compiling Openfoam-8 in my user dir /home/aleix/OpenFOAM/OpenFOAM-8/
but I was going to create another user which should also being able to run openfoam
What do I have to do once the compilation is finished? should I copy the OpenFOAM-8 dir to the new user dir and edit new user ./bashrc?
Thanks ¡¡
(0011581)
aleixandre   
2020-10-10 11:09   
Hi again,
Really frustating :-(

I can't finish compilation...
I have the following error
"
g++ -std=c++11 -DlinuxArm64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -mcpu=native -DNoRepository -ftemplate-depth-100 -I/home/aleix/OpenFOAM/OpenFOAM-8/src/thermophysicalModels/reactionThermo/lnInclude -I/home/aleix/OpenFOAM/OpenFOAM-8/src/thermophysicalModels/basic/lnInclude -I/home/aleix/OpenFOAM/OpenFOAM-8/src/thermophysicalModels/specie/lnInclude -I/home/aleix/OpenFOAM/OpenFOAM-8/src/thermophysicalModels/functions/Polynomial -I/home/aleix/OpenFOAM/OpenFOAM-8/src/ODE/lnInclude -I/home/aleix/OpenFOAM/OpenFOAM-8/src/finiteVolume/lnInclude -I/home/aleix/OpenFOAM/OpenFOAM-8/src/meshTools/lnInclude -IlnInclude -I. -I/home/aleix/OpenFOAM/OpenFOAM-8/src/OpenFOAM/lnInclude -I/home/aleix/OpenFOAM/OpenFOAM-8/src/OSspecific/POSIX/lnInclude -fPIC -c chemistrySolver/chemistrySolver/chemistrySolvers.C -o /home/aleix/OpenFOAM/OpenFOAM-8/platforms/linuxArm64GccDPInt32Opt/src/thermophysicalModels/chemistryModel/chemistrySolver/chemistrySolver/chemistrySolvers.o
g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
make: *** [/home/aleix/OpenFOAM/OpenFOAM-8/wmake/rules/General/transform:26: /home/aleix/OpenFOAM/OpenFOAM-8/platforms/linuxArm64GccDPInt32Opt/src/thermophysicalModels/chemistryModel/chemistrySolver/chemistrySolver/chemistrySolvers.o] Error 1
aleix@ub-pi4:~/OpenFOAM/OpenFOAM-8$
"

I have tried with ./Allwmake ./AllWmake -j ./Allwmake -j 2 ... and always the same proble at the same point. I have 8GBs Memory so that should not be a problem I guess, but now I dont know what to do ....
any help more than wellcomed
Thanksl
(0011582)
henry   
2020-10-10 14:55   
You will need to increase the virtual memory limit to 13Gb to compile the latest chemistry models.
(0011583)
aleixandre   
2020-10-11 09:22   
thanks Henry,
I did the following:

sudo fallocate -l 6G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfil
sudo swapon /swapfile
sudo swapon --show
sudo free -h
./Allwmake -j

The compilation stoped two o three times, but I ran again ./Allwmake and it seems OpenFoam is now compiled. As there is no final message I dont know how to check it but I ran the pitDaily example and when I wrote paraFoam it tells me that there is no ParaView linked or installed and it tells me to run paraFoam -builtin ...
I ran "sudo apt-get install paraview" and I can run ParaView 5.7 standalone but I dont know how to link it with OpenFoam so I decided to compile ThirdParty elements in order to solve it.

The result is the following error:

./makeParaView

[ 87%] Linking CXX static library ../../lib/libvtkPVServerManagerRenderingCS-pv5.6.a
[ 87%] Built target vtkPVServerManagerRenderingCS
make: *** [Makefile:152: all] Error 2
Command exited with non-zero status 2
31839.81user 6229.39system 2:43:59elapsed 386%CPU (0avgtext+0avgdata 1743840maxresident)k
23224inputs+2848968outputs (43major+184083739minor)pagefaults 0swaps
aleix@ub-pi4:~/OpenFOAM/ThirdParty-8$

Do you have any idea what can I do?

Thanks,
(0011593)
wyldckat   
2020-10-14 13:12   
@aleixandre: A complete output log would be necessary to diagnose this build issue... if you run the build command like this:

    ./makeParaView -no-config > log.makePV 2>&1

You will get the file "log.makePV" that has the full output.

The "-no-config" option is to not have to start over from scratch and instead to continue closer to where it stopped.
(0011596)
aleixandre   
2020-10-14 14:09   
Hi wyldckat,
I followed your instructions, please see the log.makePV
Thanks additional feedback
(0011597)
wyldckat   
2020-10-14 15:20   
Looks like it's an issue with the internal PNG library that VTK is using by default... try with the following build command, which will consequently give you this log file "log.makePVb":

    ./makeParaView VTK_USE_SYSTEM_PNG:BOOL=ON > log.makePVb 2>&1

I found this by looking for the error message from in line 447 of your file, namely:

    libvtkpng-pv5.6.so.1: undefined reference to `png_init_filter_functions_neon'

The answer I found was this: https://gitlab.kitware.com/vtk/vtk/-/issues/17385
(0011603)
aleixandre   
2020-10-14 18:16   
Thanks Wyldckat,
Here the log file
Thanks for your support
(0011604)
wyldckat   
2020-10-14 18:24   
If I'm not mistaken, you need to install "libpng-dev":

    sudo apt install libpng-dev

Then run again the previous command for building... hopefully it will find automatically "libpng" to be installed this time around...
(0011607)
aleixandre   
2020-10-15 14:34   
Hello wyldckat,
It seems that now everything is been compiled properly :-)
Thansk a lot

Now I have the following message when I run paraFoam:
---
FATAL ERROR: The official reader module for OpenFOAM data does not exist on
your system. This means that the version of ParaView you are using was not
compiled with OpenFOAM, or distributed with a packaged version of OpenFOAM.

For information on packaged versions of OpenFOAM/ParaView and compilation of
OpenFOAM/ParaView, see https://openfoam.org/download

Alternatively, you might be able to view your OpenFOAM data with the reader
module provided with ParaView by running:
    paraFoam -builtin
----
If I execute paraview directly the version is 5.6.3 so it is ok, but how can I link to only execute paraFoam?

I cannot upload the log as it is higher Kbs than allowed ...

Thansk a lot for your indications
(0011608)
wyldckat   
2020-10-15 14:45   
The simplest is to run these commands:

    foam
    ./Allwmake

And wait a bit. By the end it should have not given any error messages and the necessary reader module is built.
(0011609)
aleixandre   
2020-10-15 15:05   
Thanks wyldckat,
I just did it, but no luck...
See below
Thanks ¡
---
aleix@ub-pi4:~/OpenFOAM/ThirdParty-8$ ./Allwmake

========================================
Start ThirdParty Allwmake
========================================

========================================
Build MPI libraries if required

========================================
Build Scotch decomposition library scotch_6.0.9
    /home/aleix/OpenFOAM/ThirdParty-8/platforms/linuxArm64GccDPInt32/scotch_6.0.9
    scotch header in /home/aleix/OpenFOAM/ThirdParty-8/platforms/linuxArm64GccDPInt32/scotch_6.0.9/include
    scotch libs in /home/aleix/OpenFOAM/ThirdParty-8/platforms/linuxArm64GccDPInt32/lib

========================================
Build PTScotch decomposition library scotch_6.0.9 (uses MPI)
    /home/aleix/OpenFOAM/ThirdParty-8/platforms/linuxArm64GccDPInt32/scotch_6.0.9

    ptscotch header in /home/aleix/OpenFOAM/ThirdParty-8/platforms/linuxArm64GccDPInt32/scotch_6.0.9/include/openmpi-system
    ptscotch libs in /home/aleix/OpenFOAM/ThirdParty-8/platforms/linuxArm64GccDPInt32/lib/openmpi-system

========================================
Build Metis decomposition
    optional component Metis was not found

========================================
Done ThirdParty Allwmake
========================================

aleix@ub-pi4:~/OpenFOAM/ThirdParty-8$ cd ..
aleix@ub-pi4:~/OpenFOAM$ cd ..
aleix@ub-pi4:~$ cd OpenFOAM/aleix-8/run/pitzDaily/
aleix@ub-pi4:~/OpenFOAM/aleix-8/run/pitzDaily$ paraFoam
FATAL ERROR: The official reader module for OpenFOAM data does not exist on
your system. This means that the version of ParaView you are using was not
compiled with OpenFOAM, or distributed with a packaged version of OpenFOAM.

For information on packaged versions of OpenFOAM/ParaView and compilation of
OpenFOAM/ParaView, see https://openfoam.org/download

Alternatively, you might be able to view your OpenFOAM data with the reader
module provided with ParaView by running:
    paraFoam -builtin

aleix@ub-pi4:~/OpenFOAM/aleix-8/run/pitzDaily$
(0011610)
wyldckat   
2020-10-15 15:09   
???? But... didn't the "foam" command work?

Then explicitly run:

    cd ~/OpenFOAM/OpenFOAM-8
    ./Allwmake
(0011611)
aleixandre   
2020-10-15 15:52   
My fault ¡
i ran ./Allwmake in /ThirdParty dir, now I run it in /OpenFOAM/OpenFOAM-8 and once the process finish everything is working perfectly ¡¡
Thanks for your great support ¡¡

One last question (I hope), if I create another user, will this new user to run the program? or do I have to do something in addition?

I think I should have installed the program in /Opt or /usr/local but now I dont know ....

Thanks again
(0011612)
wyldckat   
2020-10-15 18:14   
You're free to test things for yourself, there is no additional licensing cost here ;)

In principle, you can either copy or move the "~/OpenFOAM/*" subfolders to another location. All that needs to then be done is to correct the ownership and file permissions at the new location.
Furthermore, if users need to recompile something, it might not work all that well... and I'm not sure how it affects the built ParaView...
(0011613)
wyldckat   
2020-10-15 18:36   
So conclusions from this long thread of issues:

1- The additional argument "VTK_USE_SYSTEM_PNG:BOOL=ON" is likely to be needed to build ParaView on ARM based processors, because VTK relies on its own PNG copy of libpng which might not support properly ARM. The people at VTK development line are apparently aware of this, given its occurrence in the their issue tracker, so this seems to be a workaround needed on those systems.

    An alternative to auto-add in "etc/tools/ParaViewFunctions" when this option is needed, is by detecting if "ParaView-*/VTK/ThirdParty/png/vtkpng/arm" doesn't exist yet and the CPU is an ARM processor...

2- 13GB of RAM + memory swap space is needed for the current chemistry stack in OpenFOAM, as Henry mentioned.


@Chris: It would be nice to have the RAM/swap memory minimum requirement mentioned somewhere at one or more pages in https://openfoam.org/download/source/
(0011614)
aleixandre   
2020-10-15 19:08   
One more time, thanks a lot for your great support, I hope this also may help others using ARM processors to install and use this program.

 :-)

Thanks, Aleixandre
(0011629)
chris   
2020-10-18 15:01   
@wyldckat
Could you suggest some text for the 13 GB memory requirement?
It is not clear to me whether it relates to RAM, swap, the sum of (RAM + swap).
I have not followed that issue so just don't know.
(0011630)
wyldckat   
2020-10-19 11:41   
@Chris OK, here's what I can come up with within a couple of minutes:

   The latest developments in the chemistry libraries rely on fairly complex C++ templating, which demands a substantial amount of memory during compilation. It's advisable to have around 24GB of RAM+swap memory space, in order to be able to fully compile OpenFOAM. There are several ways to increase swap memory space, where the suggested search keywords are as follows: linux create swap space file
(0011631)
chris   
2020-10-19 14:16   
@wyldckat
I thought it was 13 GB?
(0011632)
wyldckat   
2020-10-19 14:44   
@Chris Sorry, hold on...

@aleixandre Did your machine already have a swap size of 8GB on the system, so that you still needed to add 6GB extra, or did the machine not have swap?
(0011633)
aleixandre   
2020-10-19 16:50   
hi,
the machine I used (Raspberry Pi 4B) came with 8GBs so I did manage to swap and extra 6GB (total 14GBs)
I did:
sudo fallocate -l 6G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfil
sudo swapon /swapfile
sudo swapon --show
sudo free -h

hope this helps
Let me know if need something else
(0011634)
wyldckat   
2020-10-19 19:38   
@aleixandre: Many thanks!

@Chris: So it is at least 13GB RAM+swap... but adding a few more GB to reach the next multiple of 4, in order to give a bit of extra space for future updates of the chemistry code... here is the revised text:

    The latest developments in the chemistry libraries rely on fairly complex C++ templating, which demands a substantial amount of memory during compilation. It's advisable to have around 16GB of RAM+swap memory space, in order to be able to fully compile OpenFOAM. There are several ways to increase swap memory space, where the suggested search keywords are as follows: linux create swap space file
(0011636)
henry   
2020-10-20 14:34   
Resolved by commit 218f49416d26264af7e84df7cbebca25ad43a172:

    chemistryModel: Split chemistrySolvers.C, chemistryReductionMethods.C and chemistryTabulationMethods.C
    
    to reduces the memory requirement for compilation and speed-up parallel
    compilation.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3567 [OpenFOAM] Bug block always 2020-10-09 11:49 2020-10-14 16:05
Reporter: skwde Platform: Unix  
Assigned To: OS: Other  
Priority: normal OS Version: (please specify)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: cannot create $FOAM_RUN direcotry in docker container
Description: I am on a fresh centos7.7 Virtual Machine with linux kernel 3.10.0-1127.19.1.el7.x86_64.
I installed docker from the docker repository.

I follow the instructions, e.g. on https://openfoam.org/download/6-linux/

The container starts fine but I cannot do step 6:
mkdir -p $FOAM_RUN

It always triggers
mkdir: cannot create directory '/home/openfoam/run': Permission denied
Note, it doesn't matter if i start openfoam6-linux as root or my standard user.
I have the same issue with openfoam7-linux and openfoam8-linux.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011594)
wyldckat   
2020-10-14 13:34   
I haven't tested on CentOS 7.7, but have tested it on Ubuntu 20.04. My guess is that there is an issues associated to SELinux, for which instructions are provided here: https://docs.docker.com/storage/bind-mounts/#configure-the-selinux-label

@skwde: Please edit the file "/usr/bin/openfoam8-linux" (or similar) and find this line near the end:

    -v $MOUNT_DIR:$HOME_DIR \

Then change it to this:

    -v $MOUNT_DIR:$HOME_DIR:z \
(0011595)
skwde   
2020-10-14 13:54   
@wyldckat Thanks for your reply. Unfortunately this didn't solve the issue.

I also tried to temporarily disable selinux (via setenforce 0), but I still face the same issue.
Any other ideas?
(0011598)
wyldckat   
2020-10-14 15:24   
Without having to install CentOS 7.7 on a VM myself, more details are needed... the first few that come to mind are:

1. Knowing what the following command gives you when inside the container (when you run the launching script):

    ls -ld $HOME
    echo $USER

2. Seeing what you see when the container finishes starting up... it should give additional error/warning messages.
(0011599)
skwde   
2020-10-14 15:41   
Below the output you asked for. Notebly $USER is not set.
export USER=openfoam does not solve the issue.
id reveals that the centos uid and gid are correctly matched to the openfoam user / group.

Besides, startup does not show any errors.

1.
OpenFOAM-6(1) ls -ld $HOME
drwxr-xr-x. 2 openfoam openfoam 2048 Oct 9 08:18 /home/openfoam
OpenFOAM-6(2) echo $USER

OpenFOAM-6(3)

2.
$ openfoam6-linux
Launching /usr/bin/openfoam6-linux
User: "<MY CENTOS USER>" (ID <MY CENTOS UID>, group ID <MY CENTOS GID>)
Welcome to the OpenFOAM v6 Docker Image

Provides bash terminal with OpenFOAM 6 and ParaView 5.6.0

Produced and maintained by CFD Direct (https://cfd.direct), on behalf of the
OpenFOAM Foundation (https://openfoam.org), the owner and distributor of
OpenFOAM as free, open source software under the General Public Licence v3.

Further Resources:
* OpenFOAM User Guide: https://cfd.direct/openfoam/user-guide
* C++ Source Guide: https://cpp.openfoam.org
* OpenFOAM Training: https://cfd.direct/openfoam-training
* Running in the Cloud: https://cfd.direct/cloud
* Issue (Bug) Reporting: https://bugs.openfoam.org
* Subscribe to Newsletter: https://cfd.direct/news
* Contributors to OpenFOAM: https://openfoam.org/dev/contributors

OpenFOAM-6(1)
(0011600)
wyldckat   
2020-10-14 15:57   
It's not clear from this... without a noticeable detail, it's nearly impossible to diagnose the issue without trying it myself...

The best I can do at the moment is to point you to step-by-step building instructions, provided by the community for OpenFOAM 6 + CentOS 7.5: https://openfoamwiki.net/index.php/Installation/Linux/OpenFOAM-6/CentOS_SL_RHEL#CentOS_7.5_.281804.29

This issue seems to be related to Docker and CentOS, which mostly falls outside of the OpenFOAM Foundation issue tracker's objectives. Mounting the path of a host's user folder within the Docker seems the main issue.

- Either it's being signalled in the "/var/log/audit/*" files...
- Or in some of Docker's own log files...
(0011601)
skwde   
2020-10-14 16:05   
Alright, thanks a lot for your help anyhow.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3569 [OpenFOAM] Patch minor sometimes 2020-10-13 07:57 2020-10-13 10:25
Reporter: tniemi Platform:  
Assigned To: will OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: Patch to fix a bug in general distribution for Lagrangian
Description: In the copy constructor of general distribution, https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/src/lagrangian/distributionModels/general/general.C, the cumulative-Switch and meanValue-scalar are not being copied and this causes issues with steady tracking.

Here is a patch which adds the missing copy calls.

The fix should also be applied to OF-8.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch.diff (560 bytes) 2020-10-13 07:57
https://bugs.openfoam.org/file_download.php?file_id=3067&type=bug
patch-2.diff (561 bytes) 2020-10-13 07:59
https://bugs.openfoam.org/file_download.php?file_id=3068&type=bug
Notes
(0011589)
tniemi   
2020-10-13 07:59   
Sorry, attached a wrong diff. Here is the correct one
(0011590)
will   
2020-10-13 10:25   
Thanks, Timo. Resolved in 8 and dev.

https://github.com/OpenFOAM/OpenFOAM-8/commit/5b09ecd3bcfa794c3a87887cfd3b6fd6276dad69
https://github.com/OpenFOAM/OpenFOAM-dev/commit/e326af2b4facb6f78e7163a2497450539a1960ca


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3564 [OpenFOAM] Bug minor always 2020-10-05 02:30 2020-10-05 11:04
Reporter: GCr Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: compiled errors while using DimensionedField<Type, GeoMesh>
Description: When using DimensionedField<tensor, volMesh>, there is compiling error: no matching function for call to ‘T(const Foam::Field<Foam::Tensor<double> >&, const Foam::Field<Foam::Tensor<double> >&)’ Foam::T(result(), *this);
Tags:
Steps To Reproduce: 1.write the following code in createFields.H of the icoFoam application.
    volTensorField Ut = fvc::grad(U);
    DimensionedField<tensor, volMesh> Ud = Ut.internalField();
    Info << Ud.T() << endl;
2.compile and the error occurs.
Additional Information: the Foam::T() global functions in the FieldFunctions.H is declared as:
    template<class Type> void T(Field<Type>& res, const UList<Type>& f);
However, the member function T() of the class dimensionedField<Type, GeoMesh> is defined as:
     template<class Type, class GeoMesh> tmp<DimensionedField<Type, GeoMesh>> DimensionedField<Type, GeoMesh>::T() const
    {
        tmp<DimensionedField<Type, GeoMesh>> result
        (
            DimensionedField<Type, GeoMesh>::New
            (
                name() + ".T()",
                mesh_,
                dimensions_
            )
        );
    Foam::T(result(), *this);
    return result;
    }
where the operator() of the tmp<T> return a const reference of T rather than a non-const reference which is required by Foam::T() global function.
So, I modify the above code:
    Foam::T(result(), *this);
into:
    Foam::T(result.ref(), *this);
After this modification, the compilation can be done successfully.
Attached Files:
Notes
(0011568)
henry   
2020-10-05 11:04   
Resolved in OpenFOAM-dev by commit 077e35dc83a4488f63e5ba65356a0ca6e7ec0c0d
Resolved in OpenFOAM-8 by commit 540d813da95b928ab37722775257b43bf1e58936


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3558 [OpenFOAM] Bug minor always 2020-09-27 02:46 2020-09-29 21:46
Reporter: joegi Platform: opensuse  
Assigned To: henry OS: Other  
Priority: normal OS Version: 15.2  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: cacheTemporaryObjects with complex name
Description: This was already addresed in one update but I think the fix is not complete.

For instance if you try the same cacheTemporaryObjects as in the fix, it won't work if you try to open the field with paraFoam. That is:

    cacheTemporaryObjects
    (
        "((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)"
    );

With the regex option off.

The fix to this is to erase the parentheses in the header of the output file, as,

      object interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p)*magSf;

I think an easy fit to this is to give the user the ability to save the field with a different name such as:

outputName whatever_name;

Of course, in the name the user shouldn't use parentheses at the beginning.

Currently I have a fix using bash utilities but adding this option could be very useful.

By the way, this problem happens with all fields that stars with parentheses or funny characters, eg,

"(betaStar*omega)"
"(nut+nu)"

and so on.

Tags:
Steps To Reproduce: I don't add an example because the developers can use the same one as in the fix.
Additional Information: I dont add an example because the developers can use the same one as in the fix.
System Description
Attached Files: elbow_SIMPLE.tar.gz (19,623 bytes) 2020-09-27 18:37
https://bugs.openfoam.org/file_download.php?file_id=3062&type=bug
controlDict (3,615 bytes) 2020-09-27 19:27
https://bugs.openfoam.org/file_download.php?file_id=3063&type=bug
Notes
(0011528)
henry   
2020-09-27 10:20   
I cannot reproduce the problem as you have specified it, for me the "((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)" object is not written:

writeObjects writeObjects(regExp=off,((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)) write:
--> FOAM Warning :
    From function virtual Foam::wordList Foam::functionObjects::writeObjectsBase::objectNames()
    in file db/functionObjects/writeObjectsBase/writeObjectsBase.C at line 65
    Object "((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)" not found in database. Available objects:

30
(
((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)
GAMGAgglomeration
MRFProperties
.
.
.

In both OpenFOAM-8 and OpenFOAM-dev
(0011529)
joegi   
2020-09-27 14:25   
That is just a warning in the first iteration. After the first iteration, it should work fine.

By the way, that is another issue. But for me it does not matter , it is just a warning that happens at the very beginning.

If you still cannot reproduce the case I can prepare an small example.
(0011530)
henry   
2020-09-27 14:55   
> That is just a warning in the first iteration. After the first iteration, it should work fine.

No, for me the field is never written.
(0011531)
joegi   
2020-09-27 18:37   
You will be able to reproduce the issue with the attached case.

To run the case, type in the terminal:

    $> sh run_solver.sh

It will run simpleFoam only one iteration.


In the time directory 1, you will find the following additional fields:

    kOmegaSST:G
    (omega*yWall)


The only field with issues in paraFoam is (omega*yWall). If you try to open the case with paraFoam, you will get this error:

--> FOAM FATAL IO ERROR:
wrong token type - expected word, found on line 14 the punctuation token '('

file: /home/joegi/my_files/ofcases/elbow_SIMPLE/1/(omega*yWall)/object at line 14.

    From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::word&)
    in file primitives/strings/word/wordIO.C at line 74.

FOAM exiting


To fix the issue, erase the parentheses in the object description of the file (omega*yWall). Now the header should looks like this:

FoamFile
{
    version 2.0;
    format ascii;
    class volScalarField;
    location "1";
    object omega*yWall;
}


By the way, for some reason the field (omega*yWall) is also saved in the time directory 0. You will need to modify or erase this file.

After doing this simple modification, paraFoam will open the new field.

Another issue with paraFoam, is that if you try to apply a filter calculator to the field (omega*yWall), paraFoam will complain. To fix this problem, you will need to rename the file as well. That is, you will need to erase the parentheses in the name of the file.

This is why I think adding the option to save the field with a different name will fix these issues.

In any-case, I think this is not big of a deal (at least for me) because I do the renaming using bash scripting.


Another issue related with this case (but not to the additional fields), is that if you enable the scalarTransport functionObject, the case will crash. I haven't track this issue, maybe is something stupid that I don't see right now.
(0011532)
henry   
2020-09-27 18:47   
> This is why I think adding the option to save the field with a different name will fix these issues.

Can you fund this development or do you know of any company interested in funding it?
(0011533)
joegi   
2020-09-27 18:55   
Yes, we might be able to fund this. How much will be? Can we get in contact via private email?

In any-case, I was checking nearWallFields, and a way around is doing something similar. In this functionObject, we can save the new field using the name UNear (or whatever).

By the way, I checked with OF7 and the case will run with the scalarTransport functionObject. So I think there is something going on there with cacheTemporaryObjects and scalarTransport
(0011534)
henry   
2020-09-27 19:10   
While the case you sent writes (omega*yWall)

    cacheTemporaryObjects
    (
        "((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)"
    );

with the regex option off

still does not write anything, could you send the case setup corresponding to your original report?

> Yes, we might be able to fund this. How much will be? Can we get in contact via private email?

You can contact the OpenFOAM Foundation:

https://openfoam.org/news/funding-2020/
https://openfoam.org/contact/
(0011535)
joegi   
2020-09-27 19:23   
Add the following in controlDict:

cacheTemporaryObjects
(
    "kOmegaSST:G"
    "(omega*yWall)"
    "((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)"
);


Then use the following functionObject,


writeObjects2
{
    type writeObjects;
    libs ("libutilityFunctionObjects.so");

    enabled on;

    writeControl outputTime;

    regExp off;

    objects
    (
        "kOmegaSST:G"
        "(omega*yWall)"
        "((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)"
    );
}


And it should work (at least it is working on my computer).

I will try to reach the foundation using the links provided.
(0011536)
joegi   
2020-09-27 19:27   
Find attached my controlDict
(0011537)
henry   
2020-09-27 20:12   
When I use

functions
{
    #includeFunc writeObjects(regExp=off, "((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)")
}

in the tutorials/incompressible/simpleFoam/pitzDaily case nothing is written.
(0011538)
henry   
2020-09-27 20:15   
commit 081f2d57262b4616658f7ea51cc541eff449eeb0 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Sun Sep 27 20:13:56 2020 +0100

    writeObjectsBase: Append explicit names (regExp = false) directly to the list

resolves the issue with regExp=off
(0011539)
joegi   
2020-09-27 20:31   
can you provide an example on how to use it?

For instance in this case.
(0011540)
henry   
2020-09-27 20:37   
(Last edited: 2020-09-27 20:38)
I put

cacheTemporaryObjects
(
    "((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)"
);

functions
{
    #includeFunc writeObjects(regExp=off, "((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)")
}

in the controlDict of the tutorials/incompressible/simpleFoam/pitzDaily case

(0011541)
joegi   
2020-09-27 21:00   
OK, I see that the commit fix one issue with the regExp expression but does not fix the issue with the names nor the issue of using cacheTemporaryObjects together with scalarTransport .
(0011542)
henry   
2020-09-27 21:29   
(Last edited: 2020-09-27 21:33)
No, I didn't intend for it to change the names, just ensure the field is written which previously it wasn't. Adding code to change the field names is not trivial.

(0011543)
henry   
2020-09-27 21:34   
The issue you have with scalarTransport appears to be independent of the issue reported here as the case fails with scalarTransport with or without cacheTemporaryObjects.
You will need to arrange for some user support.
(0011556)
henry   
2020-09-29 17:24   
commit 06af648dc37a10c02531bc8b9d481995fa41ddc6 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Tue Sep 29 17:21:06 2020 +0100

    writeObjects: Prepend field expression names with "expr"
    
    for example
    
    cacheTemporaryObjects
    (
        "((1|((1|(1|A(U)))-H(1)))-(1|A(U)))"
    );
    
    functions
    {
        #includeFunc writeObjects(regExp=off, "((1|((1|(1|A(U)))-H(1)))-(1|A(U)))")
    }
    
    writes the temporary field with the name
    "expr((1|((1|(1|A(U)))-H(1)))-(1|A(U)))" so that it can be read by paraFoam and
    other post-processing tools.
(0011557)
joegi   
2020-09-29 19:39   
Ok, that seems to be a way around.

However, to make it consistent, I think you should add expr to all temporary fields. For example, if you save the field kOmegaSST:G, expr is not preprend to the field.

Another comment, in the dev version (at least on my installation), paraFoam does not open the field expr((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf) nor the field kOmegaSST:G. Instead, if I use version 8, it works ok.
(0011558)
henry   
2020-09-29 20:04   
> I think you should add expr to all temporary fields.

Why? kOmegaSST:G is not an expression, it does not start with '('.

> paraFoam does not open the field expr((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf)

How should it? it is a surfaceScalarField. How do you open it in OpenFOAM-8?
(0011559)
henry   
2020-09-29 20:53   
I can open an visualise kEpsilon:G in paraFoam OpenFOAM-dev and OpenFOAM-8.

I can visualise the boundary values of expr((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf) in paraFoam in both OpenFOAM-dev and OpenFOAM-8 because it is a surfaceScalarField and is defined on faces.
(0011560)
joegi   
2020-09-29 21:38   
Well, technically speaking I think kOmegaSST:G is an expression as you have the colon punctuation mark there (in my opinion). Even the linux bash will let you know that it is a special character.

As I said, in my installation (OF DEV) I cannot open the fields expr((interpolate(((1|((1|(1|A(U)))-H(1)))-(1|A(U))))*snGrad(p))*magSf) and kOmegaSST:G (and some other fields that I like to access). To make it clear, the fields are not available to postprocess in paraview. OF8 works fine, maybe is something related to the OF plugin, I need to check my installation. Btw, I am not trying to visualize the surface fields, I am just pointing out that they are not available in the drop-down menu or the fields browser (again, in my OF DEV installation).
(0011561)
henry   
2020-09-29 21:45   
kOmegaSST:G is not a mathematical expression it is an identifier.

I do not have any problem viewing these fields in OpenFOAM-dev or 8, the paraFoam reader is the same in both versions.
(0011562)
henry   
2020-09-29 21:46   
Resolved by commit 06af648dc37a10c02531bc8b9d481995fa41ddc6


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3554 [OpenFOAM] Patch minor sometimes 2020-09-23 10:29 2020-09-29 15:16
Reporter: wyldckat Platform:  
Assigned To: will OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: semiPermeableBaffleMassFraction includes a declaration of 'composition(...)' but not the definition
Description: In the file 'src/specieTransfer/derivedFvPatchFields/semiPermeableBaffleMassFraction/semiPermeableBaffleMassFractionFvPatchScalarField.H' is declared:

        static const basicSpecieMixture& composition(const objectRegistry& db);

But it's not defined in the '.C' file what it does. It looks like there was a bit of an incomplete copy-paste from the class 'specieTransferMassFractionFvPatchScalarField' from which 'semiPermeableBaffleMassFractionFvPatchScalarField' inherits from, but this static method seems to be simple enough to not require a redefinition.

Attached is the proposed patch 'proposed_fix_v1.patch' and the respective updated file, namely to remove the declaration from said file.
Tags:
Steps To Reproduce:
Additional Information: Found this when compiling on Windows with MSys2 + GCC 10.2.
Attached Files: proposed_fix_v1.patch (890 bytes) 2020-09-23 10:29
https://bugs.openfoam.org/file_download.php?file_id=3060&type=bug
semiPermeableBaffleMassFractionFvPatchScalarField.H (6,727 bytes) 2020-09-23 10:29
https://bugs.openfoam.org/file_download.php?file_id=3061&type=bug
Notes
(0011521)
wyldckat   
2020-09-23 10:29   
I forgot to mention that this is applicable to OpenFOAM 8 and dev.
(0011551)
will   
2020-09-29 15:16   
Thanks for the report. Fixed in 8 and dev.

https://github.com/OpenFOAM/OpenFOAM-8/commit/a3389546b5b598cf4065b0729b2b4df8b12eeecd
https://github.com/OpenFOAM/OpenFOAM-dev/commit/b0d91b53a70ef8a3450abbfe6a6ad53073ed4815


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3518 [OpenFOAM] Bug major always 2020-07-07 19:24 2020-09-28 06:52
Reporter: jnonnema Platform: Linux  
Assigned To: OS: Scientific Linux  
Priority: high OS Version: 6.3  
Status: new Product Version: 6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Heat balance not closed in quarter of hollow cylinder with anisotropic thermal conductivity in cylindrical coordinate system.
Description: When calculating the steady state temperature distribution in a quarter of a hollow cylinder (end part) with an anisotropic thermal conductivity defined in a cylindrical coordinate system, connected to a cuboid (straight part) with anisotropic thermal conductivity defined in a Cartesian coordinate system, both with uniform volumetric heat generation, more heat is generated within the end part than physically possible (or given at the input).

The cause is within the end part because, when changing the conductivity in the end part to isotropic or anisotropic with the same conductivity in the three directions (r, θ, z), the heat balance is closed. When using an anisotropic conductivity eg (1, 100, 1), probably the wrong kappa value is used when calculating the heat flux within the turbulentTemperatureCoupledBaffleMixed boundary condition.

The same issue was encountered before for the straight part, but changing the kappaMethod from solidThermo to directionalSolidThermo solved that issue for the straight part. For the end part however, this does not solve the issue.
Tags:
Steps To Reproduce: A test geometry was set up to reproduce the issue with three cases:
- Test-case with anisotropic thermal conductivity → with the issue (Issue_Aniso_ani)
- Test-case with isotropic thermal conductivity → no issue (Issue_Aniso_iso1)
- Test-case with isotropic thermal conductivity, but defined as anisotropic with the same conductivity in the three directions → no issue (Issue_Aniso_iso3)

Open test case (Issue_Aniso_ani) and run the ‘Allrun’ file. Afterwards, run the ‘Allpostprocess’ file to check the heat balance:
- Within ‘Issue_Aniso_ani\postProcessing\end\wallHeatFlux\0\wallHeatFlux.dat’ or ‘Issue_Aniso_ani\postProcessing\straight\wallHeatFlux\0\ wallHeatFlux.dat’, it can be seen that the heat flux from ‘end’ to ‘straight’ is respectively 15.56157W or 15.53741W, which is 5.9284W higher than the input value 9.609W
- Within ‘Issue_Aniso_ani\postProcessing\straight\patchAverage(name=s1Conv,T)\0\ surfaceFieldValue.dat’, the area and average surface temperature of the cooled surfaces can be found. Calculating the heat flux with q=hA(T_avg-T_inf)=2000*0.001*( 317.9635-300)=35.927, which is 5.927W higher than the input value of 30W. This value is very close to the excess losses coming from the end part, which shows that the issue is in the end part.

A repetition of the previous steps for both other test-cases with isotropic thermal conductivity in the end part (Issue_Aniso_iso1 and Issue_Aniso_iso3), shows correct results (heat balance closed).
Additional Information: This issue is related to issues:
- 0002127: Volumetric heat source in solid with anisotropic conductivity
- 0002043: turbulentTemperatureCoupledBaffleMixed doesn't get heat fluxes balance in case of anisotropic conductivity
- 0002302: wallHeatFlux utility: wrong calculation of heatfluxes using anisotropic kappa

Some details of the test geometry: the geometry consists of a quarter of a hollow cylinder (end part) with:
- an anisotropic thermal conductivity (1,100,1) defined in a cylindrical coordinate system (r, θ, z)
- inner radius 10mm, outer radius 20mm and height 10mm
- heat generation of 9.6090W
connected to a cuboid (straight part) with:
- anisotropic thermal conductivity (1,1,100) defined in a Cartesian coordinate system (x,y,z)
- height and width of 10mm, length of 50mm
- heat generation of 20.3910W
- top and inner side cooled with convective boundary condition (h=2000W/m²K, T=300K)
All other surfaces are adiabatic.
Additional information:
- solver chtMultiRegionFoam
System Description
Attached Files: Aniso_issue.zip (138,106 bytes) 2020-07-07 19:24
https://bugs.openfoam.org/file_download.php?file_id=3017&type=bug
Notes
(0011513)
michael.mueller-wrd   
2020-09-18 11:55   
do we have any updates on this issue? I ran into this problem, too, using chtMultiRegionFoam from OF version 7 (I may check version 8 as well).

For some solid region, in case of anisotropic thermal conductivity, the output of wallHeatFlux functionObject is quite strange, evidently wrong -- even though the simulation runs fine and overall enthalpy balance is correct.
In the same case, setting an isotropic kappa, also the output of wallHeatFlux functionObject is correct.
(0011526)
henry   
2020-09-25 16:16   
@michael.mueller-wrd

This should resolve the consistency problem with the wallHeatFlux functionObject which previously had NO support for anisotropic thermal conductivity:

commit f15d150ca8daf75906b4952608868399e0ea6dae (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Fri Sep 25 16:09:18 2020 +0100

    chtMultiRegionFoam, heSolidThermo: Moved the solid heat flux model into heSolidThermo
    
    and changed to be an energy implicit correction to a temperature gradient
    based heat-flux. This formulation is both energy conservative and temperature
    consistent.
    
    The wallHeatFlux functionObject has been updated to use a consistent heat-flux
    from the heSolidThermo.

However this does not correct the issue reported here which relates to the incomplete handling of anisotropy in the turbulentTemperatureCoupledBaffleMixed BC. We need funding to work on this issue which requires a rewrite of the handling of anisotropic thermal conductivity.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3555 [OpenFOAM] Bug minor always 2020-09-24 14:41 2020-09-25 17:53
Reporter: lavdwall Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: codedFvPatchFields: codeOptions missing in codeKeys_
Description: Both in codedFixedValueFvPatchFields.C and codedMixedFvPatchFields.C, the "codeOptions" key is missing from codeKeys_. Because of that, codeOptions is not written at write time, which causes problems when restarting a case or when trying to run in parallel after decomposition.

I believe it should be as follows:

template<>
const Foam::wordList
Foam::CodedBase<Foam::codedMixedFvPatchFieldBase>::codeKeys_ =
{
    "code",
    "codeInclude",
    "codeOptions",
    "localCode"
};

This issue also applies to the development version.

I also reported the issue on Github two weeks ago (when this bug reporting platform was down): https://github.com/OpenFOAM/OpenFOAM-8/issues/2
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011523)
henry   
2020-09-24 18:05   
How does the "codeOptions" entry relate to restarting a case? Could you provide details of how to reproduce the problem?

The tutorials/incompressible/simpleFoam/pipeCyclic case runs and restarts without problem, does it restart OK for you?
It contains a codedFixedValue BC:

    inlet
    {
        type codedFixedValue;
        value uniform (1 0 0);
        name swirl;
        code #{
            const vector axis(1, 0, 0);

            vectorField v(2.0*this->patch().Cf() ^ axis);
            v.replace(vector::X, 1.0);
            operator==(v);
        #};
    }
(0011524)
lavdwall   
2020-09-25 07:46   
Dear Henry,

I am sorry, I should have given more information. The problem with restarting occurs if you need to include header files. I have the below code to set a heat flux profile at the wall of a tube. I need to include "basicThermo.H" to be able to use this piece of code. For my case to find that header file, I need to add "-I$(LIB_SRC)/thermophysicalModels/basic/lnInclude" in codeOptions. The case runs perfectly on a single core. However, when I decompose, the codeOptions dictionary is not written so when I try to run the case in parallel, basicThermo.H is not found and it gives an error. The same thing occurs when restarting this case.

It all traces back to the file src/OpenFOAM/db/dynamicLibrary/codedBase/CodedBase.C, which defines which keywords are written at write time. It writes the keywords that are in codeKeys_. So that is why I believe "codeOptions" should be added there, as I explained above.


    wall
    {
        type codedMixed;
        refValue $internalField;
        refGradient uniform 0;
        valueFraction uniform 0;
        name heatfluxprofile;
        code
        #{
            scalarField z(patch().Cf().component(2)-0.444);
            const basicThermo& thermo = this->db().lookupObject<basicThermo>(basicThermo::dictName);
            scalarField kappa(thermo.kappa(patch().index()));
            scalarField grad(z.size());
            forAll(grad, facei)
            {
                grad[facei] = z[facei] < 0.0 ? 0.0 : ((-1.3599*pow(z[facei],6)+42.266*pow(z[facei],5)-505.69*pow(z[facei],4)+3105.4*pow(z[facei],3)-11256.0*pow(z[facei],2)+15684.0*z[facei]+94495.0)*1.0)/kappa[facei];
            }
            this->refGrad() = grad;
        #};
        codeInclude
        #{
            #include "basicThermo.H"
        #};
        codeOptions
        #{
            -I$(LIB_SRC)/thermophysicalModels/basic/lnInclude
        #};
    }
(0011527)
henry   
2020-09-25 16:43   
Resolved by commit 8221b25875c2993823afc70d8032ebc2da5c3002


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3556 [OpenFOAM] Bug trivial N/A 2020-09-24 16:35 2020-09-24 17:40
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Unused Make-folder, interfaceCompression
Description: interfaceCompression https://github.com/OpenFOAM/OpenFOAM-dev/tree/master/src/twoPhaseModels/twoPhaseMixture/interfaceCompression

contains a Make-folder for libinterfaceCompression.so, but this library is not being built and the interfaceCompression.C is already a part of libtwoPhaseMixture.so. Also, the target is FOAM_USER_LIBBIN instead of FOAM_LIBBIN (which was the reason for noticing this). This Make-folder is probably a leftover from testing and could be removed?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011522)
henry   
2020-09-24 17:40   
Resolved by commit a972b208ee717d1c440d0d2ef894732bdaa800c8


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3552 [OpenFOAM] Bug minor always 2020-09-21 10:38 2020-09-23 13:03
Reporter: chrix Platform: GNU/Linux (using Docker on Mac)  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Sampling using 'volFieldValue' doesn't work correctly in parallel
Description: I tried to sample the (entire) pressure field for the 'cavity' case using 'volFieldValue' from the library 'fieldFunctionObjects', but it doesn't work correctly when running in parallel.

After running icoFoam, here's the output:

cavity>> ls processor*
processor0:
0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 constant
processor1:
0 0.1 0.2 0.3 0.4 0.5 constant
cavity>> ls processor0/0.05
p_all-

In other words, it only works for 'processor0'. I think it's reasonable to expect the feature to work for all processors.

I should note that I ultimately want to be able to sample 'cellZones', but I'm assuming that if this problem (using 'regionType all') is fixed, then it will also work for 'regionType cellZone'.
Tags:
Steps To Reproduce: Make a copy of the 'cavity' case.

Add to the end of 'controlDict':

functions
{

    volFieldValue1
    {
        type volFieldValue;
        libs ("libfieldFunctionObjects.so");

        log true;
        writeControl timeStep;
        writeInterval 10;
        writeFields true;

        regionType all;
        operation none;

        fields
        (
            p
        );
    }

}

Add, into cavity/system, the 'decomposeParDict':

/*--------------------------------*- C++ -*----------------------------------*\
  ========= |
  \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
   \\ / O peration | Website: https://openfoam.org
    \\ / A nd | Version: 7
     \\/ M anipulation |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version 2.0;
    format ascii;
    class dictionary;
    note "mesh decomposition control dictionary";
    object decomposeParDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

numberOfSubdomains 2;

method simple;

simpleCoeffs
{
    n (2 1 1);
    delta 0.001;
}

// ************************************************************************* //

Run:

>> blockMesh
>> decomposePar
>> mpirun -np 2 icoFoam -parallel
>> ls processor*
Additional Information:
System Description
Attached Files:
Notes
(0011519)
henry   
2020-09-21 10:58   
Try this is OpenFOAM-dev:

commit 77ee78b47e599cded781a4bc8eda9b8c5ee1b635 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Mon Sep 21 10:55:49 2020 +0100

    functionObjects::volFieldValue: corrected parallel operation of writeFields = true
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3552


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3553 [OpenFOAM] Patch minor sometimes 2020-09-22 16:29 2020-09-22 17:31
Reporter: wyldckat Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Two 'options' files found to need a bit of fixing in multiphaseSystems and solidDisplacementThermo
Description: The following files have the respective issues:

- applications/solvers/multiphase/multiphaseEulerFoam/multiphaseEulerFoam/multiphaseSystems/Make/options

    - It's including folder 'alphaContactAngle' that no longer exists.

- applications/solvers/stressAnalysis/solidDisplacementFoam/solidDisplacementThermo/Make/options

    - it's using 'EXE_LIBS', when it should be using 'LIB_LIBS'

Attached files:

- correcting_options_v1.patch - provides the summary patch for easier review

- correcting_options_v1.tar.gz - provides the two aforementioned files
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: correcting_options_v1.patch (1,508 bytes) 2020-09-22 16:29
https://bugs.openfoam.org/file_download.php?file_id=3058&type=bug
correcting_options_v1.tar.gz (503 bytes) 2020-09-22 16:29
https://bugs.openfoam.org/file_download.php?file_id=3059&type=bug
Notes
(0011520)
henry   
2020-09-22 17:31   
Resolved by commit f3c21b74a894efee565c54da6358fc4e50afcd90


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3551 [OpenFOAM] Bug major always 2020-09-20 04:10 2020-09-21 16:43
Reporter: sjohn2 Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 20.04  
Status: new Product Version: 8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Problem with dynamic (sine - positive/negative) boundary condition on curved / orthogonal patches
Description: I am trying to simulate sinusoidal inlet boundary condition (both flow in and out of
a domain based on cycle time) using codedfixedValue using pimpleFoam . I think there exists some continuity/non orthogonality error at the inlet specifically only on curved patches for structured meshes but also in curved/straight patches for unstructed meshes.
Tags:
Steps To Reproduce: The problem can be clearly observed by running 4 test cases attached in the BUG_SUBMISSION.7z case

1) channel_structured_step_sine
straight channel case with flow in and out of domain from the inlet demonstrating no problem with orthogonal patches and structured mesh


2) channel_structured_curved_inlet_stepsine_flow_into_domain
straight channel with a curved inlet, where flow is sinusoidal but only moves in the domain and doesnot move out. No problem observed here.

3) channel_structured_curved_inlet_stepsine
straight channel with a curved inlet, where flow is set to move out of the domain. Unphysical pressure values observed at the inlet ( needs some non-orthogonal correction
at the inlet ?) and eventually flow moving back into the domain. There exists a problem in this case!!

4) channel_unstructured_stepsine
straight channel with flow moving in and out of the domain, but this unstructured mesh. This time eventhough negative velocity is set at the inlet, positive velocity is
calculated at the cells attached to the inlet.
Additional Information: I think some non-orthogonal correction is required at the inlet for the pressure field for flow moving out of the domain.
Attached Files: channel_structured_curved_inlet_stepsine.7z (975,505 bytes) 2020-09-20 04:12
https://bugs.openfoam.org/file_download.php?file_id=3054&type=bug
channel_structured_curved_inlet_stepsine_flow_into_domain.7z (427,218 bytes) 2020-09-20 04:13
https://bugs.openfoam.org/file_download.php?file_id=3055&type=bug
channel_structured_step_sine.7z (122,507 bytes) 2020-09-20 04:13
https://bugs.openfoam.org/file_download.php?file_id=3056&type=bug
channel_unstructured_stepsine.7z (1,768,103 bytes) 2020-09-20 04:13
https://bugs.openfoam.org/file_download.php?file_id=3057&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3550 [OpenFOAM] Patch minor sometimes 2020-09-18 13:29 2020-09-18 14:54
Reporter: wyldckat Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: 'malloc' in 'wmkdep.l' assumes memory preset to zero, only one situation where it can cause issues
Description: In the file 'wmake/src/wmkdep.l', these lines of code are risky and can cause issues in some situations:

        sourcePath = (char*)malloc(basePos - sourceFile + 1);
        strncpy(sourcePath, sourceFile, basePos - sourceFile);

In essence, the risk here is that 'sourcePath' gets a partial copy of the path on the left of the source file string, but does not assign the null character at the end of the copy.
Here is an example, namely if:

   sourceFile = "singlePhaseTransportModel/singlePhaseTransportModel.H";

then the result will be:

   sourcePath = "singlePhaseTransportModel?";

the '?' refers to the last byte of the 'sourcePath' char array, which is undefined when using 'strncpy', which quoting from here: http://www.cplusplus.com/reference/cstring/strncpy/

    No null-character is implicitly appended at the end of destination if source is longer than num. Thus, in this case, destination shall not be considered a null terminated C string (reading it as such would overflow).

This is usually not a problem in the majority of situations, at least on Linux, since the majority of situations the memory is already all preset to NULL... however, there are a few instances where this isn't true, even on Linux. In my situation, this was triggered on Windows, which usually initializes RAM with non-NULL values (allegedly to assist in catching memory leaks), which revealed this issue.

The proposed solution is to use the attached changes:

  - 'patch_wmkdep_v1.patch' shows the proposed change, namely to use 'calloc', which does initialize memory to zeros of the new array.

  - 'wmkdep.l' for replacing 'wmake/src/wmkdep.l' in OpenFOAM-dev (commit c4f98e7835ce, Sep 17 10:51:29 2020)

I've tested this on Windows and Linux and it does not have any other issues. All other 'malloc's in this code seem to be being used safely, since they are followed by string copy functions that always copy/include the null termination character.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch_wmkdep_v1.patch (424 bytes) 2020-09-18 13:29
https://bugs.openfoam.org/file_download.php?file_id=3052&type=bug
wmkdep.l (12,169 bytes) 2020-09-18 13:29
https://bugs.openfoam.org/file_download.php?file_id=3053&type=bug
Notes
(0011515)
henry   
2020-09-18 13:36   
Using the the fact that calloc initialises the memory is a bit of a hack, wouldn't it be better to set the null character explicitly so that the intent is clear in the code rather than using a side-effect?
(0011516)
wyldckat   
2020-09-18 13:42   
That's what I had initially thought of proposing, namely:

   sourcePath[basePos - sourceFile] = 0;

but then this felt more like a hack than using calloc... even though calloc likely ends up being slower.

There is also the function 'strncpy_s', which is standard as of C11: https://en.cppreference.com/w/c/string/byte/strncpy - quoting:

    Although truncation to fit the destination buffer is a security risk and therefore a runtime constraints violation for strncpy_s, it is possible to get the truncating behavior by specifying count equal to the size of the destination array minus one: it will copy the first count bytes and append the null terminator as always: strncpy_s(dst, sizeof dst, src, (sizeof dst)-1);

Although its usage is a bit more cumbersome to the eye and wasn't standard years ago...
(0011517)
henry   
2020-09-18 13:56   
sourcePath[basePos - sourceFile] = '\0';

would be even more explicit, see

commit 067ab99f0fc238adca948b39687e4301b57c10d4
(0011518)
wyldckat   
2020-09-18 14:54   
@Henry: Perfect, I've tested it on Windows and works as intended.

Marking this issue as resolved in the commit above.

PS: I'm getting rusty... I had forgotten about '\0' being the null character.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3549 [OpenFOAM] Patch minor sometimes 2020-09-18 13:15 2020-09-18 13:32
Reporter: wyldckat Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: 'uint' used in TimeIO.C instead of 'unsigned int'
Description: In the file 'src/OpenFOAM/db/Time/TimeIO.C' is being used the 'uint' type here:

         IOstream::defaultPrecision
         (
            controlDict_.lookup<uint>("writePrecision")
         );

However, 'IOstream::defaultPrecision' is defined as 'unsigned int', as visible here: https://github.com/OpenFOAM/OpenFOAM-dev/blob/def4772281a87a24de61057d4e4a68a7cf2248d9/src/OpenFOAM/db/IOstreams/IOstreams/IOstream.H#L210

           //- Default precision
        static unsigned int precision_;

This does not cause a problem in the majority of compilation environments, given that 'uint' is defined as 'unsigned int' in most cases, but this past week I tripped over this not being a default on all environments, namely while compiling on Windows with GCC+MinGW-w64.

Attached are the following files to change 'uint' to 'unsigned int' in 'TimeIO.C', given that it seems to be the only situation where it's being used in the OpenFOAM library:

  - TimeIO.C - for replacing the one in OpenFOAM-dev (commit c4f98e7835ce, Sep 17 10:51:29 2020), at 'src/OpenFOAM/db/Time/TimeIO.C'

  - patch_uint_v1.patch - shows the proposed patch
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch_uint_v1.patch (470 bytes) 2020-09-18 13:15
https://bugs.openfoam.org/file_download.php?file_id=3050&type=bug
TimeIO.C (14,742 bytes) 2020-09-18 13:15
https://bugs.openfoam.org/file_download.php?file_id=3051&type=bug
Notes
(0011514)
henry   
2020-09-18 13:32   
Resolved by commit 07f6ffa2b8d88ed3d5da8cdf7763aeccab5d7b29


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3546 [OpenFOAM] Bug minor always 2020-09-08 17:04 2020-09-11 12:28
Reporter: jherb Platform: SUSE Linux Enterprise Server 11  
Assigned To: OS: Other  
Priority: normal OS Version: (please specify)  
Status: new Product Version: 7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Use of turbulentMixingLengthFrequencyInlet results in crash if velocity at patch is 0
Description: If turbulentMixingLengthFrequencyBoundedInlet and turbulentIntensityKineticEnergyInlet are used for k and omega boundary conditions on a certain patch and the velocity at this patch is 0 (e. g. setting it by fixedValue to constant 0 over time or by using a table with time dependency with a certain period, where it is 0) then solution of the turbulence field equations will crash due to division by 0 on that patch.

The problem can be fixed by modifying the method turbulentMixingLengthFrequencyInletFvPatchScalarField::updateCoeffs() to be lower bounded by a non-zero value, e.g. by:
this->refValue() = max(sqrt(kp)/(Cmu25*mixingLength_), omegaMin_);
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: patch.diff (1,909 bytes) 2020-09-11 11:13
https://bugs.openfoam.org/file_download.php?file_id=3032&type=bug
bug3546_valueFractionFix.diff (3,967 bytes) 2020-09-11 12:28
https://bugs.openfoam.org/file_download.php?file_id=3033&type=bug
Notes
(0011499)
tniemi   
2020-09-09 06:43   
The same issue also affects turbulentMixingLengthDissipationRateInletFvPatchScalarField, ie. k-epsilon combination. If U is zero in some face or at some time, k will be zero and hence epsilon leading to immediate crash.
(0011500)
will   
2020-09-10 08:51   
There are a bunch of epsilon/k rates in the code, as well as the k^2/epsilon based calculation of the turbulent viscosity, so clipping epsilon and omega only really solves half the problem.

It would be better to change the turbulentIntensityKineticEnergyInlet condition to clip k given a minimum turbulent velocity fluctuation. That would fix all division issues, and a minimum/residual velocity magnitude is a more physically intuitive thing to ask users for than a value of epsilon or omega.

Better still would be to put a lower limit on the ratio of turbulent to laminar viscosity. That would be a nice non-dimensional setting so that it might be possible in some circumstances to set and forget it across multiple cases. The problem with doing this is that it couples the k and epsilon/omega boundary conditions more closely. To do it, the k condition would have to know the mixing length, which would make the BC less general and/or add a lot more logic.

Anyone got any better ideas as to how to apply this clip in as robust and user-friendly way as possible?
(0011501)
tniemi   
2020-09-10 09:11   
Residual value for k would be a simple and effective fix. Maybe it could have a default value of "small", as that is also used by default to bound the cell values of k, epsilon and omega. Could the bound-method be extended to cover also boundary values, as currently I think it only operates on cell values?
(0011502)
tniemi   
2020-09-10 09:14   
Hmm, my mistake, bound already does fix boundaryFieldRef. It has been a while since I encountered this issue, so I don't remeber where the division problem actually occured.
(0011503)
will   
2020-09-10 09:56   
(Last edited: 2020-09-10 09:56)
Yes, bound should sort it. Certainly after the model is corrected then the boundary fields should be clipped appropriately. It's possible that something in the evaluation sequence means that there are zeros hanging about for a bit causing this sort of error (like if something was doing a correctBoundaryConditions earlier on), but I can't identify what this would be, and I can't get a case to trigger it.

@jherb Can you give us a case that reproduces this problem?

(0011504)
tniemi   
2020-09-10 10:12   
I can also see if I can create a test case. When I had this issue, it was quite reproducible. Back then I "solved" the problem by simply forcing the inlet velocity to have a small positive value (it was a custom BC for velocity, with some faces possibly having pure 0). It did depend on the solver though, because if I remeber correctly, if I had p_rgh with fixedFluxPressure, the phi could be a tiny bit outwards, which turned the BCs into zeroGradient mode avoiding the issue.
(0011505)
jherb   
2020-09-10 10:46   
The problem can be reproduced in the $FOAM_TUT/heatTransfer/chtMultiRegionFoam/coolingSphere/ tutorial. Change the value of Uinlet in templates/0/fluid/U to (0 0 0) and the case will crash (tested with OpenFOAM-7):

Time = 0.0015


Solving for fluid region fluid
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab: Solving for Ux, Initial residual = 0.17451096, Final residual = 9.4936014e-07, No Iterations 4
DILUPBiCGStab: Solving for Uy, Initial residual = 0.039102964, Final residual = 5.4949103e-07, No Iterations 4
DILUPBiCGStab: Solving for Uz, Initial residual = 0.35874008, Final residual = 7.5522014e-07, No Iterations 5
DILUPBiCGStab: Solving for h, Initial residual = 0.00090359875, Final residual = 9.720741e-07, No Iterations 1
Min/max T:295.99954 347.99059
GAMG: Solving for p_rgh, Initial residual = 0.52790977, Final residual = 0.0025859984, No Iterations 6
GAMG: Solving for p_rgh, Initial residual = 0.13235302, Final residual = 0.00048298206, No Iterations 4
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 5.1026755e-08, global = 2.5261954e-09, cumulative = 2.5261954e-09
Min/max rho:0.99883892 1.174286
GAMG: Solving for p_rgh, Initial residual = 0.10024547, Final residual = 0.00050102148, No Iterations 6
GAMG: Solving for p_rgh, Initial residual = 0.030951032, Final residual = 3.4537543e-08, No Iterations 13
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 5.9540449e-12, global = 2.4344848e-13, cumulative = 2.5264389e-09
Min/max rho:0.99883891 1.1742855
[1] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[1] #1 Foam::sigFpe::sigHandler(int) at ??:?
[1] #2 ? in "/lib64/libc.so.6"
[1] #3 Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) at ??:?
[1] #4 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::operator/<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<double, Foam::fvPatchFi
eld, Foam::volMesh> > const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[1] #5 Foam::kOmegaSST<Foam::eddyViscosity<Foam::RASModel<Foam::EddyDiffusivity<Foam::ThermalDiffusivity<Foam::CompressibleTurbulenceModel<Foam::fluidThermo> > > > >, Foam::EddyDiffusivity
<Foam::ThermalDiffusivity<Foam::CompressibleTurbulenceModel<Foam::fluidThermo> > > >::correct() at ??:?
[1] #6 ? at ??:?
[1] #7 __libc_start_main in "/lib64/libc.so.6"
[1] #8 ? at /usr/src/packages/BUILD/glibc-2.11.3/csu/../sysdeps/x86_64/elf/start.S:116

Using a modified and bounded version of the turbulentMixingLengthFrequencyInlet boundary condition fixes the problem, i.e. the one line modification given in bug description above.
(0011506)
will   
2020-09-10 11:24   
OK, thanks. The problem is that the BC isn't getting overridden by the bound operation because it is of mixed type and mixed BC-s aren't affected by assignment.

So, I reckon we're back at the idea of clipping the boundary condition itself.

It would be nice for the BC-s to clip using kMin/epsilonMin/omegaMin settings from the model; that would be logical and would save any additional input. I can't see how we'd access them, though. They are not part of the momentumTransport interface and nor should they be. We'd need another layer.

Lots of options, all of which imperfect.
(0011507)
tniemi   
2020-09-11 10:47   
I had time to investigate this a bit more and yes, the problem is that the bound does not work. In this case, as the BCs are derived from inletOutlet, they actually have a non-empty assignment operator, but it does not help because refValue() is zero and valueFraction() is one so the set value is ignored.

What if the k, epsilon, omega would have their own override of the operator=, which would just put the given value there?
(0011508)
tniemi   
2020-09-11 11:13   
I tested this minimal patch for just k and it lets the coolingSphere-tutorial to run.
(0011509)
will   
2020-09-11 12:28   
(Last edited: 2020-09-11 12:28)
Interesting. Thanks for the patch. I don't think we want to fix it that way, but it's helped me understand this some more.

None of this should be necessary. `phip` should be zero when `Up` is zero, so the `1 - pos0(phip)` thing that inletOutlet does for the value fraction should evaluate as zero, so the value should get overwritten on assignment. If you print out values for this case, though, `Up` is zero, but `phip` has some round off error in it. That's what's causing this.

This patch also fixes the problem. It makes sure the value fraction is zero when the velocity is zero. Again, though, ideally we wouldn't want to fix it this way. `phip` should be exactly zero here.

It's the buoyancy formulation. Something about it is accumulating error into `phip`. If you turn the gravity off, the problem also goes away.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3541 [OpenFOAM] Bug minor always 2020-08-31 09:08 2020-09-03 14:37
Reporter: michael.mueller-wrd Platform: GNU/Linux  
Assigned To: will OS: centOS  
Priority: low OS Version: (please specify)  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: foamListTimes not working for collated decomposition
Description: The tool foamListTimes raises an error in case of a having a simulation which was run with collated fileHandler (e.g. producing directory "processors192").
I would assume that the line:
$> foamListTime -fileHandler collated -processor
should work, but apparently it looks for "processor0" only.

I am still using version 7, but the same error happens in case of version 8.
Tags:
Steps To Reproduce: Use collated fileHandler in any decomposed tutorial case, and try to get results output directories with foamListTimes...
Additional Information:
System Description
Attached Files:
Notes
(0011486)
ZhangYan   
2020-09-02 21:57   
Hi,
Maybe you can try my version of foamListTime:
https://github.com/ZhangYanTJU/ZYfoamListTimes
(0011487)
michael.mueller-wrd   
2020-09-03 09:36   
Thanks for the reply, but I would think this may/should be solved [more handily] in the general tool version...
(0011488)
henry   
2020-09-03 12:10   
Try commit a7f185eec200791fc0bd9fa7f0b60bce90c1f3ef in OpenFOAM-dev
(0011489)
will   
2020-09-03 14:37   
Confirmed that this now works. In addition the following commit also fixes usage of the "-rm" option when using the collated file handler.

https://github.com/OpenFOAM/OpenFOAM-dev/commit/ec858fe59df5fbe49a4184dbea5660af78961105


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3537 [OpenFOAM] Bug minor always 2020-08-21 15:34 2020-08-25 17:02
Reporter: millszg Platform: x86-64  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: faceAgglomerate hangs for certain values of nFacesInCoarsestLevel and featureAngle in parallel
Description: faceAgglomerate will occasionally hang for certain values of nFacesInCoarsestLevel and featureAngle. This only occurs when running in parallel, and the same values that cause it to hang for a certain number of processors will work for a different number of processors. Increasing nFacesInCoarsestLevel will sometimes alleviate it, but oftentimes it needs to be increased so much that very little agglomeration is actually occurring. In runs where the program hangs, it will always print "Agglomerating patch : patch_name" at least one time, but will not always print for each patch being agglomerated. Keeping everything the same, but rearranging the order of patches in the viewfactorsDict file will usually lead to the programming hanging after outputting "Agglomerating patch..." for a different patch. From what I have tested, this occurs in OpenFOAM 6, 7, 8 and dev. I have had this issues with multiple different meshes and on different computers. From what I have found, this is actually caused by a bug in the pairPatchAgglomeration class (see additional information for explanation).
Tags:
Steps To Reproduce: A case which will reproduce the error is attached. It is a single region of a multiregion case, so some of the boundaries are mappedWall. This error was occurring with the entire multi-region mesh was included in the case folder, so the use of mapped walls without the patch being mapped to is not the cause of the issue. The mesh has already been generated and calling faceAgglomerate will cause it to hang. The culprit seems to be innerGas_to_holderBase. When nFacesInCoarsestLevel for the patch is set to 7000, faceAgglomerate hangs. When it is increased to 10000, it will complete successfully. When the innerGas_to_holderBase is the first in the list of patch dictionaries in viewFactorsDict, faceAgglomerate seems to hang on innerGas_to_retort. When it's the fourth dictionary (between innerGas_to_tempDisks and innerGas_to_retort), faceAgglomerate seems to hang on innerGas_to_retortInlet.
Additional Information: From debugging it appears the problem is in the pairPatchAgglomeration class. In the agglomerate() function, at least one process hangs while the rest continue, causing the program to be unable to continue. This seems to happen in the do-while loop where the agglomOK variable for processes that hang remains false, while it is set to true for the other processes and they complete the function. The issue seems to be resolved by adding in a call to reduce the agglomOK variable with an orOp operation the reduce operation for nCoarseFaces on line 412 of pairPatchAgglomeration.C (in version 8). I have attached a copy of pairPatchAgglomeration.C that I am using, which is no longer causing the error for me.
System Description
Attached Files: pairPatchAgglomeration.C (15,853 bytes) 2020-08-21 15:34
https://bugs.openfoam.org/file_download.php?file_id=3029&type=bug
Notes
(0011478)
henry   
2020-08-25 17:02   
Thanks for the report and correction, I agree that with the current rather convoluted logic an additional reduction is needed

Resolved in OpenFOAM-8 by commit dd46ea14cf84c7d19a07f2f8d633d7c74025d5dd
Resolved in OpenFOAM-dev by commit 2ad3fa242aa2c0c4de9cab5fbb275df093e3ac29


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3538 [OpenFOAM] Bug minor always 2020-08-24 11:46 2020-08-24 12:00
Reporter: Tiberias_ Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: PressureDifferencePatch gives missing keyword error due to missing semicolon in .cfg
Description: When running a case with #includeFunc pressureDifferencePatch in Version 8, I get the error:

--> FOAM FATAL IO ERROR:
keyword operation is undefined in dictionary "...

The keyword "operation" is defined in pressureDifference.cfg which is included by pressureDifferencePatch.cfg.
In pressureDifference.cfg the entry "operation subtract;" is defined but i guess the error occurs due to a missing semicolon after the previous entry "writeInterval 1"
When I add the semicolon the case will run without error.

The semicolon is already missing in version 7 but the keyword "operation" changed position from top to right after the "writeInterval" keyword, so in version 7 the bug was not recognized.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011475)
henry   
2020-08-24 12:00   
Resolved by commit aac9bf5c932141ef70582e0db651eabcb88e55e7


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3534 [OpenFOAM] Bug major always 2020-08-17 08:59 2020-08-18 14:13
Reporter: peltonp1 Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 14.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: The UList::reverse_iterator does not behave like a reverse iterator
Description: The operator ++ and -- for the UList::reverse_iterator shifts the pointer to the wrong direction causing confusing behaviour. For instance, this disables the use of many of the std::algorithms (such as find_if, count_if, count etc) with reverse iterators since they run into an infinite loop. For a reverse iterator it would be more natural that the ++ operator shifts the pointer to the opposite direction as in the forward_iterator.

Tags:
Steps To Reproduce: using namespace Foam;

    std::vector<int> v_std = {1, 10, 3, 5};
    DynamicList<int> v_of(4, int());

    std::copy(v_std.begin(), v_std.end(), v_of.begin());
    CHECK(v_of[1] == 10);

   //this prints the std::vector in a reverse order
    for (auto it = v_std.rbegin(); it != v_std.rend(); it++){
        Info << *it << endl;
    }
 
    //this is an infinite loop as the pointer is always shifted right
    for (auto it = v_of.rbegin(); it != v_of.rend(); it++){
        Info << *it << endl;
    }
    
    //this fails because of an infinite loop
    int number_of_ones = std::count(v_of.rbegin(), v_of.rend(), 1);
    Info << number_of_ones << endl;

Additional Information: Fix: Return a std::reverse_iterator from the UList::rbegin/rend (and possibly some other containers)
System Description
Attached Files: Test-List.C (6,370 bytes) 2020-08-18 11:13
https://bugs.openfoam.org/file_download.php?file_id=3027&type=bug
Notes
(0011459)
henry   
2020-08-17 10:25   
> For a reverse iterator it would be more natural that the ++ operator shifts the pointer to the opposite direction as in the forward_iterator.

This doesn't seem logical to me, the -- operator should be used to reduce the pointer.

Note that I wrote the containers in OpenFOAM before STL was developed and while there has been some attempt to update them over the years to make them STL compliant this is a lot of work without funding and hence not complete.

> Fix: Return a std::reverse_iterator from the UList::rbegin/rend (and possibly some other containers)

Did you try this approach? It is not clear to me how it would work, could you send the version of UList you have developed which returns std::reverse_iterator?
(0011460)
peltonp1   
2020-08-17 10:51   
I understand that the actual operation ++ shifting pointer to left is counter intuitive, but imo it would be more safe to not provide a reverse iterator at all if it behaves like a forward iterator. I actually encountered this while trying to call std::find_if on a array I knew was sorted with a reverse iterator. I did not make any adjustments to UList, instead I call the algorithms like this:
///
///@brief Converts an iterator to a reverse iterator
///
///@tparam InputIt input iterator type
///@param i the iterator to convert
///@return std::reverse_iterator<Iter> a reverse iterator
/// with ++ and -- operators shifting to left and right, respectively.
///
template<class InputIt>
std::reverse_iterator<InputIt> make_reverse(InputIt i){
    return std::reverse_iterator<InputIt>(i);
}
auto rbegin = make_reverse(problems.end());
auto rend = make_reverse(problems.begin());
//... do stuff



For a fix in the UList, without trying, I guess just defining the reverse iterator as:

// STL reverse_iterator (not really -Petteri)

        //- Reverse iterator for reverse traversal of UList
       // typedef T* reverse_iterator; //old one
       typedef std::reverse_iterator<iterator> reverse_iterator; //new one

and implemeting the functions as:

template<class T>
inline typename Foam::UList<T>::reverse_iterator
Foam::UList<T>::rbegin()
{
    return reverse_iterator(end());
}

would fix the issue.
(0011461)
henry   
2020-08-17 11:05   
(Last edited: 2020-08-17 11:18)
I just quickly tested your proposal and it works, many thanks for the idea. I will check the other components as well, const iterators rend etc.

(0011462)
henry   
2020-08-17 11:38   
(Last edited: 2020-08-17 11:42)
I got const_reverse_iterator to work


        //- Reverse iterator for reverse traversal of constant UList
        typedef std::reverse_iterator<const_iterator> const_reverse_iterator;


template<class T>
inline typename Foam::UList<T>::const_reverse_iterator
Foam::UList<T>::crbegin() const
{
    return const_reverse_iterator(cend());
}

template<class T>
inline typename Foam::UList<T>::const_reverse_iterator
Foam::UList<T>::crend() const
{
    return const_reverse_iterator(cbegin());
}

template<class T>
inline typename Foam::UList<T>::const_reverse_iterator
Foam::UList<T>::rbegin() const
{
    return const_reverse_iterator(cend());
}

template<class T>
inline typename Foam::UList<T>::const_reverse_iterator
Foam::UList<T>::rend() const
{
    return const_reverse_iterator(cbegin());
}

(0011463)
peltonp1   
2020-08-17 12:14   
Very good! Thanks for the quick reply and patch.
(0011464)
henry   
2020-08-17 14:06   
Try this:

commit 17c40d2aa57b1f922cdddc315d8cf3471c9bc600 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Mon Aug 17 14:04:42 2020 +0100

    UList,FixedList: Updated reverse_iterators for STL compliance
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3534
(0011465)
peltonp1   
2020-08-18 11:13   
I tested the fix and it appears to be working. The applications/test/List/Test-List.C I used is attached. It fails before the aforementioned commit^.
(0011466)
henry   
2020-08-18 14:13   
Resolved by commit 17c40d2aa57b1f922cdddc315d8cf3471c9bc600


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3530 [OpenFOAM] Bug text always 2020-08-10 11:08 2020-08-13 12:25
Reporter: ekhcsar Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: Documentation of thermalBaffles requires adaptation to OpenFOAM v8
Description: The documentation of the thermalBaffles requires adaptation to OpenFOAM v8:

1D (https://cpp.openfoam.org/v8/classFoam_1_1compressible_1_1thermalBaffle1DFvPatchScalarField.html#details):
- compressible::thermalBaffle1D<hConstSolidThermoPhysics>; --> compressible::thermalBaffle1D<eConstSolidThermoPhysics>;
- Cp --> Cv
- bonus: add an entry for value to <slavePatchName>

3D (https://cpp.openfoam.org/v8/classFoam_1_1compressible_1_1thermalBaffleFvPatchScalarField.html#details):
- delete kappa
- hConst --> eConst
- sensibleEnthalpy --> sensibleInternalEnergy
- Cp --> Cv
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011450)
henry   
2020-08-10 14:14   
This should be resolved by commit 95af33515a74ce95eaff2710215dd3f037329be4
(0011456)
ekhcsar   
2020-08-13 11:58   
Looks good except that I think the change from compressible::thermalBaffle1D<hConstSolidThermoPhysics> to compressible::thermalBaffle1D<eConstSolidThermoPhysics> is still missing.
(0011457)
henry   
2020-08-13 12:25   
Resolved by
commit 944b982bb35314911fbc5c2bb3216e3f22440719 and 95af33515a74ce95eaff2710215dd3f037329be4


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3527 [OpenFOAM] Patch minor always 2020-08-05 02:45 2020-08-07 10:27
Reporter: handrake0724 Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: incorrect gnuplot option specified in gnuplotGraph::write
Description: It seems like gnuplotGraph writer is using incorrect option for offset.
I am using gnuplot 5.2 and the usage for title read for example ,

set title {"<title-text>"} {offset <offset>} {font "<font>{,<size>}"}
               {{textcolor | tc} {lt <line_type> | default}} {{no}enhanced}

<offset> value should be used with offset keyword but in the code, <offset> value is used without offset keyword.
As a result, the result file, *.gplt does not work correctly.

set output statement writes contents if set term statement is active.
so current setup in the code write a empty file since set term is commented.
as a suggestion, how about svg instead of postscript for set term because ps representation sometimes does not show as intended depending on viewer implementation, especially MS Windows

Applying these changes, the diff would be as follows:

 void Foam::gnuplotGraph::write(const graph& g, Ostream& os) const
 {
- os << "#set term postscript color" << endl
- << "set output \"" << word(g.title()) << ".ps\"" << endl
- << "set title " << g.title() << " 0,0" << endl << "show title" << endl
- << "set xlabel " << g.xName() << " 0,0" << endl << "show xlabel" << endl
- << "set ylabel " << g.yName() << " 0,0" << endl << "show ylabel" << endl
+ os << "#set term svg" << endl
+ << "#set output \"" << word(g.title()) << ".svg\"" << endl
+ << "set title " << g.title() << " offset 0,0" << endl << "show title" << endl
+ << "set xlabel " << g.xName() << " offset 0,0" << endl << "show xlabel" << endl
+ << "set ylabel " << g.yName() << " offset 0,0" << endl << "show ylabel" << endl
         << "plot";
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011445)
henry   
2020-08-05 12:02   
I can reproduce the issues on the boxTurb16 case. It is setup to display the graph from which you can write to any of the supported formats. I can change it to write postscript as this is the most common format but I can't assume everyone would rather have SVG. Maybe it would be better not to assume the format and leave the "set term" out. Alternatively users can easily introduce their own variants of the gnuplot writer to set the format and formatting anyway they want.
(0011447)
henry   
2020-08-07 10:27   
Resolved by commit cbad0026974a8613df43b4cf2b532fb6be6eb376


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3528 [OpenFOAM] Bug minor always 2020-08-06 06:36 2020-08-06 14:44
Reporter: shildenbrand Platform: HP Workstation Z640  
Assigned To: will OS: Debian  
Priority: normal OS Version: 9.5  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Postprocessing tool "particleTracks" does not work
Description: Probably since after commit 43d66b5 particleTracks does not work anymore.
First the tool is running but finds no particles before it exits with a segfault.
Tags:
Steps To Reproduce: Try $FOAM_TUTORIALS/lagrangian/reactingParticleFoam/verticalChannel
./Allrun
particleTracks
Additional Information:
System Description
Attached Files:
Notes
(0011446)
will   
2020-08-06 14:44   
Thanks for reporting. The cloud names just hadn't been updated in the particleTracks configurations. Fixed by the following commit:

https://github.com/OpenFOAM/OpenFOAM-dev/commit/1eab1b7ffe8c66dfa65cf835f9d4e8fd72491bbb

I also added calls to these utilities to the verticalChannel tutorials' Allrun-s so that they actually get tested, which should prevent this from happening again.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3385 [OpenFOAM] Bug minor always 2019-11-12 15:51 2020-08-05 10:39
Reporter: peth Platform: x86-64  
Assigned To: henry OS: Arch Linux  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: DPMFoam - "SemiImplicit" scheme for the source term gives unphysical fluid velocity distribution around the parcel
Description: Using DPMFoam to investigate a solid particle moving in fluid flow the "SemiImplicit" scheme for the momentum source gives unphysical velocity distribution around the parcel.
To show the phenomenon, a simplified simulation case is attached.
In the simulation a 2D flow flows from the left to the right in a channel. At the beginning one solid particle is positioned with zero velocity at the middle of the channel. Note that the parcel = particle in this case by the "nParticle 1" setting. Due to the small dimensions and fluid velocity, the flow will be laminar. As the particle diameter is also small the fluid drag will be the dominant force on it. This means that over the time the particle has to move with the same speed as the fluid in the channel.
Although the local cell fluid velocity and particle velocity will be nearly the same indeed, this velocity is usually smaller than the surrounding velocity of the fluid flow.
The phenomenon does not exist with the "explicit" momentum source term setting. However, the implicit scheme would be favorable, as the explicit scheme seemed to be unstable at higher particle volume fractions, and worked only with significantly decreased time steps.
The problem can be checked by running the attached simulation with the "SemiImplicit" and "explicit" schemes which can be set at the constant/kinematicCloudProperties file.
The difference between the two technique can be seen by the source code. In the followings I try to summarise it based on my understanding:

In DPMFoam.C the line
    fvVectorMatrix cloudSU(kinematicCloud.SU(Uc));
calls the SU() function of the particle cloud, which can be found in the KinematicCloudI.H. Here the return values of the two options (explicit/implicit) are:

       if (solution_.semiImplicit("U"))
        {
            const volScalarField::Internal
                Vdt(mesh_.V()*this->db().time().deltaT());

            return UTrans()/Vdt - fvm::Sp(UCoeff()/Vdt, U) + UCoeff()/Vdt*U;
        }
        else
        {
            tmp<fvVectorMatrix> tfvm(new fvVectorMatrix(U, dimForce));
            fvVectorMatrix& fvm = tfvm.ref();

            fvm.source() = -UTrans()/(this->db().time().deltaT());

            return tfvm;
        }

where the volScalarField::Internal (DimensionedField) type dUTrans field is the momentum transferred from the parcels to the fluid in the given time step.
1. In the explicit scheme the force in each cell is explicitly given by dividing this momentum with the time step. Later in DPFoam.C it is further divided by the mesh volume to get the volumetric force density with the term "cloudVolSUSu". This term then will be included in the "phicForces" term and added to HbyA (see UEqn.H and pEqn.H). As in this case the "cloudSU" term contains only the explicit source term, which will be set to zero at DPMFoam.C, the cloudSU has no effect in the momentum equation.

2. In the semiImplicit case the second and the third term in the return line "should" cancel out each other in a steady case. I assume that these terms are given to increase the stability based on https://www.cfd-online.com/Forums/openfoam-solving/149682-dpmfoam-interpretation-uceqn-h.html
The return line is given with the type of volScalarField::Internal (DimensionedField). However the function return type is fvVectorMatrix, and at the conversion between the two at fvMatrix.C adds a multiplication with mesh.V() for the source. This is the reason that here the return terms are also divided by the volume.
Later in UcEqn.H the cloudSU() adds only the second (implicit) term to the momentum equation, while the phicForces contains only the first and the third (explicit) terms.
Tags:
Steps To Reproduce: 1. Download and extract the attached simulation folder.
2. Generate the mesh with the ./mesh_gen script.
3. Run the simulation with the ./run script.
4. Check the fluid velocity cell values around the moving parcel.
Additional Information: The simulation was run with OpenFOAM-5.x (manually compiled). The corresponding code for the source term handling in OpenFOAM-7 looks similar, so I assume that the problem will also exist there.
System Description
Attached Files: dpmfoam_source_report.tar.gz (5,012 bytes) 2019-11-12 15:51
https://bugs.openfoam.org/file_download.php?file_id=2824&type=bug
magU.png (16,037 bytes) 2019-11-12 15:51
https://bugs.openfoam.org/file_download.php?file_id=2825&type=bug
dpmfoam_source_report_dev.tar.gz (4,909 bytes) 2019-11-13 16:08
https://bugs.openfoam.org/file_download.php?file_id=2826&type=bug
mag_Uf_injected_particles_orig.png (127,827 bytes) 2019-11-14 19:37
https://bugs.openfoam.org/file_download.php?file_id=2827&type=bug
mag_Uf_injected_particles_corrected.png (102,847 bytes) 2019-11-14 19:37
https://bugs.openfoam.org/file_download.php?file_id=2828&type=bug
mag_Uf_particle_inject_corrected_explicit.png (105,747 bytes) 2019-11-16 13:27
https://bugs.openfoam.org/file_download.php?file_id=2829&type=bug
velocity_profile_compare.pdf (9,522 bytes) 2019-11-16 13:27
https://bugs.openfoam.org/file_download.php?file_id=2830&type=bug
dpmfoam_source_report_dev_centrecloud.tar.gz (11,243 bytes) 2019-11-16 13:27
https://bugs.openfoam.org/file_download.php?file_id=2831&type=bug
Notes
(0010893)
henry   
2019-11-13 11:18   
Have you tried running with outer correctors to update the semi-implicit sources? e.g. set

   nOuterCorrectors 5;

for example.
(0010894)
henry   
2019-11-13 11:22   
I tried to run the case but it fails at start-up:

--> FOAM FATAL IO ERROR:
keyword alpha.water is undefined in dictionary

Could you provide an updated version for OpenFOAM-dev?
(0010898)
peth   
2019-11-13 16:08   
I have compiled the current version of OpenFOAM-dev from GitHub, and corrected the simulation folder accordingly. The new simulation is attached as "dpmfoam_source_report_dev.tar.gz".
Initially the nOuterCorrectors was 1 and now I have checked it with 5 and 10. The fluid velocity is decreased around the parcel in all cases.
(0010899)
henry   
2019-11-13 17:01   
Thanks, I will investigate further.
(0010900)
henry   
2019-11-13 17:17   
Try this:

commit b22545b9315cd72034905474b28e88d90b012583 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://openfoam.org>
Date: Wed Nov 13 17:15:12 2019 +0000

    DPMFoam: Changed the cloud source splitting to handle symmetric semi-implicit sources consistently
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3385
(0010902)
peth   
2019-11-14 19:37   
Thanks for the correction, I have tried it. The velocity field looks much more smooth now, see the attached pictures with some injected particles from the inlet with the original and the corrected solver. (The particles are magnified compared to their real sizes just for the visualization).
If I interpret the modification well, as
    cloudSU.diag()= - Ucoeff/dt
the modified code
     cloudVolSUSu.primitiveFieldRef() = (cloudSU.diag()*Uc() - cloudSU.source())/mesh.V();
means that the explicit (Ucoeff/Vdt * Uc_old) term will be added by the second part (.source()) and also subtracted by the first part (.diag()), so finally in cloudVolSUsu only the (UTrans/Vdt) part remains. I think this term is much smaller than the (Ucoeff/Vdt * Uc_old) part (and it should be almost zero) in the investigated case.
Then the line
    cloudSU.source() = cloudSU.diag()*Uc();
results that in UcEqn besides the implicit source term -fvm::Sp(UCoeff/Vdt, Uc_new) the similar, but explicit source (Ucoeff/Vdt * Uc_old) is also included.
Can you please tell me why this method gives better result than the previous?
(0010903)
henry   
2019-11-14 19:57   
This approach avoids the cell-face splitting error and ensures that the cell parts and the face parts of the source are consistent.
How do the results of the explicit and semi-implicit approach compare for this case?
(0010915)
peth   
2019-11-16 13:27   
I have run the simulation with the corrected code and the explicit scheme. The velocity field and the particle distribution looks similar to the previous one with the semiImplicit scheme, see on the attached picture. The fluid velocity profiles have been compared at x=L/4 (where L is the whole channel length), and they are almost the same (it is shown at the attached pdf).
The two method anyway can provide different results, e.g. when a lot of particles are injected at t=0 to a specific part of the channel with zero velocity (this simulation is also attached). At the beginning the particles have to be accelerated up, which results - for a short time - a locally decreased velocity field. The semiImplicit technique is able to capture this phenomenon, while the explicit (with the given time step size) does not.
(0010919)
henry   
2019-11-18 08:06   
Resolved by commit b22545b9315cd72034905474b28e88d90b012583
(0011442)
will   
2020-07-31 09:49   
Note that commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/43d66b5e7c566e087db187df023f134422ee8a4b has reverted this change by default. The change to the splitting caused significant problems with MPPIC simulations. There is now a keyword in "system/fvSolution.PIMPLE" called "cloudMomentumSplit" which can be set to the following values:

    faceExplicitCellImplicit
    faceExplicitCellLagged
    faceImplicit

The first is the default and causes the artefacts in the velocity field detailed in this report. The second is the fix from commit b22545b9 which removes the artefacts but causes issues in MPPIC simulations. The third is another approach which removes the artefacts and is less troublesome for most MPPIC cases, but the cyclone tutorial still doesn't run. See the following file for more information:

     https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/applications/solvers/lagrangian/denseParticleFoam/denseParticleFoam.C

These choices may be removed in the future if MPPIC is developed to the point of being tolerant to these sort of details. We may also judge that the default needs to be different, so if this is important to you then I recommend you set the control explicitly.

So, this report is still considered fixed, it's just that an additional entry (faceExplicitCellLagged or faceImplicit) is now needed to resolve the issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3525 [OpenFOAM] Bug block always 2020-07-28 12:17 2020-07-29 15:03
Reporter: gfilip Platform: GNU/Linux  
Assigned To: chris OS: Ubuntu  
Priority: high OS Version: 18.04  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Docker script for openfoam-8 fails to launch with permission denied problem
Description: I followed the docker instructions and when trying to launch openfoam-8, I get a permission denied error after the image is downloaded:

-------------------------------------------------------------------
Launching /usr/bin/openfoam8-linux
User: "gfilip" (ID 1001, group ID 1001)
/bin/sh: 1: /entry.sh: Permission denied
-------------------------------------------------------------------

I noticed that this was an issue with the image for openfoam-7 and 5 as reported on this issue tracker, so I suspect it may be the same problem that has to be resolved on the image side of things. I've tried to delete and re-download the image several times but the issue persists.
Tags:
Steps To Reproduce: Download the official docker script and execute per instructions:

sudo sh -c "wget http://dl.openfoam.org/docker/openfoam8-linux -O /usr/bin/openfoam8-linux"
sudo chmod 755 /usr/bin/openfoam8-linux
openfoam8-linux

Additional Information:
System Description
Attached Files:
Notes
(0011439)
wyldckat   
2020-07-29 11:16   
@Chris: As indicated in the description, this issue seems to be the same as reported on https://bugs.openfoam.org/view.php?id=3041 - namely the permissions might still be set to:

   -rwxr-x--- 1 root root 2769 Jul 8 15:50 /entry.sh

namely no one other than root can run the script :(
(0011440)
chris   
2020-07-29 14:47   
Updating container...
(0011441)
chris   
2020-07-29 15:03   
Thanks for reporting the issue. The container is updated with correct permissions on "*.sh" script files.
If there are any further problems, please let us know.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3521 [OpenFOAM] Feature minor always 2020-07-10 15:19 2020-07-21 22:25
Reporter: peksa Platform: x86  
Assigned To: OS: Centos  
Priority: high OS Version: 7  
Status: new Product Version: 7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: EngineTime (CAD) not recognized correctly by functionObjects
Description: In internal combustion engine related solvers (coldEngineFoam and XiEngineFoam) the solver setup (startTime, endTime etc.) respect the engine relevant cranck-angle-degree (CAD) format.

However, run-time functionObjects respect the physical time value (runTime.value()) instead of runTime.timeToUserTime(runTime.value()) based value. In order to make e.g. timeActivatedFileUpdate function to work, user needs to input the update timings in real time which is cumbersome because the values depend on engine setup.

In contrast to above, postProcessing utility "postProcess -func CourantNo" utilizes the engine time based time-step saved under the uniform directory. Hence, mistakenly, utilizes that in the computation of the Courant number even though in that utility the physical time step should be used.

Because this engineTime related bug concerns variety of functionObjects I don't have a satisfactory solution to provide at the moment but I'd like to inquire whether you have ideas how to fix the issue? I could participate to the bug-fixing process if required/preferred.
Tags:
Steps To Reproduce: 1) Copy */tutorials/combustion/XiEngineFoam/kivaTest tutorial
2) add engine time based timeActivatedFileUpdate (fileUpdate1) from below to the controlDict
3) log the output and see that files are updated at the startup only.
4) add physical time based timeActivatedFileUpdate (fileUpdate2) from below to the controlDict
5) log the output and see that files are updated correctly according to the physical time given.

---------------------------------------------------------
    fileUpdate1
    {
        type timeActivatedFileUpdate;
        functionObjectLibs ("libutilityFunctionObjects.so");
        outputControl timeStep;
        outputInterval 1;
        fileToUpdate "$FOAM_CASE/system/controlDict";
        timeVsFile
        (
            (-190 "$FOAM_CASE/system/controlDict")
            (-179 "$FOAM_CASE/system/controlDict")
        );
    }

---------------------------------------------------------

    fileUpdate2
    {
        type timeActivatedFileUpdate;
        functionObjectLibs ("libutilityFunctionObjects.so");
        outputControl timeStep;
        outputInterval 1;
        fileToUpdate "$FOAM_CASE/system/controlDict";
        timeVsFile
        (
            (-1 "$FOAM_CASE/system/controlDict")
            (-0.0197778 "$FOAM_CASE/system/controlDict") // Corresponds -177.75 CA-deg
        );
    }
---------------------------------------------------------
Additional Information:
System Description
Attached Files:
Notes
(0011415)
henry   
2020-07-10 15:46   
Updating all the functionObjects to work with engine time would be a substantial undertaking and currently none of the OpenFOAM sponsors:

https://openfoam.org/supporters/

have expressed any interest in the maintenance of the engine solvers so we would need to secure specific funding for this work.
(0011417)
peksa   
2020-07-12 14:42   
I totally understand the related work-load and requirement of funding.

May I inquire, what kind of solution you would prefer to have for such a problem? Perhaps a separate parameter "-useEngineTime" or replace runTime.value() by timeToUserTime in functionObject control?
(0011418)
henry   
2020-07-12 14:55   
My preference would be for the handling to be automatic and use the UserTime where appropriate.
(0011428)
ZhangYan   
2020-07-21 22:25   
Hi, I've changed timeActivatedFileUpdate to engineTimeActivatedFileUpdate.
Enjoy: https://github.com/ZhangYanTJU/functionObjects


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3519 [OpenFOAM] Feature minor always 2020-07-09 02:49 2020-07-11 17:22
Reporter: albertop Platform: GNU/Linux  
Assigned To: henry OS: Other  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Changes to Intel MPI directory structure
Description: Intel has changed the directory structure of their MPI libraries for versions higher than 18.x.

In versions older than 19, MPI_ROOT needed to point to

<system_dependent_path>/intel/20.0/impi/yyyy.xx.xxx

It now should point to:

<system_dependent_path>/intel/20.0/impi/yyyy.xx.xxx/intel64

This change does not impact OpenFOAM, since it must be set explicitly by users. The following changes however were also made, which impact the OpenFOAM settings:

1) In wmake/rules/General/mplibINTELMPI64, the PLIBS flag should become:

PLIBS = -L$(MPI_ARCH_PATH)/lib/release -lmpi

2) In in OpenFOAM/OpenFOAM-dev/etc/config.sh/mpi, INTELMPI section, the _foamAddLib line should be:

_foamAddLib $MPI_ARCH_PATH/lib/release

The latter path becomes $MPI_ARCH_PATH/lib/debug for debug mode and $MPI_ARCH_PATH/lib/release_mt for the multi-threaded optimized library.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011416)
henry   
2020-07-11 17:22   
Resolved by commit 077138942f3245feb5c16ea2b119e021dd7db58d


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3344 [OpenFOAM] Contribution feature always 2019-09-09 12:23 2020-07-06 21:13
Reporter: Wenyuan Fan Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Issues with turbulence modeling in isothermal VOF solvers
Description: Under the VOF framework, the flow of the isothermal mixture belongs to the variable-density incompressible flow category. For such flows, VOF-based solvers of OpenFOAM fail to construct the correct governing equations for turbulence modeling. varRhoTurbVOF contains a set of newly designed VOF-based solvers which could use the desired governing equations for turbulence quantities.
Tags:
Steps To Reproduce: Details could be found at
https://doi.org/10.1016/j.cpc.2019.106876
and
https://arxiv.org/abs/1811.12580v2
Implementations for different OpenFOAM versions are provided at
https://github.com/wenyuan-fan/varRhoTurbVOF
Additional Information:
Attached Files: OpenFOAM-7-selectable.tar.gz (17,700 bytes) 2019-09-17 10:16
https://bugs.openfoam.org/file_download.php?file_id=2772&type=bug
1_geometry.jpg (250,413 bytes) 2019-09-18 12:48
https://bugs.openfoam.org/file_download.php?file_id=2774&type=bug
2_velocity.jpg (392,201 bytes) 2019-09-18 12:48
https://bugs.openfoam.org/file_download.php?file_id=2775&type=bug
3_slice_velo.jpg (319,880 bytes) 2019-09-18 12:48
https://bugs.openfoam.org/file_download.php?file_id=2776&type=bug
4_slice_interFoam_k.jpg (159,928 bytes) 2019-09-18 12:48
https://bugs.openfoam.org/file_download.php?file_id=2777&type=bug
5_slice_interFoam_rhoTurb_k.jpg (201,674 bytes) 2019-09-18 12:48
https://bugs.openfoam.org/file_download.php?file_id=2778&type=bug
6_slice_varRhoInterFoam_k.jpg (192,973 bytes) 2019-09-18 12:48
https://bugs.openfoam.org/file_download.php?file_id=2779&type=bug
turbulenceDamping.tar.gz (3,446 bytes) 2019-09-19 13:42
https://bugs.openfoam.org/file_download.php?file_id=2781&type=bug
turbulenceDamping.tar-2.gz (3,510 bytes) 2019-09-19 15:15
https://bugs.openfoam.org/file_download.php?file_id=2782&type=bug
Notes
(0010708)
henry   
2019-09-09 12:38   
The flow is treated as incompressible in interFoam and hence the divergence of the mixture velocity is zero so it is valid to use the incompressible form of turbulence models. There are issues with the meaning of shear and turbulence generation in the interface region due to the unphysical nature of interface capturing but using a compressible formulation for the turbulence models does not resolve this.

A more general formulation is provided in compressibleInterFoam in which mixture and separate phase turbulence models are supported, however no special handling for the interface capturing region is provided.
(0010709)
Wenyuan Fan   
2019-09-09 13:23   
Thank you for the quick reply!

I totally agree that the mixture flow is divergence-free, but I do not think it is appropriate to use the "incompressible form of turbulence models" in OpenFOAM. The reason is that such incompressible turbulence models are designed for strict incompressible flows, where the density field is constant (unity in OpenFOAM). However, the density of the mixture is changing with the phase distribution, meaning that the flow is incompressible but with varying density. Therefore, those strict incompressible turbulence models are no longer valid for isothermal VOF solvers.

I also agree with you that there are issues with the meaning of the shear and turbulence generation in the interface region, which are caused by the interface capturing method itself. We do not think our solution could solve all these issues. But, I do believe our solution is advantageous in at least three aspects. First, it is mathematically consistent. Since the flow is variable-density incompressible, we need to consider the varying-density effect in turbulence modeling, which cannot be achieved by using the "incompressible form of turbulence models" in OpenFOAM. Second, it is much less sensitive to mesh refinement, as we described in the paper. Third, it produces better results for the case we discussed in the paper.
(0010710)
henry   
2019-09-09 13:38   
The incompressible turbulence models are valid for each phase away from the interface because each phase is incompressible. In reality the density is a constant in each phase and it is not mathematically consistent to treat the system as a variable density mixture; this is a poor approximation. None of the turbulence models are valid in the interface capturing region and formally special treatment is required there. The current approach in interFoam is particularly robust and has been used successfully by thousands of users for thousands of cases since I created it in the late 90's.

However, if you prefer the approach in which a variable density mixture approach is used for turbulence you can run compressibleInterFoam which support both this form and separate turbulence models for the two phases. It can be run compressible or incompressible in either phase by choosing the appropriate equation of state.
(0010711)
Wenyuan Fan   
2019-09-09 16:17   
To be more accurate and precise, I will use self consistency, instead of mathematical consistency. For a VOF solver, we need to accept all advantages and flaws of VOF, e.g., the favorable mass conservation feature and the questionable interfacial region. Therefore, the two-phase system should be treated as a varying-density mixture as long as the VOF method is used. Concerning the self consistency that I have just mentioned, it simply means we should use the same treatment/assumption in the same solver. For instance, the variable-density effect is considered in the momentum equation, then it should be considered in the turbulence modeling as well. For the same reason, if strict incompressible turbulence models were used, they should be used together with a strict incompressible momentum equation, where the varying-density effect is not considered. However, neither treatment is used in interFoam. I agree with you that we need special treatments for turbulence modeling when it comes to the interfacial region. And this is still a challenging topic.

You are right that one could use compressibleInterFoam as an alternative. We tried this last year and it worked. However, for other VOF solvers that do not have the corresponding compressible versions, this approach will not work.

Anyway, thank you for handling this issue! I really appreciate your enormous contribution to the community.
(0010712)
henry   
2019-09-09 16:30   
Adding another VoF solver which duplicates some of the functionality of compressibleInterFoam introduces substantial maintenance overhead. It would be better if functionality is merged rather than duplicated. Any change to interFoam must preserve the current effective, robust and well tested functionality. It would be possible to add the other turbulence options currently available in compressibleInterFoam to interFoam, i.e. variable density mixture formulation and separate phase turbulence models and this would be easier to maintain than your proposal of having a completely separate solver structure. However given that this functionality is already available in compressibleInterFoam it is not clear how much interest there would be in this work. An alternative would be to make parts of compressibleInterFoam selectable, e.g. the energy equations, and this could then replace interFoam entirely.
(0010713)
henry   
2019-09-09 16:34   
> For instance, the variable-density effect is considered in the momentum equation, then it should be considered in the turbulence modeling as well.

I don't see why this is necessary given that the interface region in erroneous anyway. A better approach would be to add modeling for the interface region which might be based on the variable density or current incompressible formulation or even separate turbulence models for the two phases. Once we have this model we can decide which turbulence formulation should be used.
(0010714)
Wenyuan Fan   
2019-09-10 10:33   
It is true that there will be repetitions if we want to keep both the strict incompressible and the variable-density incompressible solvers. Because the only difference between these two types of solvers is the turbulence modeling part, which only has several lines of codes. Therefore, one possible solution is making the turbulence modeling part selectable. Of course, we need to find a smart way to do it.

Talking about compressibleInterFoam, I think it is another reason why we need to make such changes. Some solvers have two versions, say, incompressible and compressible. To my understanding, this classification enhances the solver performance, but it should not violate the consistency between solvers. For instance, we can use both simpleFoam and rhoSimpleFoam (by choosing the appropriate equation of state) to simulate a flow with constant density. There might be slight difference in the results due to round-off errors. However, these two results should always be numerically equivalent, and the only difference should be that simpleFoam runs faster than rhoSimpleFoam. When it comes to interFoam and compressibleInterFoam, this is not the case. Also, interFoam is not the only solver affected by this issue. For instance, interMixingFoam also has this issue, but we cannot use "compressibleInterMixingFoam" to avoid this problem, because it does not exist.

Regarding the necessity of using consistent formulations for both the momentum equation and the turbulence modeling part, I think it is a requirement for a model that all sub-models should not contradict with each other. Otherwise, the model does not have a solid theoretical basis. I totally agree with you that we need to develop better turbulence models for two-phase flows. However, the current problem is that we only have two solutions, which both look erroneous. One solution is erroneous in a more self-consistent manner than the other in the sense that all the treatments are in line with the basic assumption of VOF. If I have to make a choice between these two, I would select the more self-consistent one.

Anyway, I think it would be beneficial for the community to understand this issue. No matter which solver they choose, it would always be nice if they know the rationale behind it.
(0010716)
henry   
2019-09-10 11:08   
> but we cannot use "compressibleInterMixingFoam" to avoid this problem, because it does not exist.

It would be trivial to create a compressibleInterMixingFoam solver if required, but so far no one has requested or contributed it. However, I am no longer convinced that interMixingFoam or compressibleInterMixingFoam are good approaches and it would be better to solve for mixing in terms of species instead of additional phases which mix. As it happens this would be easier in the compressibleInterFoam framework rather than interFoam because the standard thermo packages used in compressibleInterFoam have composition options.

Given that interFoam has been used successfully for 20years with the current turbulence modeling framework any change to this would need to be validated on a VERY wide range of cases, particularly if a replacement of the current approach is to be considered. How many cases and for what range of problems have you tested the alternative formulations on?
(0010721)
Wenyuan Fan   
2019-09-10 16:38   
I understand the popularity of interFoam, so we need to be very careful with any changes. I also admit that we have only tested our solvers with few cases. Therefore, much more tests are needed. However, this is far beyond our ability, and can be only achieved by efforts from the community. By the way, I have just noticed Issue 0003310, which means that there is certain demand from the community. I hope our solvers could fulfill such demands.
(0010722)
henry   
2019-09-10 16:45   
OK, we can wait until the community tests your changes or compares interFoam with compressibleInterFoam on a range of cases to confirm or otherwise the need for them.
Can you provide a version of interFoam in which the three options for turbulence modeling are supported with a run-time selection mechanism, basically an extension of the mechanism I implemented in compressibleInterFoam?
(0010723)
Wenyuan Fan   
2019-09-10 17:10   
Yes, I will try to create a version of interFoam which supports run-time selection for turbulence modeling. I hope I can finish it in the coming days.
(0010734)
michele   
2019-09-11 12:18   
You may be also interested in testing an approach consisting on turbulence damping at the interface. Here a link to a kOmega model derivation, tested in OF5

https://bugs.openfoam.org/view.php?id=3310#c10733
(0010735)
Wenyuan Fan   
2019-09-11 12:55   
Thank you for the information!

Actually, we have been working with Egorov's turbulence damping model for some time, and have made some improvements to the model, which could be found at
https://doi.org/10.3390/fluids4030136

In the model you provided, "dn" is given as a user specified scalar, instead of a volScalarField which should be calculated based on the local mesh and flow information. Also, we proposed an asymmetric damping treatment in the paper.

The issue I would like to address in this thread is about self consistency. Of course, a self-consistent model does not always guarantee correctness due to certain limitations of the model. As described in the above mentioned paper, varRhoInterFoam cannot give reasonable predictions without using Egorov's turbulence damping model. Then one may argue that if a self-consistent model does not work well, why should we use it? The answer is simple. We can at least make sure that the problem is not caused by the self-consistency of the model.
(0010736)
michele   
2019-09-12 10:06   
Hello Wenyuan Fan.
Let me understand your point of view: interFoam considers two immiscible incompressible fluids with different densities (air, water).

Each phase is incompressible (and the incompressible equations apply, both for momentum and turbulence).

At the interface we have a physical discontinuity. Physically we know that there exist a re-laminarization of the flow at the interface. There could be also other phenomena (like inter-phase mass/momentum/turbulence transfer).
In the real world, at the interface, the density gradient goes to infinity. A VOF approach "smears" this discontinuity trying to keep the interface compressed on, let me say 2 to 5 cells.
If you consider a compressible version of the turbulence model, the only terms that differ from the incompressible version are those related to density gradients. So you are trying to compute these gradients on a region of 2 to 5 cells where large density gradients occour.
Apart from the physical inchoerency of calling "density gradient" a region where, in reality, there is a phase change (the DENSITY GRADIENT is only a result of the VOF ability to compress the interface, so it HAS NO PHYSICAL MEANING).
Also, due to the fact that large gradients occour on a small number of cells, have you quantified the discretization errors of such an approach? In my opinion there could be large errors.

I think it may be preferrable a different approach, i.e. simply model the interface interaction effects. So I use the Egorov approach for the re-laminarization terms. The characteristic lenght "dn", in strongly anisotropic cells, is simply the cell height at the interface (and not the cube root of the cell volume, as implemented in certain commercial codes). In my procedure, it should not be "automatically" computed from the mesh and flow characteristics (provided the computational mesh adheres to strict requirements in quality and geometry at the interface). At the end of the day, all is multiplied by a B factor that is a "large" number. In real world problems with complex geometries this approach proves to be accurate (and consistent with experimental validation). In my experience this approach, combined with a good mesh, adhering to quality requirements (especially at the interface), is the main ingredient for obtaining useful results.
(0010737)
Wenyuan Fan   
2019-09-12 11:52   
Hi Michele,

Regarding turbulence modeling in VOF, my key point is self consistency, as I have already stressed in previous posts.

Let's consider the issue in another way. I totally agree with your argument about the DENSITY GRADIENT that it's unphysical and there might be large discretization errors. Then why should we include this term in the momentum equation? If a strict incompressible momentum equation were used, I would agree the idea of using strict incompressible turbulence models. In my opinion, the statement "the DENSITY GRADIENT HAS NO PHYSICAL MEANING" is true in the real world, but is dangerous in the realm of VOF.

Concerning the Egorov approach, it is useful. Therefore, we are using it and trying to make it better. I agree with you that the cubic root of cell volume is a bad treatment. "dn" could be a constant for given meshes and flow conditions. However, for general cases, where the interface is moving, "dn" should not be treated as a constant since the interface orientation is changing. Discussions about the calculation of "dn" could be found in our paper. Regarding the value of "B", we need to find an appropriate number, not a random "large" number, or a "large enough" number. This is also discussed in the paper. Anyway, the Egorov approach is useful, but it needs fine tuning of the input parameter. The method might be problematic in the absence of experimental values because we don't know how large should "B" be.
(0010738)
michele   
2019-09-12 19:48   
Ok thanks for the clarification. My conclusion is the following.

Regarding the declared "self consistency" of using a compressible turbulence model in interFoam. Are you aware that you are implicitly assuming that a general compressible turbulence model, that has been developed for substantially different types of flow, with coefficients calibrated on typical compressible flow benchmarks, has no specific modelling/calibration for the VOF interface?
A turbulence model is never an exact closure: it has a series of coefficients that are tuned on specific scenarios, and is capable to capture only the phenomena that are included in its terms.
At least a re-calibration of the coefficients on known benchmarks should be performed before using blindly a turbulence model on a completely different scenario.

Moreover, are you sure that the non-uniform density diffusion term is a correct model for the re-laminarization mechanism? This term (in the k equation) is just a consequence of density variation in compressible flow, but does not "inform" the turbulence model that an interface do exist.
In my opinion there must exist a specific correction in order to inform the turbulence model that there is an interface, the same way that in more advanced compressible turbulence models there are terms that account for the presence of shock waves interfaces (typically in the dissipation equation). Regarding the shock waves interface terms, consider that we have typical density ratio of about 5 in (hypersonic) strong shocks, whereas in a interFoam simulation with air-water the density ratio is about 800, so these specific terms are really needed. And there we return to the Egorov damping term: it "informs" the turbulence model of the presence of an interface and provides a way to deal with it. Regarding the coefficients, B should be "large enough" to suppress the turbulence: provided is large enough, there is a large range of variation (exactly like for the coefficient of the solid-wall function).
 
Before stating that a model should be replaced in complex industrial applications, a lot of more work should be done. I would be more than happy that, after 15 years of successful usage of the Egorov model, some advancement is made.
Personally, if I had to construct a new turbulence model for VOF, I would go back to the relaminarization mechanism at the interface: i.e. the suppression of the interface-normal fluctuations (v2). This mechanism is strongly anisotropic and consequently the Boussinesq hypothesis is debatable. So I would try to derive a model like the elliptic relaxation model (Durbin’s v2-f), with specific interfaces sources/sinks on the equations, linked to a non-linear (or algebraic) Reynolds stress tensor.
If such a model proves to be robust, numerically efficient, and accurate (on a sufficient range of benchmarks, with different meshing strategies, and with a demonstration of its mesh convergence capabilities), then I would consider to replace the simple Egorov dissipation source.
(0010739)
Wenyuan Fan   
2019-09-12 22:23   
I am quite aware that we are using single-phase turbulence models to model multiphase flows, which is definitely problematic. However, this is the approach that has been widely adopted in different software and studies. Your comments on calibration and re-calibration are a very good point, because we even have such problems for single-phase flows. However, I don't think such comments are fair to the variable-density incompressible turbulence models, because the strict incompressible turbulence models have the same issues as well. Therefore, I don't see the link between the calibration/re-calibration issue and the self-consistent formulation.

In addition, the non-uniform density diffusion term purely comes from the mathematics derivation, we have never claimed that it is a model for the re-laminarization mechanism. Also, I would like to emphasize that a flow with variable density is unnecessarily compressible.

I agree with you that the desired VOF turbulence models should be able to detect the location of the interface. However, I still believe that there is no large enough value for B. As we discussed in the paper, the non-zero behavior has been observed for k near the interface both in experiments and DNS, meaning that there is certain level of turbulence around the interface. A large enough B simply kills all the turbulence.

Thank you for sharing your thoughts about the turbulence modeling for VOF. I agree with you that the anisotropic Reynolds stress tensor should be an important ingredient. However, adding such terms is not an easy work, so many people may use LES directly. Of course, there should be additional treatments in LES as well.
(0010743)
Wenyuan Fan   
2019-09-17 10:16   
Hello Henry,

I have created a new version of varRhoInterFoam which supports run-time selection of turbulence modeling. Please find it in the attachment. The separate-phase turbulence modeling is not included since we are not working with it.

For the moment, the new turbulence class is written for immiscibleIncompressibleTwoPhaseMixture transport model. However, it can be extended to other transport models (and VOF solvers) by using templates.
(0010745)
henry   
2019-09-17 10:42   
> The separate-phase turbulence modeling is not included since we are not working with it.

It would be much better if all three options were handled in the same system based on the approach in compressibleInterFoam. The merge into OpenFOAM-dev can wait until this is complete.

Following feedback from the community it appears that interface turbulence damping is more important than changing the turbulence model formulation. Currently we do not provide interface damping for the turbulence but it would seem quite straightforward and could be done in an fvOption. Can you provide an fvOption for this?
(0010761)
user136   
2019-09-18 12:48   
Dear colleagues,

here is an update to this and the issue reported here: https://bugs.openfoam.org/view.php?id=3310

We checked the impact of Wenyuan's implementation of incorporating rho consistently into the turbulence models for interFoam.

Here I focus _only_ on incorporating the density in the equation, not on damping etc. as implemented by Michele or Brecht Devolder. Damping clearly enhances the physics if done correctly, but I think first the numerical part should be "best".

Our investigations show that incorporating rho in the equations clearly enhances the modeling of turbulence in the "heavy" phase of interFoam-computations. The attached pictures show a testcase. It is the flow through a weir complex (flow is left to right). Picture 1 shows the geometry, 2 shows velocity right below the water surface, 3 shows velocity on a vertical slice through the domain in flow direction. This slice is regarded in detail in the following pictures.

Picture 4 shows the development of k computed with "normal" interFoam. The white line is the water surface. The upper image part shows the slice directly behind the weir. K should increase in the water due to local dissipation. But instead a lot of k is generated in the air and this effortlessly diffuses into the water. This is due to the constant density, which gives water and air the same "weight" in the PDE. Further downstream (lower image) we would expect k to be highest at the bottom (friction). Again this is spoiled with k coming from the air.

Picture 5 shows the same with the modified turbulence model by Brecht Devolder (https://bugs.openfoam.org/view.php?id=3310, rho in turbulence model), but without the damping he implemented . The results are much better in the water: Near the weir k is dominated by local effects in the water. In the farfield bottom friction is visible. The results in the air are not very nice (numerically), but they do not influence the water too much.

Picture 6 shows the results with varRhoInterFoam by Wenyuan. Again the results in the water are better than in the original version, but here the air looks numerically better, too.

Comment: The simulations were still running when I made the pictures, so they do not all show the same time.

In my oppinion incorporating the density in the equation enhances the quality for people that are interested in simulating the water phase. But for people interested in the air it might (!) be worse. Actually I think the usergroup of "water" guys is much bigger, so I vote for using the correct density. Maybe as a flag?

Based on that, additionally a damping near the water surface (fvOptions) would help.


Best,

Carsten
(0010764)
Wenyuan Fan   
2019-09-18 14:58   
Hello Henry and Carsten. Thank you for the comments and feedback!

Regarding the separate-phase turbulence modeling, I think it might violate the self-consistency that we have been talking about. Since such an approach is designed for the two-fluid method where each phase has its independent momentum equation, it will be confusing to use this approach in VOF where we only have one momentum equation for the mixture. This is my main concern about adding this type of turbulence modeling.

Regarding the fvOptions for turbulence damping, I will provide one in the coming days. Actually, I have been seeking a better way to add the damping term such that the users don't need to keep a copy of the fvOptions file or use a separate turbulence model. Any suggestions?

By the way, I really like the following sentence by Carsten. Damping clearly enhances the physics if done correctly, but I think first the numerical part should be "best".
(0010765)
Wenyuan Fan   
2019-09-19 13:39   
Please find the fvOption for turbulence damping in the attachment. I have tested it with OpenFOAM-7 and OpenFOAM-1706. It should work with other recent versions as well. The usage could be found in "turbulenceDamping.H".
(0010766)
henry   
2019-09-19 13:59   
Thanks for the turbulence damping implementation, I had a quick look and there are some issues. Is it applicable to both k-omega and k-epsilon models? Will it work for interFoam and compressibleInterFoam?
Also the layout of the code is rather different to the conventions in OpenFOAM: https://openfoam.org/dev/coding-style-guide/
Could you update it before it is included in OpenFOAM-dev? It would save a lot of time.

Do you have results with this damping which shows the effect on the two approaches to mixture turbulence?
(0010767)
Wenyuan Fan   
2019-09-19 15:15   
Please find the updated source file in the attachment.

The original model needs to work with omega equations, and my implementation only handles omega-based turbulence models. I think such a treatment is also adopted in ANSYS FLUENT.

This implementation deals with mixture turbulence models, both strict incompressible and full forms. Therefore, it will always work for interFoam. However, it will only work for compressibleInterFoam provided that the separate-phase turbulence modeling is not used.

We tested this model with varRhoInterFoam, the results are given in the paper. Of course, one could test the combination of the damping and interFoam, since, as I mentioned above, the implementation could handle strict incompressible turbulence models as well.
(0010768)
henry   
2019-09-19 15:31   
Is there a fundamental reason why this form of damping cannot be applied via an epsilon equation? Many many users use k-epsilon forms with interFoam and would also benefit from turbulence damping.

I am glad that the implementation is general enough to work with compressibleInterFoam with mixture turbulence and I understand that the model is only for mixture turbulence modeling. A completely different and probably more physical approach would be needed with separate turbulence models in the two phases.
(0010769)
Wenyuan Fan   
2019-09-19 16:52   
Regarding the fundamental reason, I think it is related to the different near-wall behaviors of omega and epsilon. Because this damping modification is based on the phenomenon that, to the gas, the liquid behaves like a solid wall. For omega, there is an asymptotic solution that we can use. And this is why the parameter "B" is included in the model. However, there is no such solution for epsilon. From this point of view, this model can only work with omega-based models. Of course, this is a way to introduce similar corrections to epsilon-based models, which is less physically sound. I will try to implement it and evaluate the performance.
(0010783)
henry   
2019-09-30 14:45   
Given the number of users who run interFoam and compressibleInterFoam with models other than kOmega we will need an implementation which also works for epsilon. Also given that omega and epsilon are related and each can be obtained from the other given k and that it is possible to convert epsilon equations into omega equations and vice versa (and this was done in the creation of the kOmegaSST model) I see no reason why the turbulence damping omega source cannot be converted into the equivalent epsilon damping source. It is not clear why different near wall behavior between different models is relevant here; I get the same near wall solutions for k epsilon and k omega models using corresponding wall function choices.
(0010784)
Wenyuan Fan   
2019-10-01 10:03   
You are correct. This is the way I mentioned. As I said, I need to implement it and evaluate the performance. However, this task has relatively low priority on my to do list, since I think including density is the basic requirement.

Introducing damping may improve results. However, it should work with a self-consistent turbulence model.
(0010785)
henry   
2019-10-01 11:24   
OK, no problem, this can wait until the turbulence modelling is complete and support all three options and the turbulence damping support epsilon.

Currently there is not much information about the difference in behavior of the current interFoam and compressibleInterFoam turbulence modelling with the turbulence damping, the indication given to me in the past is that the damping it the critical component and the difference in turbulence model form less important. Either way the community can test and use either option in the current OpenFOAM releases and try the damping model implementation you provided and report their findings.
(0011414)
Wenyuan Fan   
2020-07-06 21:13   
Hello Henry,

We have provided a major update to our codes, which can be found at

https://doi.org/10.1016/j.cpc.2020.107467

https://github.com/wenyuan-fan/varRhoTurbVOF_2

There are three main changes:
1. We extend our implementation to interPhaseChangeFoam, since it does not consider the variable-density effect in turbulence modeling as well.

2. All solvers can operate in two modes based on the user input. So we can avoid code duplication and maintain the backward compatibility. It should be noted that our approach is different from the one used in compressibleInterFoam, and does not support separate-phase turbulence modeling.

3. The turbulence damping correction is implemented for both omega- and epsilon-based turbulence models. But the implementation is limited to constant-property fluids. So the model is not yet compatible with compressibleInterFoam. In order to make it work with compressibleInterFoam, one needs to use the newest properties in the source term.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3516 [OpenFOAM] Bug minor always 2020-07-04 09:37 2020-07-04 09:51
Reporter: gskillas Platform: GNU/Linux  
Assigned To: henry OS: OpenSuSE  
Priority: normal OS Version: 12.3  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: rhoReactingBuoyantFoam fails to build
Description: cfd@chalk ~/OpenFOAM/OpenFOAM-dev/applications/solvers/combustion/reactingFoam/rhoReactingBuoyantFoam > wmake
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -I. -I/home/cfd/OpenFOAM/OpenFOAM-dev/applications/solvers/combustion/reactingFoam -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/finiteVolume/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/finiteVolume/cfdTools -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/meshTools/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/sampling/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/MomentumTransportModels/momentumTransportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/MomentumTransportModels/compressible/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/ThermophysicalTransportModels/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/ThermophysicalTransportModels/rhoReactionThermo/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/thermophysicalModels/specie/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/thermophysicalModels/reactionThermo/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/thermophysicalModels/basic/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/thermophysicalModels/chemistryModel/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/ODE/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/combustionModels/lnInclude -IlnInclude -I. -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude -I/home/cfd/OpenFOAM/OpenFOAM-dev/src/OSspecific/POSIX/lnInclude -fPIC -c rhoReactingBuoyantFoam.C -o /home/cfd/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/applications/solvers/combustion/reactingFoam/rhoReactingBuoyantFoam/rhoReactingBuoyantFoam.o
In file included from rhoReactingBuoyantFoam.C:102:0:
../../../heatTransfer/buoyantPimpleFoam/pEqn.H: In function ‘int main(int, char**)’:
../../../heatTransfer/buoyantPimpleFoam/pEqn.H:106:22: error: ‘pRef’ was not declared in this scope
 p = p_rgh + rho*gh + pRef;
                      ^~~~
../../../heatTransfer/buoyantPimpleFoam/pEqn.H:106:22: note: suggested alternative: ‘hRef’
 p = p_rgh + rho*gh + pRef;
                      ^~~~
                      hRef
make: *** [/home/cfd/OpenFOAM/OpenFOAM-dev/wmake/rules/General/transform:26: /home/cfd/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/applications/solvers/combustion/reactingFoam/rhoReactingBuoyantFoam/rhoReactingBuoyantFoam.o] Error 1
Tags:
Steps To Reproduce: go to applications/solvers/combustion/reactingFoam/rhoReactingBuoyantFoam type wclean; wmake
Additional Information:
System Description
Attached Files:
Notes
(0011413)
henry   
2020-07-04 09:51   
Resolved by commit e63f3c1e98d8314948fbf0eb9907bdc44e36e0cf


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1991 [OpenFOAM] Bug major always 2016-02-10 15:02 2020-06-25 17:59
Reporter: emacchi Platform: GNU/Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 14.04  
Status: new Product Version: dev  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Problems with turbulentTemperatureCoupledBaffleMixed boundary condition
Description: While doing some CHT simulations (with low-Re RANS model) I noticed that the heat flux of a patch computed using the wallHeatFlux utility in either solid or fluid region is not the same. This is obviously not possible since the equality of heat fluxes is imposed through the boundary condition. The problems seems to appear only when performing variable properties simulations. I checked the output from the debug of the turbulentTemperatureCoupledBaffleMixed BC and in here the computation of the heat flux is correct. I did not check yet but I think the problem is connected to how the heat flux is computed in the utility: in particular it might be related to the conductivity/diffusivity coefficient. In the boundary conditions kappa is computed using directly the boundary values while in the utility fvc::interpolate(alpha) is used.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: modifiedCoolingSphere.tar.gz (7,192 bytes) 2020-06-25 17:59
https://bugs.openfoam.org/file_download.php?file_id=3014&type=bug
Notes
(0005933)
emacchi   
2016-02-10 16:31   
I tried computing the heat flux as follows but there is still the same problem...

surfaceScalarField snGradh
(
fvc::snGrad(h)
);

surfaceScalarField::GeometricBoundaryField& patchHeatFlux =
                                          snGradh.boundaryField();

forAll(patchHeatFlux, patchi)
{
patchHeatFlux[patchi]*=(turb.alphaEff(patchi)());
};
(0005934)
emacchi   
2016-02-10 17:07   
(Last edited: 2016-02-10 17:28)
Ok, I think I found the problem: if I use temperature and effective conductivity to compute the heat flux the results are correct.

Thinking about it the turbulentTemperatureCoupledBaffleMixed BC starts from temperature and conductivity to impose the condition so it makes sense that the heat fluxes computed in this way are identical.

However I would not expect such differences (up to 5%) when using enthalpy. Is this due to the non-linearity of the h-T function I am using? I am modelling supercritical CO2 so the specific heat presents strong variations around the pseudo-critical temperature.

Unfortunately after this correction the error on the overall energy balance for the fluid region is larger...

(0005935)
wyldckat   
2016-02-11 08:01   
Can you please provide a test case that reproduces this problem?

By the way, have you double-checked if the fixes made here: http://www.openfoam.org/mantisbt/view.php?id=1879 - worked as intended?
(0005936)
Juho   
2016-02-11 09:54   
(Last edited: 2016-02-11 09:56)
The turbulentTemperatureCoupledBaffleMixed BC calculates the heat flux: kappaEff*grad(T)

In the energy equations of chtMultiRegionFoam and wallHeatFlux utility the heat flux is calculated alphaEff*grad(he).

These are only equal if Cp is constant on between the wall face and the near wall cell. Otherwise there is an error in the energy balance between the regions.

This issue is explained in a bit more detail in this M.Sc. thesis: https://aaltodoc.aalto.fi/bitstream/handle/123456789/17759/master_Tuominen_Riku_2015.pdf?sequence=1

(0005937)
emacchi   
2016-02-11 11:07   
@ wyldckat: the previous issue was different and it was fixed in the dev (and 3.x) version

@ Juho: yes, I think that's exactly the problem. I will check the M.Sc. thesis. Thank you.
(0005978)
emacchi   
2016-02-23 12:25   
(Last edited: 2016-02-23 15:11)
Yesterday I finally got some time to work on the boundary condition. I implemented a boundary condition based on alphaEff*grad(he) and computed the boundary temperature using Newton method (through assuming constant alpha during iterations). I think its more or less what's described in the MSc, thesis.

Very few Newton iterations are needed, however the heat flux computed on the two sides of the same patch is not identical; sometimes the difference is very small (practically negligible) but it seems that when the transients are important the error also becomes significant. It seems that the number of outer iterations must increased (>25-30) to solve the problem.

Any thoughts?

(0005980)
Juho   
2016-02-26 07:15   
It is probably just a consequence of the region-segregated solution algorithm. You need to iterate over the energy solutions of the regions to converge the inter-region heat transfer. Implicit coupling between the energy solutions of the the different regions would remove the need for these iterations.

You could probably speed-up the simulation a bit by splitting a nOuterEnergyCorr from the nOuterCorr.

Something like:
// --- PIMPLE loop
   for (int oCorr=0; oCorr<nOuterEnergyCorr; oCorr++)

solveFluid.H:
if (oCorr >= nOuterCorr)
{
    frozenFlow = true;
}
else
{
    frozenFlow = false;
}


With something like:
nOuterCorr 3;
nOuterEnergyCorr 30;

You could also add some kind of inter-region heat balance check to stop the extra energy corrector loop if they are below a set tolerance, so that they are only done when needed.
(0005981)
emacchi   
2016-02-26 12:21   
Yeah, its also due to the segregated solution algorithm but I think that the "approximated" Newton method used while computing enthalpy based boundary condition plays a large role.

I could try to update also alpha during the Newton iteration but it's not that simple because both kappa(T) and Cp(T) are not simple functions (for example Cp(T) is something like a Gaussian function).

I was also thinking of adding additional iterations to compute only the fluid energy equation. In this way the alpha in the BC is updated without having to do a full outer correction. Implementing an inter-region heat balance to stop the energy corrector loop is good idea! I will do this shortly, thank you!

Last week, before adding the new BC I tried to use the regionCoupled functionality in OF-dev (src/regionCoupled and src/meshTools/regionCoupled/). I got it to run so the simulation setup should be ok but the results are not correct. Unfortunately there is almost no information about this functionality and I am not sure whether it is fully functional or not. I tried to check the source code (src/regionCoupled/derivedFvPatchFields/energyRegionCoupled/energyRegionCoupledFvPatchScalarField.C) but I don't understand how this works (it not that clear from "updateInterfaceMatrix"). However this seems for sure quite different from conjugateHeatFoam, the fully-coupled CHT solver of FOAM-extend.

Do you have any info about this?
(0006007)
emacchi   
2016-03-08 11:55   
(Last edited: 2016-03-08 12:05)
Update about this problem:

adding an energyCorrector loop inside the outerCorrections loop (to solve the energy equation for all the regions) solves the problems. As suggested by Juho the number of iterations can be managed automatically based on an inter-region heat balance. The latter can be computed similarly to what is done in temperatureCoupled.. boundary conditions.

(0011411)
jherb   
2020-06-25 17:59   
Any updates on this issue? I am running exactly into this problem. I have created a test case based on $FOAM_TUTORIALS/heatTransfer/chtMultiRegionFoam/coolingSphere

The thermophysical proberties of vapor were fitted to the output of:
https://webbook.nist.gov/cgi/fluid.cgi?Action=Data&Wide=on&ID=C7732185&Type=IsoBar&Digits=5&P=16&THigh=1275&TLow=625&TInc=10&RefState=DEF&TUnit=K&PUnit=MPa&DUnit=kg%2Fm3&HUnit=kJ%2Fkg&WUnit=m%2Fs&VisUnit=Pa*s&STUnit=N%2Fm

Is the boundary condition "turbulentTemperatureCoupledBaffleMixedMod" mentioned in the master thesis or the other developments available?

Thank you for any help


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3513 [OpenFOAM] Bug minor always 2020-06-23 13:34 2020-06-23 15:43
Reporter: joegi Platform: OpenSUSE 15  
Assigned To: will OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 7  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: pimpleFoam - residualControl does not have any effect when using the functionOnject scalarTransport
Description: In report 0003510, the issue with steady solvers was fixed. Now it works great.

Now I am doing the same test with unsteady solvers and I found that the issue is still there.

Personally speaking, for unsteady solvers this is not a big deal (my opinion). However, I think it is a good idea to have a consistent behavior among the solvers.

If you set outerCorrectorResidualControl to a large value, i.e.,

    outerCorrectorResidualControl
    {
        "(T)"
        {
            relTol 1; //0.01 - 0.001
            tolerance 1; //0.001 - 0.0001
        }
    }

I would expect the loop to stop almost immediately, but it does not.

I also found that if you use residualControl, the solver will read this condition as well.

    residualControl
    {
        T 1;
    }

I think the use of residualControl is redundant. The condition outerCorrectorResidualControl should be enough to control the loop. In my personal opinion, residualControl makes sense only to assess if the solver has reached a steady behavior (maybe this is the desired behavior, I don't know).

Maybe a way to solve this issue, will be to add the tolerance in the function object scalarTransport, but this fix will be only valid for this specific function object.

Again, I think this is more an annoying behavior than a bug.
Tags:
Steps To Reproduce: In the attached case run the script run_all.sh:

$> sh run_all.sh

The tolerance of the transported scalar is high, so I would expect the solver to stop immediacy, but it does not.
Additional Information:
Attached Files: pimpleFoam.tar.gz (31,211 bytes) 2020-06-23 13:34
https://bugs.openfoam.org/file_download.php?file_id=3012&type=bug
Notes
(0011409)
will   
2020-06-23 15:43   
PimpleFoam in version 7 does not support time-loop residualControl. This has already been resolved in dev.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3336 [OpenFOAM] Feature minor N/A 2019-08-23 11:45 2020-06-23 15:42
Reporter: joegi Platform:  
Assigned To: will OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Purpose of residualControl in the pimple loop
Description: I am wondering what is the purpose of residualControl keyword in the PIMPLE loop?

I think outerCorrectorResidualControl should be the only one to specify, as residualControl does not have any influence.

Also, it might be helpful to add the option for a minimum number of iterations even if the tolerances are reached, just an idea.


Also, I would like to highlight a small typo, in the header of the file
src/finiteVolume/cfdTools/general/pressureControl/pressureControl.H

Should read,
Provides controls for the pressure reference IN closed-volume

Instead of,
Provides controls for the pressure reference IS closed-volume
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: cavity_single.tar.gz (3,984 bytes) 2019-08-23 15:05
https://bugs.openfoam.org/file_download.php?file_id=2751&type=bug
Notes
(0010690)
will   
2019-08-23 14:06   
See https://github.com/OpenFOAM/OpenFOAM-dev/commit/4c8122783aedaa7dadf0486163a98350e625db32
(0010691)
joegi   
2019-08-23 14:21   
Yes, but even setting residualControl to a large value does not have any effect in the convergence control in the PIMPLE loop
(0010692)
will   
2019-08-23 14:37   
(Last edited: 2019-08-23 15:24)
Please give me an example which reproduces the issue

https://bugs.openfoam.org/rules.php "An issue report therefore must include the following: A clear set of instructions that reproduces the issue, including key files, if required"

(0010693)
joegi   
2019-08-23 15:05   
Run the case using pimpleFoam.

The case should stop almost immediately but it keeps iterating until the end time. For this case it seems that residualControl has no effect at all on the convergence control.

On the other hand, outerCorrectorResidualControl works as it should be.
(0010694)
will   
2019-08-23 15:21   
OK. pimpleFoam hasn't been updated to use the time-loop residual controls. I think the only solver that has is chtMultiRegionFoam. If I recall correctly, the inclusion of these controls into PIMPLE was designed to facilitate making PIMPLE offer the same functionality as SIMPLE so that extremely complex solvers could be combined. I guess only the solvers that actually were combined were considered necessary to update.

The change could be propagated to all PIMPLE solvers if need be; it's just a one-liner. It begs the question, though, why do you want to do simulation-level residual control on a pimpleFoam case, and why are you not running simpleFoam?
(0010695)
joegi   
2019-08-23 15:51   
I was porting a case from another version and I realized that the dictionaries changed, so I started to read the convergenceControl options.

For me it also does not make sense to have residualControl in the pimple loop. In any-case, it can be helpful as a monitor to determine if the solver has reached an steady state (but it is better to monitor an integral quantity).

Then, thinking about this, it might be helpful to add a control for the minimum number of iterations in outerCorrectorResidualControl, I know it might be redundant, but sometimes I use it (hardwired in the solver though).
(0010703)
will   
2019-08-27 14:07   
Ok, well, for consistency's sake, I think it's reasonable to say that residual controls should function the same way in all PIMPLE solvers, regardless of whether there is a SIMPLE variant or not. I have made this the case with the following commit.

https://github.com/OpenFOAM/OpenFOAM-dev/commit/f53632854427b8afb8cf60f87829520ba76eea2d

The case you uploaded now exits as expected when the residuals reduce to the specified tolerance, so I consider this bug to have been resolved.

As for the issue of a minimum number of iterations in the corrector residual controls. Such a change is perfectly possible, though there are some questions regarding syntax and which iteration loops it applies to. If you are able to support such a change, either by means of funding its development or by contributing the code yourself, then please open a feature request.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3509 [OpenFOAM] Bug major always 2020-06-14 20:08 2020-06-22 09:22
Reporter: Qiang Platform: WSL  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: new Product Version: dev  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Phase mass/volume imbalance of the VoF family solvers due to using AMI
Description: I have tested the VoF family solvers under almost all versions of OF and found when the AMI approach with a baffle inside the fluid is employed, like mixerTank2D case, the phase mass/volume imbalance or mass loss problem will take place. With every timestep, it loses a certain amount of fluid, for the attachment case, the fluid volume loss fraction, only after running 12.5 seconds, had reached 37.34%. The level of liquid in the tank has dropped remarkably in the condition of having not any outlet due to this volume/mass loss.

Through monitoring the weightedSum(phi) of the patch AMI1 and AMI2 found this phase volume/mass loss possibly comes from the inconsistent interpolation when two patches slides and couples with each other. how to forcefully keep balance when interpolation may be a key problem.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: mixerTankAMI3D_forBugReport.tar.gz (11,163 bytes) 2020-06-14 20:08
https://bugs.openfoam.org/file_download.php?file_id=3002&type=bug
Volume evolution.PNG (101,189 bytes) 2020-06-14 20:10
https://bugs.openfoam.org/file_download.php?file_id=3003&type=bug
weightedSum(phi) difference between AMI1 and AMI2.PNG (613,946 bytes) 2020-06-14 20:10
https://bugs.openfoam.org/file_download.php?file_id=3004&type=bug
AMI1.dat (177,600 bytes) 2020-06-14 20:13
https://bugs.openfoam.org/file_download.php?file_id=3005&type=bug
AMI2.dat (183,932 bytes) 2020-06-14 20:13
https://bugs.openfoam.org/file_download.php?file_id=3006&type=bug
volFieldValue.dat (35,141 bytes) 2020-06-14 20:13
https://bugs.openfoam.org/file_download.php?file_id=3007&type=bug
mass_loss_comparison_across_different_OFversion.PNG (207,547 bytes) 2020-06-17 18:17
https://bugs.openfoam.org/file_download.php?file_id=3008&type=bug
Notes
(0011394)
henry   
2020-06-14 20:34   
Yes this is a well known problem with the current AMI implementation and has been reported several times. If you search for AMI you will see the previous discussions on this issue.
(0011395)
Qiang   
2020-06-17 18:17   
Sure. I have reviewed the most of related items from this tracking system and CFD-online forum. I saw there were still a lot of struggles to try to solve this issue, although it had a long history. And I found the pimpleDyMFoam with AMI and VoF family solvers with MRF have already had some improvements to keep the mass/volume conversion, but the issue on VoF solvers with AMI is still there about several years and across the several versions.

In addition, it seems to even turn worse and worse, the following figure gives a comparison between two old snapshots of dev-490a29719073e724 by released on Sep. 06, 2018 and dev-fa9cccf11df67a1f on Jun. 11, 2020. Maybe, it is a hint what you have changed, thus it turn worse.

By the way, could you of OF.org have any plan to fix this ill in the near future, or if possible, could you give some hints or clues on how to fix it? Finally, thank you very much.
(0011396)
henry   
2020-06-17 19:35   
This is a particularly tricky problem to solve and requires funding for development and maintenance:

https://openfoam.org/news/funding-2020/
(0011401)
Qiang   
2020-06-22 09:22   
Thank you for all the replies.

Honestly, this bug has resulted in many abnormal results when the VoF solvers with AMI were employed and thus incurred the OF creditworthiness loss. Of course, I can understand your demand for funding to struggling OF. If possible, in the future once I get a financial aid, I will attend the Maintenance Plans.

On this bug, I have spent several days to find a workaround to forcefully keep mass balance when using AMI interpolation, I still need some additional tests to guarantee the validity of this remedy.

Whatever, thank you very much for sharing the excellent OF codes with the community.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3500 [OpenFOAM] Patch minor always 2020-06-01 11:21 2020-06-09 10:41
Reporter: wyldckat Platform:  
Assigned To: will OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: Missing touches on the update to the new CGAL and Boost header-only method
Description: Following up on issues, 3439 and 3496, there are a couple of details that need tweaking:

1- README in ThirdParty should mention Boost 1.72 as the minimum. I haven't confirmed what is the actual minimum, but it was the one closest to the latest CGAL releases and builds with header's only.

2- "wmake/rules/General/CGAL" is still referring to Boost's include folder, which is no longer used in the header-only mechanism, given that no script is now provided/needed to build Boost.

Attached are the following files:
- README-dev_v1.patch - patch file indicating the line changed in the "ThirdParty-dev/README.org" file regarding Boost version.

- ThirdParty_dev_README.org - the actual "ThirdParty-dev/README.org" already updated.

- wmake_rules_General_CGAL - The "wmake/rules/General/CGAL" file already updated for Boost in header only mode (i.e. without "/include" folder).

- wmake_rules_General_CGAL-dev.patch - The respective patch file.

Both are indexed to OpenFOAM-dev, but the patches should be applicable to OpenFOAM-7 and ThirdParty-7.
Tags:
Steps To Reproduce:
Additional Information: Technically, the inclusion path defined in wmake's "CGAL" file, could also include the "/include" path for Boost, but this way it enforces the more recent versions of Boost.
Attached Files: README-dev_v1.patch (581 bytes) 2020-06-01 11:21
https://bugs.openfoam.org/file_download.php?file_id=2978&type=bug
ThirdParty_dev_README.org (2,688 bytes) 2020-06-01 11:21
https://bugs.openfoam.org/file_download.php?file_id=2979&type=bug
wmake_rules_General_CGAL (2,436 bytes) 2020-06-01 11:21
https://bugs.openfoam.org/file_download.php?file_id=2980&type=bug
wmake_rules_General_CGAL-dev.patch (391 bytes) 2020-06-01 11:21
https://bugs.openfoam.org/file_download.php?file_id=2981&type=bug
Notes
(0011389)
will   
2020-06-09 09:11   
(Last edited: 2020-06-09 09:11)
I don't know what the actual minimum boost is either, but I've tested building against CGAL-4.10 with boost-1.58.0 in Ubuntu 16.04. You're right, though that the README should list a current version to match what is listed for CGAL (5.0.2). I've tested boost-1.71, so that or your suggestion of 1.72 should be fine. I'll apply the patch.

wmake/rules/General/CGAL refers to boost's include directory because it is used in the header-only mechanism. It's the lib directory that isn't used any more. The include directory has moved (it's just in the top level ThirdParty-dev now, not in platforms, as we don't build or install anything), but I believe it is still needed.

Saying that, I haven't tested a build against anything other than a system boost. I'll give it a go this morning and confirm either way.

(0011390)
will   
2020-06-09 10:41   
I've done a build with non-system boost now. I see what you mean about boost's "include" subdirectory (or lack thereof) now. I've fixed "wmake/rules/General/CGAL" accordingly. Links have also been updated in the README-s as you suggested. Thanks for the report.

https://github.com/OpenFOAM/OpenFOAM-7/commit/f440844a5b782709c38b4c0deb8c93f25ede14a7
https://github.com/OpenFOAM/ThirdParty-7/commit/d7636a04b51086ede89ccf01891dd91a23cbe8da
https://github.com/OpenFOAM/OpenFOAM-dev/commit/7dd592ff4013fc6e444f27b12ff8729774cb5e0f
https://github.com/OpenFOAM/ThirdParty-dev/commit/f83b1b65b48f3ac35ca69677e392ce78315095ae


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3502 [OpenFOAM] Bug minor always 2020-06-02 23:11 2020-06-03 17:13
Reporter: StasF1 Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: high OS Version: 20.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Change moving mesh behaviour between dev-20200508 and dev-20200531 release
Description: After the dev-20200531 release the moving mesh on cyclic (and cyclicACMI) patches with type 'slip' started to act weirdly
Tags:
Steps To Reproduce: Run the cylCyclic2D/ case using OpenFOAM dev-20200508 and dev-20200531
Additional Information:
System Description
Attached Files: cylCyclic2D.tar.xz (7,840 bytes) 2020-06-02 23:11
https://bugs.openfoam.org/file_download.php?file_id=2982&type=bug
dev-20200508.png (105,001 bytes) 2020-06-02 23:11
https://bugs.openfoam.org/file_download.php?file_id=2983&type=bug
dev-20200531.png (130,449 bytes) 2020-06-02 23:11
https://bugs.openfoam.org/file_download.php?file_id=2984&type=bug
Notes
(0011371)
henry   
2020-06-03 17:13   
Resolved by commit 6ef064984d0cf4c0afb6d2f83eb8e86f76255a2e


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3463 [OpenFOAM] Bug minor always 2020-02-29 14:28 2020-06-02 18:45
Reporter: Federico Municchi Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: low OS Version: 18.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Incorrect template for PrimitivePatch in patchToPatchInterpolation.H
Description: Template for PrimitivePatch in typedef
https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/OpenFOAM/interpolations/patchToPatchInterpolation/patchToPatchInterpolation.H#L41
does not comply with current definition of PrimitivePatch
https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/OpenFOAM/meshes/primitiveMesh/PrimitivePatch/PrimitivePatch.H#L81
but it still has the old template
https://github.com/OpenFOAM/OpenFOAM-6/blob/master/src/OpenFOAM/meshes/primitiveMesh/PrimitivePatch/PrimitivePatch.H#L81

Therefore, the code in
https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/OpenFOAM/interpolations/patchToPatchInterpolation/patchToPatchInterpolation.H
does not compile when included in an application (it is never included in any of the native applications/library).
Tags:
Steps To Reproduce: Simply adding
#include "patchToPatchInterpolation.H"
to any application will reproduce the error.
I attached a simple example for your convenience.
Additional Information:
System Description
Attached Files: OpenFoamBugInterpolationTemplates.zip (2,137 bytes) 2020-02-29 14:28
https://bugs.openfoam.org/file_download.php?file_id=2924&type=bug
Notes
(0011225)
henry   
2020-02-29 15:14   
Resolved in OpenFOAM-dev by commit 58f3ed727678475f6970b5a8190c5b3695c893b8


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3498 [OpenFOAM] Bug crash always 2020-05-22 19:18 2020-05-25 11:10
Reporter: gskillas Platform: OpenSUSE  
Assigned To: henry OS: Leap  
Priority: normal OS Version: 15.1  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: solidDisplacementFoam crashes when Re-reading system/fvSolution
Description: Changes made to system/fvSolution, causing a re-read by a running solidDisplacementFoam instance lead to a crash with a message similar to:

regIOobject::readIfModified() :
    Re-reading object fvSolution from file "/home/cfd/OpenFOAM/cfd-dev/run/pressurisedPipe/system/fvSolution"
Iteration: 0.10036



--> FOAM FATAL IO ERROR:
keyword D is undefined in dictionary "\


file:


    From function T Foam::dictionary::lookup(const Foam::word&, bool, bool) const [with T = double]
    in file /home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/dictionaryTemplates.C at line 46.

FOAM exiting
Tags:
Steps To Reproduce: Copy the platehole tutorial, change the end time in system/controlDict to 20000 (to give the case enough running time), and then

> ./Allclean; ./Allrun & sleep 30; touch system/controlDict
Additional Information:
System Description
Attached Files:
Notes
(0011366)
henry   
2020-05-25 11:10   
Resolved by commit cf36a5de3cf1007595429bf14c5699d8c68cd431


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3495 [OpenFOAM] Bug minor N/A 2020-05-13 21:42 2020-05-22 09:11
Reporter: kevnor Platform:  
Assigned To: will OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Divide-by-zero in SHF particle break-up model
Description: A divide-by-zero occurs in the SHF break-up model src/lagrangian/spray/submodels/BreakupModel/SHF/SHF.C:161 when the relative velocity (Urmag) is zero.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011364)
will   
2020-05-22 09:11   
I have pushed a change to dev that should resolve this.

https://github.com/OpenFOAM/OpenFOAM-dev/commit/9b23ae3b1b05e4d1cfcce9f1b6e64761276e710a

You have not provided any means of reproducing or testing the error, however, so I am not 100% sure that what I have done will resolve your problem. If the change does not fix your issue, please open another bug report. In future, please provide something that we can use to reproduce the issue. See https://bugs.openfoam.org/rules.php.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3492 [OpenFOAM] Bug minor always 2020-05-11 08:34 2020-05-22 08:42
Reporter: FoamerLY Platform: GNU/Linux  
Assigned To: will OS: Ubuntu  
Priority: normal OS Version: 14.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: The formula in the OF is inconsistent with the Rosin-Rammler distribution theory formula
Description: The formula used to calculate CDF (Cumulative Distribution Function) is at line 31 in RosinRammler.H (https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/lagrangian/distributionModels/RosinRammler/RosinRammler.H)

The CDF is now calculated as:
cumulative model=(1.0-exp(-((x-d0)/d)^n))/(1.0-exp(-((d1-d0)/d)^n));
where d0 and d1 are the minimum and maximum diameters of particles, respectively; d is the Rosin-Rammler representative diameter and n is the Rosin-Rammler exponent. They are all constants.

However, according to Atomization and Sprays and Ansys Fluent Users Guide Release 19.0
the theoretical formula of Rosin-Rammler distribution is as follows:
cumulative model=(1.0-exp(-(x/d)^n+(d0/d)^n))/(1.0-exp(-(d1/d)^n+(d0/d)^n));

With the same parameters, these two formulas may get different solutions.
Tags:
Steps To Reproduce: Based on the coefficients in the OpenFOAM-7/tutorials/lagrangian/sprayFoam/aachenBomb/sprayCloudProperites#L139, We find that when the values of d0 and d1 are very different, the two curves of CDF are similar (see Figure 1).

However, when the difference between the two values is not that large, the two curves began to show differences (see Figure 2).

Accoding to the Rosin-Rammler distribution parameters (Fig. 3) adopted in 'Large eddy simulation of high-velocity fuel sprays: studying mesh resolution and breakup model effects for spray A', there are obvious differences between the two CDF curves (Fig. 4).
Additional Information:
System Description
Attached Files: figure 1.png (22,973 bytes) 2020-05-11 08:34
https://bugs.openfoam.org/file_download.php?file_id=2963&type=bug
figure 2.png (24,726 bytes) 2020-05-11 08:34
https://bugs.openfoam.org/file_download.php?file_id=2964&type=bug
figure 3.jpg (6,601 bytes) 2020-05-11 08:34
https://bugs.openfoam.org/file_download.php?file_id=2965&type=bug
figure4.png (24,476 bytes) 2020-05-11 08:34
https://bugs.openfoam.org/file_download.php?file_id=2966&type=bug
Equation 1.png (6,533 bytes) 2020-05-14 09:57
https://bugs.openfoam.org/file_download.php?file_id=2968&type=bug
Equation 2.png (2,087 bytes) 2020-05-14 09:57
https://bugs.openfoam.org/file_download.php?file_id=2969&type=bug
Equation 3.png (3,844 bytes) 2020-05-14 09:57
https://bugs.openfoam.org/file_download.php?file_id=2970&type=bug
Equation 4.png (5,311 bytes) 2020-05-14 09:57
https://bugs.openfoam.org/file_download.php?file_id=2971&type=bug
picture 5.png (25,478 bytes) 2020-05-18 11:52
https://bugs.openfoam.org/file_download.php?file_id=2974&type=bug
Table 2.png (12,265 bytes) 2020-05-18 11:52
https://bugs.openfoam.org/file_download.php?file_id=2975&type=bug
picture 6.png (27,127 bytes) 2020-05-18 11:52
https://bugs.openfoam.org/file_download.php?file_id=2976&type=bug
Table 3.png (11,649 bytes) 2020-05-18 11:52
https://bugs.openfoam.org/file_download.php?file_id=2977&type=bug
Notes
(0011337)
will   
2020-05-12 09:48   
(Last edited: 2020-05-12 09:49)
Rosin Rammler (or Weibull) is usually only stated as `Q = 1 - exp(-(x/d)^n)`. The additional (d0 and d1 dependent) terms are there to clip the distribution. I see no reference to how these additional parameters should be handled, either in Atomisation and Sprays, or on Wikipedia, though I might not have spotted it. I do not have access to the Fluent 19.0 user manual.

Can you be specific as to where (ideally, in Atomisation and Sprays, or in a publicly accessible document) that your proposed form of the distribution is defined?

(0011341)
FoamerLY   
2020-05-14 09:57   
I agree with you that there is no standard for the selection of these parameters in the Rosin-Rammler distribution. What we suspect is that the CDF formula used in OpenFOAM is wrong. The following is our derivation of this modified formula.

As you said, Rosin Rammler distribution is usually stated as `y = 1 - exp(-(x/d)^n)`, But generally, we only consider the situation where the particle diameter is in the range of [d0, d1]. The probability that the particle diameter is within this range is given by Equation 1. The red part ‘K’ is a scalar used in https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/lagrangian/distributionModels/RosinRammler/RosinRammler.C

Since the domain of definition changes from (0, ∞) to (d0, d1), the modified cumulative distribution function needs to satisfy Equation 2. In order to keep the linear relationship between the modified CDF function and the original function, the modified CDF function needs to meet the Equation 3.

Combined with Equation 1, 2 and 3, the modified CDF function can be derived (see Equation 4).
(0011344)
will   
2020-05-14 19:26   
> In order to keep the linear relationship between the modified CDF function and the original function

Why is linearity important? Both forms transform the function from (0,+inf) to (d0,d1) so that y(d0)=0 and y(d1)=1.

RosinRammler has been the form it is now for almost a decade. I need good evidence to change it. Why is your form better? Is there a standard reference that supports what you are saying?
(0011352)
FoamerLY   
2020-05-18 11:52   
We understand that this formula has been in use for almost a decade. Through analysis, the formula used in OpenFOAM works well under certain parameters, such as the parameters used in the OpenFOAM-7/tutorials/lagrangian/sprayFoam/aachenBomb/sprayCloudProperites#L139

Under these parameters, the PDF curve used in OpenFOAM is quite consistent with our modified PDF curve (Fig. 5). Their mathematical expectations and variances are very close (Table 2).

We point out that there may be problems with the existing formula under other parameters, like the parameters used in Fig. 3. Under these parameters, deviation between the two curves occurs (Fig 6). Although their variances are the same, their mathematical expectations are different (Table 3).

We know it is hard to challenge an existing formula, especially it works under certain conditions. Could you provide me with the relevant references where the form adopted in OpenFOAM is proposed. This will help us a lot to understand it.
(0011358)
will   
2020-05-19 12:44   
Is your clipping equivalent to sampling the entire (0,+inf) range, but discarding any result that does not fall into the (d0,d1) range and re-sampling? Like what is currently implemented in massRosinRammler.C. If so, then I think consistency with other distributions might be reason enough to accept your proposed change.
(0011362)
FoamerLY   
2020-05-21 07:34   
Yes, you get it. As you think, they are equivalent. There are two methods of sampling a random number in a finite interval (d0, d1), one is to sample the whole (0, +inf) but need to re-sample if the selected number does not fall within the desired (d0, d1) range, the other is to transform the original function from (0, +inf) to (d0, d1) and the probability in the interval (d0, d1) is proportionally enlarged so that y(d0)=0 and y(d1)=1. The effect of the two methods is the same. The first method is now adopted in massRosinRammler.C as you said, the second method is the one we suggest.
(0011363)
will   
2020-05-22 08:42   
OK, thanks. Your change has been made to dev as the following commit.

https://github.com/OpenFOAM/OpenFOAM-dev/commit/8604c1eb5fe621f9084eaeb784e11dd559552f47

I can't do the same to version 7. Changes to numbered versions shouldn't affect results; they can only fix crashes and such.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3497 [OpenFOAM] Bug minor always 2020-05-17 19:16 2020-05-18 15:44
Reporter: JeroenJanssen Platform: Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 20.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: blockMeshDict missing in pitzDaily tutorial
Description: Hi,
I just installed a clean version of OF dev and while going through the steps on your website for checking if the installation went correct, I noticed that the blockMeshDict file is missing in the $FOAM_TUTORIAL/incompressible/simpleFoam/pitzDaily/system folder. (it's also missing on the GitHub repo)

I created a new blockMeshDict from the previous version, and everything seems to works ok.

Thanks,
Jeroen
Tags:
Steps To Reproduce: install OF-dev

cd $FOAM_RUN
cp -r $FOAM_TUTORIALS/incompressible/simpleFoam/pitzDaily .
cd pitzDaily
blockMesh
Additional Information:
System Description
Attached Files:
Notes
(0011350)
tniemi   
2020-05-17 19:57   
Hi,

In the pitzDaily case there is Allrun-script, which contains this:
runApplication blockMesh -dict $FOAM_TUTORIALS/resources/blockMesh/pitzDaily

So the blockMesh is located in a common resources folder, because there are multiple variations of the same tutorial for differents solvers.
(0011351)
JeroenJanssen   
2020-05-18 10:36   
Hi,

Thanks, ok, that makes sense.
Maybe then the steps on the website should be updated to reflect that (as that is now the new steps to get the dev-version to work..)

https://openfoam.org/download/dev-ubuntu/
Under 'Getting Started'

Many thanks!
(0011353)
henry   
2020-05-18 15:44   
Resolved by commit 1217724ed93a0e6906eedcf4b022c940c35d91ee


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3491 [OpenFOAM] Contribution minor always 2020-05-06 11:32 2020-05-08 11:55
Reporter: arohner Platform: Unix  
Assigned To: will OS: Ubuntu  
Priority: normal OS Version: 20.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: Compilation with some Errors
Description: Hello All

I couldn't wait for the packaged version of OpenFOAM for ubuntu-20.04. Is there already a certain date, when this package will be available?
Compilation from source generated some errors, which I judge as minor relevant, since everything seems to work as expected. I anyway added the log from the compilation. I would also suggest to update the compilation procedure on openfoam.org. The one found in openfoamwiki.net gives a slightly more detailed step-by-step workflow:

https://openfoamwiki.net/index.php/Installation/Linux/OpenFOAM-7/Ubuntu/18.04

Let me know, whether I can help with further information or contribute anything else.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: compilation2004_logs.tar.gz (11,643 bytes) 2020-05-06 11:32
https://bugs.openfoam.org/file_download.php?file_id=2962&type=bug
Notes
(0011332)
wyldckat   
2020-05-06 14:14   
From what I can quickly see in the log files, only CGAL is failing to compile, likely due to some detail between the CGAL version that Ubuntu 20.04 brings and the version that OpenFOAM was tested with... either that and/or because of the GCC version.

It also seemed like the readers for ParaView didn't build, either due to CMake version or due to ParaView not having been built yet?

Either way, you can run Allwmake with the -k option so that it ignores errors and proceed building the remaining binaries, e.g.:

   ./Allwmake -j 4 -k > log2.make 2>&1

I'll also try to build it on Ubuntu 20.04 sometime this week... I'm curious and I am still using 16.04...
(0011333)
will   
2020-05-08 11:55   
Resolved in 7 and dev by the following commits

https://github.com/OpenFOAM/OpenFOAM-7/commit/3bcbaf946ae937ab98c0261764a22451a52bac95
https://github.com/OpenFOAM/OpenFOAM-dev/commit/83bd225910e29b9b952eafe011066d9b79f6cdf7

CGAL (and Boost) is now being used header-only, which requires version 4.9 or above. If that's not available on a system it will need downloading and unpacking into ThirdParty, and the version number in the CGAL setup file changing accordingly. Fortunately, because it's now header-only, that's all you have to do. There's no library to build.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3489 [OpenFOAM] Feature feature have not tried 2020-04-28 23:23 2020-05-01 00:00
Reporter: StasF1 Platform: Unix  
Assigned To: OS: Other  
Priority: normal OS Version: (please specify)  
Status: new Product Version: dev  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Return writeVolume option to volFieldValue post-processing function
Description: In the commit d27e752 the writeVolume option was removed from volFieldValue post-processing function, but it was handy tool for moving meshes (and it also needed).
Is it possible to return it back?
Tags:
Steps To Reproduce:
Additional Information: - [ commit d27e752 ] - https://github.com/OpenFOAM/OpenFOAM-dev/commit/d27e752ad6a3811cc76aa5b540b46841d11192a1
- System: Ubuntu 20.04 LTS
- Product Version: OpenFOAM-dev, 2020/04/26 - https://github.com/OpenFOAM/OpenFOAM-dev/releases/tag/20200426
System Description
Attached Files:
Notes
(0011307)
henry   
2020-04-28 23:58   
It is not logical that volFieldValue functionObject also provides mesh geometry writing capability, it would be better that this is provided by a special functionObject dedicated to that purpose.
(0011308)
chris   
2020-04-29 08:51   
Follow the advice here https://cfd.direct/openfoam/productive-cfd/#post-processing-cli
and type:
postProcess -list
You should see the writeCellVolumes function object
(0011309)
StasF1   
2020-04-29 09:36   
Thank you for your immidiate responce!
I'm familiar the writeCellVolumes object, but it just creates volScalarField of the cell volumes. But what if i need to get volume of the whole domain (as function of time)? Or even volume of the cellZone region?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3488 [OpenFOAM] Bug minor have not tried 2020-04-26 21:42 2020-04-29 12:52
Reporter: handrake0724 Platform: Unix  
Assigned To: OS: Other  
Priority: normal OS Version: (please specify)  
Status: new Product Version: dev  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: interfaceHeight results have non-zero mean wave level in parallel computation
Description: I have tried wave simulation following a tutorial in multiphase/interFoam/laminar/wave.
first, the case in multiphase/interFoam/laminar/wave gives correct wave elevation with zero mean level both in single and parallel computations.
So, I have made a benchmark case for my own and ran some calculations. in single core calculation, the elevation looked correct.
but in parallel computations, the wave elevations were shifted by non-zero mean.

I looked into interfaceHeight.C to figure out what caused it and found that the following statements have different values from single core calculation.

        reduce(sumLength, sumOp<scalar>());
        reduce(sumLengthAlpha, sumOp<scalar>());

As attached case which has length of 450 in z direction, the above statements give exactly 450 in single core calculation but in parallel calculation, it gives 900.

I could not figure out what difference made it from the tutorial case yet.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: case.tar.gz (4,173 bytes) 2020-04-26 21:42
https://bugs.openfoam.org/file_download.php?file_id=2958&type=bug
Notes
(0011305)
handrake0724   
2020-04-27 02:54   
I studied the case little bit further.
The results look like depending on the number of decomposed domain in gravity vector.
in the decomposeParDict, set method to simple

simpleCoeffs
{
    n (3 2 1);
    delta 0.001;
}
and
simpleCoeffs
{
     n (3 1 2);
    delta 0.001;
}

gives different results.

when there are more than one decomposed domain in z direction, interface height has the same values as single core results
but when there are only one decomposed domain in z direction, the results depends on the number of decomposition in that direction.
(0011306)
will   
2020-04-28 09:12   
The problem is not the decomposition in Z, it's the decomposition in X and Y (in this case Y). You've put a processor boundary exactly on the sampling line (the given point with a ray shot in -g and +g). The line is showing up in both processors.

We can't account for that. You have to make sure that sampling lines are fully within a processor for this sort of thing to work. The same is true of graph generation or any number of other post-processing operations. The traditional way of doing this on a structured mesh is to specify the point (1e-6 1e-6 1e-6) rather than (0 0 0). Doing so in your case gives the correct answer.
(0011310)
handrake0724   
2020-04-29 12:52   
That makes sense to me. Thank you for enlightening me.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3486 [OpenFOAM] Bug crash always 2020-04-21 21:56 2020-04-22 15:22
Reporter: jheylmun Platform: Linux  
Assigned To: henry OS: OpenSUSE  
Priority: normal OS Version: Tumbleweed  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: ExtrueMesh fails in parallel with wedge extrusion
Description: When running extrudeMesh is parallel with a wedge extrusion type, an error in IOstream is thrown. A regular extrusion work, and it also work in serial. I have reproduced in WLS with Ubuntu 18.04 as well.
Tags:
Steps To Reproduce: run ./Allrun from the attached case
Additional Information:
System Description
Attached Files: wedgeExtrude.tar.gz (3,431 bytes) 2020-04-21 21:56
https://bugs.openfoam.org/file_download.php?file_id=2956&type=bug
wedgeExtrude.tar-2.gz (3,415 bytes) 2020-04-21 22:10
https://bugs.openfoam.org/file_download.php?file_id=2957&type=bug
Notes
(0011296)
jheylmun   
2020-04-21 22:10   
I uploaded the wrong case originally. Apologies.
(0011297)
henry   
2020-04-21 22:26   
How important is extruding a wedge in parallel? How large is your case that you need to extrude a 2D wedge in parallel?
(0011298)
jheylmun   
2020-04-21 22:32   
Our case is 25 million currently, but potentially more.
(0011299)
henry   
2020-04-21 22:53   
25 million cell 2D case?
(0011300)
jheylmun   
2020-04-21 22:56   
Yes. We have a very large domain, and a high resolution is needed.
(0011302)
henry   
2020-04-22 10:44   
I have applied this fix to OpenFOAM-dev which should resolve the problem:

commit 6e43847f5eb211d57f3e515caa3c35e0adc0b0e1 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://openfoam.org>
Date: Wed Apr 22 10:40:55 2020 +0100

    extrudeMesh: Ensure the polyTopoChange runs on all processors if edge collaping has occurred on any
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3486
(0011303)
jheylmun   
2020-04-22 14:32   
That fixed it. Thank you.
(0011304)
henry   
2020-04-22 15:22   
Resolved by commit 6e43847f5eb211d57f3e515caa3c35e0adc0b0e1


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3487 [OpenFOAM] Bug text always 2020-04-22 07:13 2020-04-22 10:11
Reporter: wwzhao Platform: Unix  
Assigned To: henry OS: Other  
Priority: none OS Version: (please specify)  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Wrong comments for functionObject::end()
Description: Related source file: src/OpenFOAM/db/functionObjects/functionObject/functionObject.H

The comment for functionObject::end() includes "By default it simply calls execute()."

However, in the source file, it simply returns true.

bool Foam::functionObject::end()
{
    return true;
}

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011301)
henry   
2020-04-22 10:11   
Resolved by commit a4fb8c64603f6ab6f0e170efe32202359d6476e1


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3480 [OpenFOAM] Bug major always 2020-04-14 13:14 2020-04-18 14:21
Reporter: zhangxusjtu Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: dev  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Error in a fomula of the lagrangian library at /PhaseChangeModel/LiquidEvaporation/LiquidEvaporation.C
Description: At line 197 to calculate the vapor concentration at surface: const scalar Cs = pSat/(RR*Ts);. Here, `Cs` is supposed to be the surface vapor concentration of component i.

According to Raoult's law, the partial pressure of each component of an ideal mixture of liquids is equal to the vapour pressure of the pure component multiplied by its mole fraction in the mixture. The partial vapor pressure of component i can be calculated with `ps = X[lid]*pSat`, and the corresponding vapor concentration should be `Cs = X[lid] * pSat/(RR*Ts)`.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011292)
will   
2020-04-16 11:59   
(Last edited: 2020-04-16 11:59)
Just looking at the code, I agree with you. However, the code is not straightforward, and I can't be 100% sure. I need some evidence that the current implementation is wrong and that your proposal is correct. This is a commonly used model; we can't just change it on a hunch. Do you have any evidence?

It seems to me that you could prove the correct-ness of this model in the presence of multiple species by creating two cases that simulate the evaporation of a single drop (potentially in a single cell). The drop in the first case would be 100% water. The second would be 50% water and 50% some other species with identical properties to water. If the results were the same, then the handling of Raoult's law would be proven consistent. Can you construct such a test?

(0011294)
zhangxusjtu   
2020-04-16 12:51   
I agree with you, and the proposed test case is convincing. I will try it later.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3485 [OpenFOAM] Bug text always 2020-04-16 16:15 2020-04-16 16:51
Reporter: Tobermory Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: low OS Version: 12.10  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Error in the description of the blended scheme for the omega wall function
Description: In the documentation for the omega wall function (https://cpp.openfoam.org/v7/classFoam_1_1omegaWallFunctionFvPatchScalarField.html), under "Detailed Description", the text states that with the blended scheme, the omega value is calculated from the sqrt of the sum of the squares of the viscous and turbulent (log law) values. Looking at the code in https://cpp.openfoam.org/v7/omegaWallFunctionFvPatchScalarField_8C_source.html, on line 236 you can see:

omega0[celli] += w*(lamFrac*omegaVis + turbFrac*omegaLog);

in other words, it is a simple linear blend, not a root-square blend.
Tags:
Steps To Reproduce: Review the documentation.
Additional Information: I suspect that this is legacy text, since i know that these wall functions have been revisited a few times over the last decade.
System Description
Attached Files:
Notes
(0011295)
henry   
2020-04-16 16:51   
Resolved in OpenFOAM-dev by commit 46f5de875da3acc9c1bc8a81ef05978581ea1d6b


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3471 [OpenFOAM] Bug minor have not tried 2020-03-26 14:47 2020-04-16 12:30
Reporter: FoamerSv Platform: GNU/Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 14.04  
Status: new Product Version: 7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bugs to calculate the thickness of liquid sheet in LISAAtomization
Description: The codes in LISAAtomization.C#L148
hSheet = volFlowRate/(constant::mathematical::pi*delta*Urel);
It is obviously to demonstrate the calculation of thickness of liquid sheet, hSheet. volFlowRate is the volume rate [m3/s]. delta is the radial distance from the center line (injector direction) to the mid-line of the sheet (umbrella rib). Urel is the velocity of parcel.
Should not it be calculated by the following sentence?
hSheet = volFlowRate/(constant::mathematical::twoPi*delta*Urel);
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: 2020-03-26_182131.png (14,233 bytes) 2020-03-26 14:47
https://bugs.openfoam.org/file_download.php?file_id=2947&type=bug
Notes
(0011293)
will   
2020-04-16 12:30   
I agree with your analysis, but to be confident enough to release the proposed change I need some way of testing it, and some evidence to suggest that it is beneficial. We don't have a tutorial that uses this functionality and there isn't even a usage description in the header. Given that, and with reports stating that the implementation is incorrect, I would be more inclined to remove this model than to patch it.

Do you have a case which uses this model, and which demonstrates the need for your proposed change?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3481 [OpenFOAM] Bug minor always 2020-04-15 09:56 2020-04-15 15:10
Reporter: DaveD Platform: GNU/Linux  
Assigned To: will OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Bug in wallHeatFlux field calculation for patches
Description: In OpenFoam v7, one can give the wall patches for which the wallHeatFlux field shall be calculated, otherwise wallHeatFlux is calculated for all wall patches.

wallHeatFlux
{
    type wallHeatFlux;
    libs ("libfieldFunctionObjects.so");
    patches ("wall_heated");
    writeControl writeTime;
}

In postprocessing/wallHeatFlux/0/wallHeatFlux.dat, OpenFoam writes the min/max/integral values of the patch "wall_heated" as it should.
However, in the volScalarField that is created for each writeTime, wallHeatFlux is calculated for arbitrary patches, no matter which patches are being specified for calculation. In my case, wallHeatFlux was calculated for wall_heated and for inlet, the latter of which is purely non-sense.

Obviously, wallHeatFlux loops for the field creation over all boundaries and not the ones being specified (wallHeatFlux.C, line 87 f.):

    forAll(wallHeatFluxBf, patchi)
    { ...

In contrast, wallShearStress does what it should (wallShearStress.C, line 79 ff.):

    forAllConstIter(labelHashSet, patchSet_, iter)
    {
        label patchi = iter.key();
        ...

See also https://www.cfd-online.com/Forums/openfoam-post-processing/225743-bug-feature-wallheatflux-calculation-patches.html
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011291)
will   
2020-04-15 15:10   
Agreed. wallHeatFlux should output values on walls only, unless finer per-patch control is specified by the user. Resolved in dev by https://github.com/OpenFOAM/OpenFOAM-dev/commit/d3fed1155a1ba1ea7904516e5816577da3c15458.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3482 [OpenFOAM] Bug crash have not tried 2020-04-15 11:25 2020-04-15 11:33
Reporter: Henning86 Platform: Unix  
Assigned To: henry OS: Other  
Priority: immediate OS Version: (please specify)  
Status: resolved Product Version: dev  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: missing library lcompressibleTransportModels
Description: OpenFoam-dev (commit e3cd6341047d) does not compile as it is missing the library lcompressibleTransportModels.
It apears that lcompressibleTransportModels was removed but is still present in:

grep -r lcompressibleTransportModels:

src/MomentumTransportModels/compressible/Make/options: -lcompressibleTransportModels \
applications/solvers/multiphase/compressibleInterFoam/VoFphaseCompressibleMomentumTransportModels/Make/options: -lcompressibleTransportModels \
applications/solvers/multiphase/twoPhaseEulerFoam/phaseCompressibleMomentumTransportModels/Make/options: -lcompressibleTransportModels \

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011287)
henry   
2020-04-15 11:33   
Already fixed:

commit 7c402dde4e459101e0e9d096acbadf04b5d63b62
Author: Henry Weller <http://openfoam.org>
Date: Wed Apr 15 11:17:16 2020 +0100

    Removed redundant library link statements


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3479 [OpenFOAM] Bug minor sometimes 2020-04-10 14:17 2020-04-10 16:09
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: wordAndDictionary, compilation error with gcc older than v 7
Description: When compiling dev with an older gcc, the compilation fails with
"error: no matching function for call to ‘Foam::wordAndDictionary::wordAndDictionary()’"

It seems that the compiler is unable to find a constructor which takes no parameters for that class. The constructor is created with a using clause
using Tuple2<word, dictionary>::Tuple2;

Tupple2 does have such a constructor, so this is likely a compiler bug. While investigating, I found out that C++11 standard has been reworded regarding inheriting constructors and only gcc 7 or newer support this. The rewording seemed complicated, so I don't know if it is related to this or not, but at least it matches my observations when testing various compilers as v. 5 and 6 seemed to fail.

If the using-clause is replaced with a regular constuctor definition, the code compiles with older compilers.
Tags:
Steps To Reproduce: Compilations with 5.3.1, 5.4.0, 6.3.0 fail, 7.5.0 works.
Additional Information:
Attached Files:
Notes
(0011286)
henry   
2020-04-10 16:09   
Resolved by commit b9c74286192892fa4711a9885f9739ac90abe14c


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3478 [OpenFOAM] Patch minor always 2020-04-08 13:53 2020-04-10 09:37
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: copiedFixedValue, fixedMultiPhaseHeatFlux: added missing clone and mapping functions
Description: I have attached a patch which adds missing clone functions to copiedFixedValue and fixedMultiPhaseHeatFlux. Due to missing functions, if user is loading libraries in controlDict which include these BCs, the missing clone-functions cause issues. For example reconstructed fields will became fixedValue.

The patch also adds rmap and automap functions to fixedMultiPhaseHeatFlux because it has a scalarField member variable.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch.diff (5,464 bytes) 2020-04-08 13:53
https://bugs.openfoam.org/file_download.php?file_id=2951&type=bug
typos.diff (6,545 bytes) 2020-04-09 05:52
https://bugs.openfoam.org/file_download.php?file_id=2952&type=bug
Notes
(0011283)
tniemi   
2020-04-09 05:52   
Here is also a small patch for some completely random, unrelated typos.
(0011285)
henry   
2020-04-10 09:37   
Thanks Timo

Resolved by commit 53ac3f223ad399df78ec40f72bc271776356c68d


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3473 [OpenFOAM] Bug minor always 2020-04-01 12:15 2020-04-01 17:05
Reporter: jkim2000 Platform: Intel PC  
Assigned To: henry OS: ubuntu  
Priority: low OS Version: 18.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: wallHeatFlux and P1 radiation
Description: During postProcessing with wallHeatFlux, it was found that P1 radiation heat flux is not added, and only the convective heat flux is calculated and saved in the field of "wallHeatFlux"

It was expected that wallHeatFlux in the case with P1 radiation must be larger than WallHeatFlux in the case without radiation.
But, the wallHeatFlux function gives same heat flux in the cases without radiation and with P1 radiation

The problem is from that in P1.C code read-option of qr is NO_READ. On the contrary in FvDOM.C read-option of qr is READ_IF_PRESENT, which means that an object of the P1 radiation model created by wallHeatFlux function does not read the qr field.

When the read-option of qr in P1.C code is changed to READ_IF_PRESENT, wallHeatFlux function gives the sum of convective and radiative heat flux
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: P1.C (6,606 bytes) 2020-04-01 12:15
https://bugs.openfoam.org/file_download.php?file_id=2948&type=bug
Notes
(0011279)
henry   
2020-04-01 17:05   
Resolved by commit 4867477252f4da773ea4bb5bd03d2740d88f2d00


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3458 [OpenFOAM] Contribution minor N/A 2020-02-20 10:31 2020-03-24 16:54
Reporter: kevnor Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: unable to reproduce  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: meshToMesh0::cellAddresses speed up
Description: In the moderate-sized (~20M cell) mesh mappings I've been testing on non-convex geometries, the computation of mesh-to-mesh cell addressing in meshToMesh0::cellAddresses can be sped up significantly (in some cases by > 100x) by updating the current position 'curCell' in the source mesh to correspond to the cell returned by the octree search whenever this is performed. If this isn't done, the curCell in the source mesh can get 'stuck' at an edge, with the result that octree search is used for all the following points that are not visible from curCell, at great expense.

I've attached a patch that implements this.

Also, I'm not sure that I understand the point of the "rescue" logic in the same routine and this is also causing a slow-down in our cases! It seems that it merely avoids checking neighbour cells if the closest cell-centre is on the boundary and just goes straight to octree search. However, when meshes are graded near the boundary (as they often are), it is actually fairly common for the point to lie in a neighbour cell. It's relatively cheap to check these neighbours and expensive to do a full octree search...

A second patch is included that implements both this and the curCell update.

As I said, disabling the rescue logic results in speed-ups for the cases we're looking at, but I guess that there must be situations where it helps for it to have been introduced in the first place?! It seems to have been there since at least version 2.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: meshToMesh0_noRescue.patch (7,244 bytes) 2020-02-20 10:31
https://bugs.openfoam.org/file_download.php?file_id=2917&type=bug
meshToMesh0_updateCurCell.patch (1,083 bytes) 2020-02-20 10:31
https://bugs.openfoam.org/file_download.php?file_id=2918&type=bug
Notes
(0011205)
henry   
2020-02-21 15:35   
(Last edited: 2020-02-21 15:35)
For what range of cases have you tested these patches?

(0011208)
kevnor   
2020-02-21 17:32   
So far I've only tested it on 4 different cases here (plus those tutorial cases that use mapFields, though those are all rather small). Our cases include tet and hex meshes between 2 million and 30 million cells and a variety of different geometries. I get widely varying speedups for the different cases, but the patched versions are faster than the unpatched for all the larger cases. I can post more exact figures if its useful?

Unfortunately I'm not able to upload the meshes I've tested so far here, but I will try and put together some simple blockMesh / snappyHexMesh meshes that demonstrate the issue shortly!

I understand this is going to need further testing to make sure that it doesn't break anything -- in particular, as I mentioned above, I guess that the 'rescue' logic must have been put in for a good reason.
(0011264)
henry   
2020-03-20 21:20   
(Last edited: 2020-03-20 21:32)
On the complex geometry cases I have tested meshToMesh0_updateCurCell.patch gives a slight improvement in performance but meshToMesh0_noRescue.patch gives a very significant drop in performance. The results of the mapping are the same for the current version and both patches.

(0011265)
henry   
2020-03-20 21:24   
Can you provide any case which shows the benefit of the either or both of the two patches?
(0011275)
henry   
2020-03-24 16:54   
I have committed the "curCell" optimisation as it shows a minor improvement in performance for some cases.

commit 4be01b4e70e4bab877346cce52900a59fd6bfeac

However removing the "rescue" logic has a significant detrimental effect for all the cases I have tested and I have not committed it.
We have not found any cases for which either change provides significant benefit and we need you to provide a means to reproduce your findings in order to work further on this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3466 [OpenFOAM] Bug minor always 2020-03-11 13:17 2020-03-15 10:18
Reporter: Heikuna Matata Platform: Ubuntu 18.04.4 LTS bionic  
Assigned To: henry OS: Other  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Error using rhoCentralFoam's BC maxwellSlipU parallel
Description: Hello,

I noticed a problem concerning rhoCentralFoam's boundary condition maxwellSlipU. The boundary condition contains 3 vector fields, Uwall, value and refValue. When running a case parallel and reconstructing the case, it can occur, that these vector fields aren't reconstructed as vector fields, but as scalar fields containing numeric limits values. Without parallelization this issue doesn't occur.
The results can be viewed in paraView without errors, but if one wants to simulate further steps from this reconstructed state the following error message occurs:

/*---------------------------------------------------------------------------*\
  ========= |
  \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
   \\ / O peration | Website: https://openfoam.org
    \\ / A nd | Version: 7
     \\/ M anipulation |
\*---------------------------------------------------------------------------*/
Build : 7-1ff648926f77
Exec : rhoCentralFoam
Date : Mar 11 2020
Time : 13:42:33
Host : "ip98linux"
PID : 3327
I/O : uncollated
Case : /home/pleskun/Heiko/CouetteFlow/b_h_2/p10/test2Cores/testCase
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 1e-06

Reading thermophysical properties

Selecting thermodynamics package
{
    type hePsiThermo;
    mixture pureMixture;
    transport const;
    thermo hConst;
    equationOfState perfectGas;
    specie specie;
    energy sensibleInternalEnergy;
}

Reading field U



--> FOAM FATAL ERROR:
Attempt to cast type N4Foam5token8CompoundINS_4ListIdEEEE to type N4Foam5token8CompoundINS_4ListINS_6VectorIdEEEEEE

    From function To& Foam::dynamicCast(From&) [with To = Foam::token::Compound<Foam::List<Foam::Vector<double> > >; From = Foam::token::compound]
    in file /home/ubuntu/OpenFOAM/OpenFOAM-7/src/OpenFOAM/lnInclude/typeInfo.H at line 93.

FOAM aborting

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::Istream& Foam::operator>><Foam::Vector<double> >(Foam::Istream&, Foam::List<Foam::Vector<double> >&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/rhoCentralFoam"
#3 Foam::Field<Foam::Vector<double> >::Field(Foam::word const&, Foam::dictionary const&, int) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/rhoCentralFoam"
#4 Foam::maxwellSlipUFvPatchVectorField::maxwellSlipUFvPatchVectorField(Foam::fvPatch const&, Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#5 Foam::fvPatchField<Foam::Vector<double> >::adddictionaryConstructorToTable<Foam::maxwellSlipUFvPatchVectorField>::New(Foam::fvPatch const&, Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#6 Foam::fvPatchField<Foam::Vector<double> >::New(Foam::fvPatch const&, Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/rhoCentralFoam"
#7 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::readField(Foam::DimensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/rhoCentralFoam"
#8 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::readFields(Foam::dictionary const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/rhoCentralFoam"
#9 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::readFields() in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/rhoCentralFoam"
#10 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/rhoCentralFoam"
#11 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/rhoCentralFoam"
#12 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#13 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/rhoCentralFoam"
Abgebrochen (Speicherabzug geschrieben)

Tags:
Steps To Reproduce: Use the attached test case with following commands

blockMesh
decomposePar
mpirun -np 4 rhoCentralFoam -parallel
reconstructPar

Check the vectorFields Uwall and refValue in boundary upperWall at time step 1e-6 of the U field. These are now described as nonuniform List<scalar> instead of nonuniform List<vector>.
I think it is because processor0 does not contain any part of this boundary.

Change endTime in the controlDict to 2e-6 and rerun the simulation to get the above mentioned error message.
Additional Information: One can fix it by hand, with the correct values, but this can be a very annoying task especially when you have several million cells and many simulations.

Cheers,
Heiko
System Description
Attached Files: testCase.7z (2,363 bytes) 2020-03-11 13:17
https://bugs.openfoam.org/file_download.php?file_id=2941&type=bug
Notes
(0011248)
henry   
2020-03-11 23:23   
This should be resolved in OpenFOAM-dev by commit 220507b4f5b54220d12054606ac24079f8627975
(0011249)
Heikuna Matata   
2020-03-13 08:03   
Thank you very much.
(0011250)
henry   
2020-03-15 10:18   
Resolved in OpenFOAM-dev by commit 220507b4f5b54220d12054606ac24079f8627975


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2456 [OpenFOAM] Bug major always 2017-02-09 13:43 2020-03-10 13:36
Reporter: fsch1 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: curvatureSeparation in 'Hot Boxes'-tutorial doesn't work
Description: Hello,
in the hotBoxes-tutorial of the reactingParcelFilmFoam the curvatureSeparation doesn't work.

Run the case, e.g 5s. In result-file ./5/uniform/regionModels/wallFilmRegion/wallFilmRegionOutputProperties all the injectedMass is due to drippingInjection and 0 for curvatureSeparation.

In addition, the wallFilm-height deltaf gets to high for my understanding. And then the minimum temperature in the thermoSingleLayer/wallFilm goes down to 270K instead staying at more less 300K.
I think it's a problem for the model if the wallFilm gets to high. But I think it's caused by the water not separating at the bottom of the boxes...
Tags: curvatureSeparation
Steps To Reproduce: Run hotBoxes-tutorial
Additional Information:
Attached Files: bugCurvatureSeperation.zip (3,499,933 bytes) 2017-02-10 13:08
https://bugs.openfoam.org/file_download.php?file_id=1979&type=bug
testcase_curvatureSeparation.tgz (8,749 bytes) 2017-02-10 14:58
https://bugs.openfoam.org/file_download.php?file_id=1981&type=bug
V03_TestCase_CurvatureSeparation.zip (30,925 bytes) 2019-06-21 13:40
https://bugs.openfoam.org/file_download.php?file_id=2705&type=bug
curvatureSeparation.C (10,469 bytes) 2019-07-01 13:13
https://bugs.openfoam.org/file_download.php?file_id=2709&type=bug
curvatureSeparation.H (4,520 bytes) 2019-07-01 13:13
https://bugs.openfoam.org/file_download.php?file_id=2710&type=bug
Notes
(0007734)
fsch1   
2017-02-10 13:08   
I've added a small testcase.

the curvatureSeperation is the only injectionModel activated. And there are some parcels generated. So curvatureSeperation seems to work.

But in 0.05 uniform/regionModels/wallFilmRegion/wallFilmRegionOutputProperties there is no count for the injected parcels by curvatureSeperation...


Run:
Allpre
reactingParcelFilmFoam

Note: the numeric instability is due to the high wallFilm height deltaf in beginning for demonstrating the effect in the first timesteps
(0007737)
shildenbrand   
2017-02-10 14:58   
I can confirm this problem with curvatureSeparation. I also attached a different testcase which shows this behaviour: When using curvatureSeparation only, the case gets instable and temperatures behave stange.
When using another model (BrunDripping or Dripping) the case stays stable.
I don't think it has something to do with the film height but rather with the model itself.
(0010524)
fsch1   
2019-06-21 13:40   
Hello again,
after a long time I took a look into this case again and updated it to work with the newer OpenFoam-dev versions.
In short it's a box with a water film on it, which starts dry by the water running of due to gravity.

To run more stable all the temperatures are the same (293 K) and constrained via fvOptions and the phaseChangeModel is deactivated.

1. Bug
Shildenbrands point is correct regarding the instability of the curvatureSeparation-model. I think it is due to this two lines in the curvatureSeparation.C:
...
 const volScalarField& delta = film.delta();
...
diameterToInject = separated*delta;
...

As far as I understand the code, if droplets are separating, the diameter of these droplets are the same as the film height.
So this does not make sense.
Additionally if the film height is really low, the 1e8 to 1e11 particle are added into one single parcel. This is also the point when the simulation becomes instable (in the attached case shortly after 0.07s).

I think it's necessary to implement some checks (like in drippingInjection.C, starting line 129), that droplets only can separate, if a minMass is overcome. For the diameter I don't know what's the best solution.


2.Bug
The mass injected by the curvatureSeparation-Model continues to be neglected in the outputProperties.
As you can see in the wallFilmRegionOutputProperties below injectedMass is zero, even more ~1500 parcels detached the film.

...
    location "0.07/uniform/regionModels/wallFilmRegion";
    object wallFilmRegionOutputProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

addedMassTotal 0.006046627137;

injectionModel
{
    curvatureSeparation
    {
        injectedMass 0;
    }
}



Hope this helps in locating these bugs.
(0010537)
fsch1   
2019-07-01 13:13   
Regarding 1.)
I have attached a proposed patch of the curvatureSeparation.
The patch introduces a stable film thickness (similar as in the two other existing injectionModels brunDrippingInjection/ drippingInjection) which have to be exceeded for the model to activate the separation.

With a film tickness deltaStable = 0.0001 the attached test case as well as the Hot Boxes - Tutorial stay numerically stable.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3461 [OpenFOAM] Bug minor have not tried 2020-02-27 17:25 2020-02-28 16:58
Reporter: amtri Platform: GNU/Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 15.04  
Status: new Product Version: 7  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: cellSet ascii files incorrectly reported as format binary
Description: This is what files I am receiving look like:

/*--------------------------------*- C++ -*----------------------------------*\
  ========= |
  \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
   \\ / O peration | Website: https://openfoam.org
    \\ / A nd | Version: 7
     \\/ M anipulation |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version 2.0;
    format ascii;
    class cellSet;
    location "constant/polyMesh/sets";
    object porosity;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //


18400
(
131072
65536
131073
...
Tags:
Steps To Reproduce: I haven't generated these files. I'm just trying to read them with my own source code. I noticed that only files under "sets" have this problem. I am not familiar with the source code, but the output appears incorrect. If my observation is not correct please close this issue.
Additional Information:
System Description
Attached Files: porosity (138,015 bytes) 2020-02-27 17:25
https://bugs.openfoam.org/file_download.php?file_id=2922&type=bug
Notes
(0011213)
wyldckat   
2020-02-27 19:11   
@amtri: If you haven't generated this file, then how was this file generated in the first place?

Please provide the indication of which OpenFOAM utility you have used to generate this file, so that this error can be reproduced.
(0011215)
amtri   
2020-02-27 19:36   
I have contacted my client who needs to contact his client. I've asked him for permission to share the entire model if possible, as well as complete information on the OpenFOAM version (and distribution...) used.
(0011216)
wyldckat   
2020-02-27 19:43   
We don't need the complete model, we only need to know what application was used to generate this file, namely if it was with:

1. topoSet
2. setSet
3. snappyHexMesh

I ask this because it is possible that this 'set' file was actually created by another application outside of OpenFOAM.
(0011217)
amtri   
2020-02-27 20:20   
If I'm lucky I'll have your answers tomorrow. Next week is more probable. Thanks for the quick response.
(0011218)
amtri   
2020-02-27 22:25   
The customer is using topoSet.
(0011219)
amtri   
2020-02-27 22:33   
One more piece of information:

"When I changed “format binary;” to “format ascii” in porosity porousCellSet (in the case of controlDict including writeformat binary) and ran topoSet, then the file could not be read".

Perhaps the above isn't quite clear and I apologize for that. I'm not familiar with how OpenFOAM works, but I know that if the data in the file is ascii the format shouldn't say binary or vice-versa. That's what's creating problems for me when I read the file.
(0011220)
will   
2020-02-28 09:21   
(Last edited: 2020-02-28 09:22)
I can reproduce this. A topoSet stores it's information via derivation from HashTable, which does not have binary IO implemented. Hence always coming out as ascii. Binary IO needs adding.

(0011222)
amtri   
2020-02-28 15:25   
If I understand what you're saying then:

1) What the customer is doing is correct and valid.

2) Since cellSet with topoSet does not have a binary IO implemented, it should have had the "format ascii" in its header. And this is indeed a bug.

Am I correct?

Thanks.
(0011223)
will   
2020-02-28 16:56   
It is a bug. It should not have "format ascii" in it's header, it should be written in binary, as that is the case setting. If it wrote the file ascii with "format ascii" in it's header when "format binary" was selected in the controlDict, I would still consider that a bug.
(0011224)
amtri   
2020-02-28 16:58   
Thanks! I'll let my customer know. He will inform his customer to change the format in those files until a new release is available that fixes the problem.

Much appreciated!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3457 [OpenFOAM] Bug minor sometimes 2020-02-19 20:08 2020-02-25 20:56
Reporter: sjohn2 Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 15.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Error in boundary condition prghTotalPressure
Description: The field varible 'p' picks up a uniform value of p0 specified in prghTotalPressure boundary condition in field p_rgh. At the inlet p_rgh is a non uniform scalar field while p is a uniform field. This leads to abnormality in the internalField.
Tags:
Steps To Reproduce: re-run case files attached
Additional Information:
System Description
Attached Files: CD_NOZ_3D_rtpef_BNL_291_lam_cse8_TP_oldcase_pWAL_dev_bc_test.zip (1,940,814 bytes) 2020-02-19 20:09
https://bugs.openfoam.org/file_download.php?file_id=2916&type=bug
CD_NOZ_3D_rtpef_BNL_291_lam_cse8_TP_oldcase_pWAL_dev_bc_test-2.zip (1,846,985 bytes) 2020-02-21 14:56
https://bugs.openfoam.org/file_download.php?file_id=2919&type=bug
CD_NOZ_3D_rtpef_BNL_291_lam_cse8_TP_oldcase_pWAL_dev_bc_test-3.zip (1,808,929 bytes) 2020-02-21 16:25
https://bugs.openfoam.org/file_download.php?file_id=2920&type=bug
Notes
(0011199)
sjohn2   
2020-02-20 21:47   
solver is reactingTwoPhaseEulerFoam
(0011200)
henry   
2020-02-21 12:48   
In a p_rgh solver p should have calculated BCs so that it is calculated from the current p_rgh and rho distributions. It is not clear why you the field varible 'p' picks up a uniform value of p0 if the 'p' BCs are calculated.
(0011201)
sjohn2   
2020-02-21 14:56   
Please check the boundary field 'p' after 0.01 seconds
It is picking up INLET
    {
        type calculated;
        value uniform 514174;
    }

instead of values based p_rgh.

On a seperate note, in the p_rgh file after 0.01 seconds, if I uncomment lines
// phi phi.liquid;
// rho thermo:rho.liquid;
in the inlet field at initial time, I found that p_rgh also picked up
   value uniform 514174; which is basically p0
at the inlet after 0.01 secs.

Note : there is not volume fractions of gas phase in the inlet
(0011202)
henry   
2020-02-21 15:11   
In what way are the p values not based on p_rgh?

Can you provide a patch which changes the BC how you want it to be for us to consider?
(0011203)
sjohn2   
2020-02-21 15:29   
I did not mean to say that the p values are not based on p_rgh.
Can you run the original case till 0.001 secs and check the boundary field p. They are taking a uniform value of 'p0' and please compare it with the boundary field of p_rgh at the same time.
(0011204)
henry   
2020-02-21 15:32   
(Last edited: 2020-02-21 15:33)
I am not aware of any problem in either the prghTotalPressure BC or the evaluation of p. See if you can reproduce the problem in one of the tutorial cases with uses the prghTotalPressure BC.
Alternatively can you provide a patch which corrects the problem for your case which we can study?

(0011206)
sjohn2   
2020-02-21 16:25   
I have checked all tutorials for multiphase solvers and all of them use prghPressure at the outlet, which is different from my case, so I am not sure how I can reporduce my problem from it. I will detail my problem:
I am trying to simulate phase change in a nozzle using reactingTwoPhaseEulerFoam using pressure based boundary conditions. I have used prghTotalPressure at the inlet and prghPressure at outlet and pressure based boundary conditions for the velocity field. Rest BC are standard.
I have set a total pressure p0 514174 at the inlet and 454700 at the outlet. The p BC's are set to be calculated based in internal field.
In this particular case,
As p =p_rgh - rho g x
At the inlet p = p_rgh as x=0;
IF you check the attached file in the note here:
you can find in the boundary field 0.001/p

    INLET
    {
        type calculated;
        value uniform 514174; <----- is the value of total pressure I have given in the problem.
    }

while in the 0.001/p_rgh file we can se that

    INLET
    {
        type prghTotalPressure;
        U U.liquid;
        rho rho;
        psi none;
        gamma 1;
        p0 uniform 514174;
        value nonuniform List<scalar>
24
(
514173.201842
514173.201842
514173.201842
514173.201842
514173.201842
514173.201842
514173.201841
514173.201841
514173.201841
514173.201841
514173.201841
514173.201841
514173.20184
514173.20184
514173.20184
514173.20184
514173.201839
514173.201839
514173.201839
514173.201839
514173.201838
514173.201838
514173.201965
514173.20699
)
;
    }


Shouldn't be p =p_rgh? and how can p have a value of total pressure when there is some value of velocity pressure in the inlet face.
(0011207)
sjohn2   
2020-02-21 16:28   
correction in this first line:
I have checked all tutorials for multiphase solvers and all of them use "prghTotalPressure" at the outlet, which is different from my case, so I am not sure how I can reporduce my problem from it.
(0011209)
henry   
2020-02-23 22:24   
The issue does not relate to the boundary condition prghTotalPressure but the use of pressureInletOutletVelocity for inlet velocity which was not explicitly supported for multiphase.
I have now generalised support for derived fixedValue BCs using the assignable() member function which should resolve this problem and potential problems with other derived fixedValue BCs.

Resolved by commit 5b4e84c97bf272104f432406b22fc8728d751da2
(0011211)
sjohn2   
2020-02-25 20:21   
i think this issue has been resolved, works correctly for 3D cases.
(0011212)
henry   
2020-02-25 20:56   
Resolved by commit 5b4e84c97bf272104f432406b22fc8728d751da2


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3459 [OpenFOAM] Patch minor N/A 2020-02-23 14:09 2020-02-24 17:51
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Patch for adding phase support for moleFractions function object
Description: I have attached a simple patch which adds the option to specify a phase name to rho/psiReactionThermoMoleFractions function objects. This allows the function object to work in multiphase cases.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch.diff (4,112 bytes) 2020-02-23 14:09
https://bugs.openfoam.org/file_download.php?file_id=2921&type=bug
Notes
(0011210)
henry   
2020-02-24 17:51   
Resolved by commit b559ef28ef527389de95f099a76622a86c2f22d7


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3445 [OpenFOAM] Bug crash always 2020-02-07 09:18 2020-02-24 09:16
Reporter: stardust23 Platform: Linux  
Assigned To: will OS: Debian  
Priority: normal OS Version: 10  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: CyclicAMI not working with small prism cells to reproduce boundary layer on the patch
Description: I’m trying to run the steady-state case of a pump impeller with SRFSimpleFoam. To reduce the computational cost, I’d like to simulate only one blade with cyclicAMI patches on the periodicity boundaries.
Unfortunately the simulation crashes due to these cyclic interfaces. I tried to modify the mesh and it seems that the problem is related to the thin prismatic cells used for hub and tip BLs on the AMI patches (removing these cells the simulation starts normally).
I’m sharing the complete case that is not working hoping that someone could help finding a way to solve the problem: https://drive.google.com/drive/folders/1DMW2SrAIoC1w6hMbSNjX2EwBhS29Tp_B?usp=sharing
The archive contains all the files needed to run the case (mesh, initialization, etc.)

Tags:
Steps To Reproduce: Unzip the archive and run SRFSimpleFoam in the extracted folder.
Additional Information:
System Description
Attached Files:
Notes
(0011197)
will   
2020-02-18 11:27   
In version 7 and earlier OpenFOAM has no ability to calculate transformations non non-planar cyclic patches such as these. You will need to specify the rotation angles on both sides as well as the axis and centre.

OpenFOAM-dev can now automatically calculate cyclic transformations on patches such as these as a result of the following commit.

https://github.com/OpenFOAM/OpenFOAM-dev/commit/7010a8ec24fc64214a5b6c641266e09618f4fd32

Note that for AMI-type patches you will need to specify "transform unspecified;" for it to calculate the transformation, otherwise it will assume that there is no transformation.

Note even with the transformation fully specified the geometric match is poor and the AMI weights are very
 far from unity. That is a problem with your meshing strategy.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1993 [OpenFOAM] Bug minor always 2016-02-14 12:00 2020-02-19 15:49
Reporter: will Platform: GNU/Linux  
Assigned To: will OS: OpenSUSE Leap  
Priority: normal OS Version: 42.1  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Face centres (and by extension, cell centres) are calculated incorrectly when the initial guess is outside the face
Description: primitiveMesh::makeFaceCentresAndAreas calculates the cell centres first by making an initial guess of the centre, then doing an area weighted average of the centres of the triangles made between this guess and each edge. The problem is that it uses the magnitude of each triangle's normal. If the initial guess is outside the face, then some of the triangles will be inverted, and their contributions to the average should be subtracted.
Tags:
Steps To Reproduce: Run blockMesh and calcCellCentres on the attached case. The centre of the smaller cell should be coincident with the inner points at (x, y) = (0.25, 0.25). You can work this out by hand by averaging the centres of the two triangles. OpenFOAM does not reproduce this result.
Additional Information: A fix can be found here <https://github.com/OpenFOAM/OpenFOAM-dev/compare/master...will-bainbridge:veryConcaveFaceCentres>· Essentially, the magnitude operation is replaced by a dot product with the unit normal, which is calculated in a separate loop. Inverted triangles have opposite normals, which generate the correct sign.

This changes the behaviour of the worst cells significantly. Snappy's quality criteria will be affected, and the coefficients of many interpolations and gradient calculations will change. I havent the resources to run big snappy cases and assess the effect of this change. I guess it might be sensible to put a switch in to control the behaviour.
System Description
Attached Files: veryConcaveFace.tar.gz (2,432 bytes) 2016-02-14 12:00
https://bugs.openfoam.org/file_download.php?file_id=1465&type=bug
Notes
(0005940)
will   
2016-02-14 12:04   
Mantis has mangled linking the URL a bit. Without angle brackets...

https://github.com/OpenFOAM/OpenFOAM-dev/compare/master...will-bainbridge:veryConcaveFaceCentres
(0005942)
henry   
2016-02-14 20:34   
Thanks for the update; I am testing a few large snappyHexMesh cases now, will report any problems.
(0005944)
henry   
2016-02-15 11:19   
This change generally works fine, at least for the cases for which it does not significantly affect the face-centre. The only case for which I see a serious problem is with the foamyHexMesh mixerVessel case for which this change causes the meshing to crash:

Face collapsing is on
    Initial face length factor = 0.35
Control mesh quality = on
    Minimum edge length reduction factor = 0.5
    Minimum face area reduction factor = 0.5
    Maximum number of collapse iterations = 10
    Maximum number of edge/face reduction factor smoothing iterations = 1
    Maximum number of times a point can contribute to bad faces across
    collapse iterations = 3
Selectively disabling wanted collapses until resulting quality satisfies constraints in system/meshQualityDict

Outer Iteration = 0

    "Edge Filter Factor": min = 1e-06 av = 1e-06 max = 1e-06
        9964310 / 9964310 elements used

    Inner iteration = 0

        Collapsing 219079 small edges
[2]
[2]
[2] --> FOAM FATAL ERROR:
[2] More than six unsigned transforms detected:
6(((-1.468232221e-07 7.520275254e-06 2.867305949e-05) (1 0 0 0 1 0 0 0 1) 0) ((4.769817608e-08 -2.443097266e-06 2.546124074e-06) (1 0 0 0 1 0 0 0 1) 0) ((-2.638528285e-12 1.351677346e-10 5.465866648e-11) (1 0 0 0 1 0 0 0 1) 0) ((-1.47770
9621e-11 7.568818042e-10 -1.142231587e-09) (1 0 0 0 1 0 0 0 1) 0) ((2.716529779e-11 -1.391405303e-09 4.215973237e-09) (1 0 0 0 1 0 0 0 1) 0) ((1.32806266e-11 -6.802331476e-10 -4.83081769e-10) (1 0 0 0 1 0 0 0 1) 0))
[2]
[2] From function void Foam::globalIndexAndTransform::determineTransforms()
[2] in file primitives/globalIndexAndTransform/globalIndexAndTransform.C at line 183.
[2]
FOAM parallel run exiting
(0005956)
will   
2016-02-16 21:40   
Hmmm, that's a pain, though I kind of expected a change this low down in the bowels of openfoam was likely to affect something.

I don't really to know what to do with this bug, it's just something I noticed when looking at tracking last year. The face calculation as it is is demonstrably wrong in extreme cases, but what effect this has, even whether it is detrimental or beneficial, I don't know. I simply thought that there should be a record of it, hence this report.

If I had to make a recommendation, or if I were charged with fixing this, I would probably apply my patch, but put a debug switch in or similar that lets cases revert to the current behaviour, and then set the switch for this foamy case. It's not an ideal solution, but it would get the change out and therefore widely tested. I'm also struggling to think of any other approach other than simply not fixing it.
(0005957)
henry   
2016-02-16 22:45   
I am OK with the change in principle and would rather not put it on a switch but someone would need to spend a bit of time looking into the problem triggered in foamyHexMesh; the issue is likely to be associated with some bad faces generated during the collapsing process which might be easy to fix.
(0005974)
will   
2016-02-19 19:37   
The foamy case runs for me in serial. Not sure if that makes the problem better or worse, but it's more information.
(0006020)
MattijsJ   
2016-03-08 14:36   
The error comes from the global transformations calculation. Each of them is a displacement (for separated coupled patches) and a rotation (for rotational coupled patches). As far as I remember the mixerVessel does not have any separated coupled patches nor rotational ones and there should be only one transform ((0 0 0)(1 0 0 0 1 0 0 0 1)). I guess there is an accumulation of errors (the faces can be minute, leading to large errors) which prevents the transforms from merging.
(0011198)
will   
2020-02-19 15:49   
Resolved by https://github.com/OpenFOAM/OpenFOAM-dev/commit/f85edb01fe02ffb4e88be01ceff958c65a2becb4


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3442 [OpenFOAM] Bug tweak always 2020-02-06 05:09 2020-02-17 16:40
Reporter: sjohn2 Platform: GNU/Linux  
Assigned To: henry OS: OpenSuSE  
Priority: normal OS Version: 12.3  
Status: resolved Product Version: 6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Unexpected drop at inlet temperatures noticed in reactingTwoPhaseEulerFoam
Description: The problem being simulated is flashing (phase change from liquid to gas) of steam in a convergent-divergent nozzle. Pure liquid enters the nozzle at the inlet and the phases change occurs downstream of the throat due the pressure dropping below the saturation value. The solver being used is the reactingTwoPhaseEulerFoam with the interfaceCompositionPhaseChangeTwoPhaseSystem phase system. The interface composition system being used is the Saturated type with both the constant and the antonie type are tested. A single species exists in each of the phase.

PROBLEM FACED:
The phase change is triggered only with specification of a small value of the initial volume fraction of the gas phase (1e-12).
Unexplained temperature drop is developed and convected near the first control volume near the inlet boundary. This leads to low temperatures being transported throughout the nozzle thereby leading to drop in saturation pressures and temperatures.
Tags:
Steps To Reproduce: All required files can be downloaded from the links given in pdf file attached
Additional Information:
System Description
Attached Files: REPORT.pdf (265,224 bytes) 2020-02-06 05:09
https://bugs.openfoam.org/file_download.php?file_id=2890&type=bug
Notes
(0011127)
henry   
2020-02-06 08:27   
reactingTwoPhaseEulerFoam is under active development and there have been many improvements in OpenFOAM-7 and OpenFOAM-dev. Please re-run your case in the latest OpenFOAM-dev.
(0011142)
sjohn2   
2020-02-07 07:09   
I have tested this case on OpenFoam version 7 and have found the same issues. Please find attached the results file>
I will test the case on OpenFOam-dev within couple of weeks and report.

https://www.dropbox.com/s/noo2q6vvevc86d5/CD_NOZ_3D_rtpef_BNL_291_lam_cse8_TP_oldcase_of7.tar.xz?dl=1
(0011186)
sjohn2   
2020-02-16 02:05   
I have tested this case with latest -dev version of Openfoam and found that the problem still persists.
Please find attached the files
 https://www.dropbox.com/s/19oahlx7688gb7y/CD_NOZ_3D_rtpef_BNL_291_lam_cse8_TP_oldcase_of7_dev.zip?dl=1
(0011190)
henry   
2020-02-17 10:27   
The case has a few setup problems and takes a long time to run, can you provide an 2D axisymmetric version for testing?
(0011191)
henry   
2020-02-17 14:09   
The temperature issue is caused by an accumulation of error from the pressure work term in the internal energy equation from the very small but non-zero continuity error.
To avoid this kind of error accumulation in pure incompressible phases there is an optional pressureWorkAlphaLimit control which you can set and it resolves the problem.
I have also improved the pressure work term formulation to include a continuity error compensation term:

commit 17afa7d79b09f7d2dbf71f55925c041e0f2bd32f (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://openfoam.org>
Date: Mon Feb 17 14:04:45 2020 +0000

    reactingEulerFoam::AnisothermalPhaseModel: Added a continuity error compensation term to the internal energy pressure work
    
    Reduced the accumulation of error for incompressible and low compressibility
    cases.
(0011192)
sjohn2   
2020-02-17 14:46   
Thank you Henry for the changes. I will test it when the repository package files are updated and the software is upgraded.
Can I also please request you to upload the new case with the corrected setup problems that I have missed. This will help verification and my studies at the university.
(0011193)
henry   
2020-02-17 14:56   
It would make more sense to work on an axisymmetric case; I don't see the need to run this case 3D unless you want to run it LES.

The issue with the phase change occurring only when there is at least some gas is that the current phase-change modelling is not designed for spontaneous flashing; it occurs at the interface between the phases so the interface need s to be present. Funding would be required to develop reactingEulerFoam for flashing calculations.
(0011195)
henry   
2020-02-17 16:40   
Resolved by commit 17afa7d79b09f7d2dbf71f55925c041e0f2bd32f


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3455 [OpenFOAM] Patch minor have not tried 2020-02-16 13:24 2020-02-17 09:55
Reporter: handrake0724 Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: incorrect description in forces.H
Description: I would like to make sure the Note on coordinate system in forces.H which reads:

\verbatim
    coordinateSystem
    {
        origin (0 0 0);
        e3 (0 0 1);
        e1 (1 0 0);
    }
\endverbatim

I tried to use local coordinate to measure wind load following wind direction.
At first, forces functionObject dictionary went like this

forces
{
  type forces;
  functionObjectLibs 1 ( ”libforces.so” );
  writeControl timeStep;
  writeInterval 1;
  patches ("hull");
  rhoName rhoInf;
  rho rhoInf;
  log true;
  rhoInf 1.21;
  coordianateSystem
  {
    origin (0 0 0);
    e3 (0 0 1);
    e1 (1 0 0);
  }
}

But the above did not work saying failed to find origin.
The next thing I found to make it work is that

forces
{
  type forces;
  functionObjectLibs 1 ( ”libforces.so” );
  writeControl timeStep;
  writeInterval 1;
  patches ("hull");
  rhoName rhoInf;
  rho rhoInf;
  log true;
  rhoInf 1.21;
  origin (0 0 0);
  coordinateRotation
  {
       type axesRotation;
       e3 (0 0 1);
       e1 (1 0 0);
  }
}

So, I am wondering if the description on the header file is incorrect.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011189)
henry   
2020-02-17 09:55   
Resolved by commit fe13ba9face16b9de1dc77a45aacf3b93d8548ab


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3451 [OpenFOAM] Bug minor always 2020-02-12 15:35 2020-02-14 13:30
Reporter: michael.mueller-wrd Platform: Unix  
Assigned To: henry OS: centOS  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: chtMultiRegionFoam: postProcess functions use global caseDicts function files instead case specific files in local ./system/
Description: For example in the heatedDuct tutorial, to extract vtk surfaces in post-processing step, I copied the global file via "foamGet surfaces" into the system directory.
Then, I adapted the settings of the surfaces (name, basePoint. normalVector etc.) so that there is only one surface included (name z_cL, see below).
I tried to post-process via:
chtMultiRegionFoam -postProcess -latestTime -func surfaces -region metal

But only the global surfaces (located in .../etc/caseDicts/postProcessing/visualization/surfaces) are processed, ie. xNormal, yNormal yNormal, p100, CAD.

When I rename the local system/surfaces file to system/surfacesTMP, and again:
chtMultiRegionFoam -postProcess -latestTime -func surfacesTMP -region metal
... it works as expected, processing only the locally specified surfaces.

I don't understand, why the global surfaces file is used in the former case. At least in the case described here, this behaviour is not intended.
By the way, the same problem occurs for streamlines functionality as well.

PS: the methodology itself works fine for me in case of single region cases (simpleFoam etc.)
Tags:
Steps To Reproduce: Try any chtMultiRegionFoam tutorial, use foamGet to copy surfaces file... see above.
Additional Information: content of system/surfaces tested with heatedDuct tutorial:
#includeEtc "caseDicts/postProcessing/visualization/surfaces.cfg"

fields (T);

surfaces
(
    z_cL
    {
        $cuttingPlane;
        pointAndNormalDict
        {
            basePoint (0 0 0.1); // Overrides default basePoint (0 0 0)
            normalVector (0 0 1); // $z: macro for (0 0 1)
        }
    }

);
System Description
Attached Files:
Notes
(0011170)
henry   
2020-02-12 16:30   
Try with OpenFOAM-dev
(0011174)
michael.mueller-wrd   
2020-02-14 13:00   
Works as expected with OpenFOAM-dev.

Thanks.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3447 [OpenFOAM] Bug minor always 2020-02-08 00:17 2020-02-11 13:54
Reporter: a_malin Platform: LInux  
Assigned To: will OS: Fedora  
Priority: normal OS Version: 31  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Cyclic patches generation malfunctions in certain situations
Description: Cells and faces are misaligned after createPatch in unclear specific situations.

I couldn't trace the problem to specific source, but my guess is that something is wrong with ordering stage of cyclic patch creation.
Tags:
Steps To Reproduce: Case is attached. Polymesh is tetrahedral, converted from gmsh and initially valid (both checkMesh, visual examination and testing case without cyclic boundary conditions). It has two identical patches with 18 degrees rotation around (0,0,1) axis - placed such that rotation is identical to reflection relative to plane x=0. That way it is easy to check .obj with coupled cells, as thet should differ only in sign of y coordinate.
a) Launch 'createPatch -overwrite' using pretty standard createPatchDict with 18 degrees rotation around (0,0,1) axis and pointSync false;
No errors are immediately reported, but now checkMesh reports severely bad mesh. Manual examination of coupled points shows serious displacement of corresponding points. The flow entering one cyclic boundary as a single jet comes from multiple locations through another side.
b) Launch 'createPatch' without other options. Same result.
c) Launch 'createPatch' without specifying exact transformation parameters (rotationAngle etc.). Same result.
d) Launch 'createPatch' with pointSync true; throws an error before writing final coupling
'The distance between the centre of patch cyc_half0 and the transformed centre of patch cyc_half1 is 0.286011.
This is greater than the match tolerance of 3.16228e-06 for the patch.'
Checking initial .obj file shows that transformation is still incorrect.
Additional Information: Surprisingly, in tutorials that use cyclic and cyclicAMI patch types, rotation and translation I was unable to reproduce the problem. Both native specification in blockMesh and through createPatch work well. I've checked mixer from SRFSimpleFoam, pipeCyclic for simpleFoam and planarCouette for pimpleFoam. The differences to my case are: using blockMesh vs external mesher; hence hexahedral structured mesh vs tetrahedral.

In OpenFOAM-7 the same case used to work well; so, it is safe to suppose this problem originates from recent overhaul of coupledPatches and related transformation stuff.
Attached Files: Test_cyclic.tar.xz (1,180,764 bytes) 2020-02-08 00:17
https://bugs.openfoam.org/file_download.php?file_id=2893&type=bug
Notes
(0011151)
openfoam_ran   
2020-02-08 20:44   
Thanks for report the difference between v7 and v6.

People will be careaful use cratePatch in their work.
(0011162)
a_malin   
2020-02-09 15:58   
BTW, probably the problem has common root with that https://bugs.openfoam.org/view.php?id=3445 as they both contain cyclic patches with rotation and unstrustured mesh
(0011168)
will   
2020-02-11 13:54   
Thanks for the report. Fixed by https://github.com/OpenFOAM/OpenFOAM-dev/commit/ba8e1ecd2d9151681e29016f5ac043409e68da4d.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3448 [OpenFOAM] Bug minor have not tried 2020-02-09 03:05 2020-02-09 12:09
Reporter: shadowfax Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: high OS Version: 19.10  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: It is not possible to create a List from a SLList
Description: It is not possible to create a List from a SLList
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011153)
henry   
2020-02-09 12:08   
It is not clear if you obtained the patches you provided from ESI's fork of OpenFOAM so I have removed them and corrected OpenFOAM-dev myself and provided a simple test.
(0011154)
henry   
2020-02-09 12:09   
Resolved by commit 972af235a074371a8bbc3c8599a611f0e00f8c4e


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3443 [OpenFOAM] Bug major always 2020-02-06 16:10 2020-02-07 16:16
Reporter: bakonyi.dani Platform: Unix  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: nutkAtmRoughWallFunction not working properly in OpenFOAM 7
Description: I was trying to create a simple 2D case for an atmospheric boundary layer flow in OpenFOAM7 to check the consistency of the inlet and outlet profiles, but I had zero luck recreating anything I found in the literature (the outflow U, k, eps and nut all were very different). By elimination I finally found that the nutkAtmRoughWallFunction BC behaved strangely. It was totally unresponsive to any change of kappa or z0 inputs. I have read in the OpenFoam 7 release notes that the nutkRoughWallFunction code was updated, which made me suspicious and I quickly checked the case in OpenFOAM 6 as well. The problem went completely away, so it appears to be a bug in OpenFOAM 7 (maybe due to the changes made to nutkRoughWallFunction, but I don't have the skills jet to investigate any further).
Tags:
Steps To Reproduce: Simply run the case in OpenFOAM 6 vs. 7:
https://bitbucket.org/BPPRepo/nutkatmroughwallfunction_test/src/master/
I used ParaView to visualize the profiles (the state is also included).
Additional Information:
System Description
Attached Files:
Notes
(0011135)
henry   
2020-02-06 18:12   
Can you reproduce the problem in the tutorial case: tutorials/incompressible/simpleFoam/turbineSiting

I have run this case in OpenFOAM-6, 7 and dev and get the same results for all three versions.
(0011136)
bakonyi.dani   
2020-02-06 19:50   
That is strange...
I have uploaded a comparison of the vertical profiles (at the outlet, of U, k, eps etc.) I got from both the nutkAtmRoughWall and turbineSiting cases:
https://drive.google.com/drive/folders/12iMIpLipg5w9HaxRk6ciPuBby-QarCWd
They are very different for me.
(0011138)
henry   
2020-02-06 21:43   
Try this:

commit ac27a25923cde9fd468ec09944b7c3a9872e8215
Author: Henry Weller <http://openfoam.org>
Date: Thu Feb 6 21:42:26 2020 +0000

    nutkAtmRoughWallFunction: Updated calcNut -> nut
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3443
(0011149)
bakonyi.dani   
2020-02-07 16:07   
It worked! I am now getting the same results as with OF6.
Thank you!
(0011150)
henry   
2020-02-07 16:16   
Resolved in OpenFOAM-7 by commit ac27a25923cde9fd468ec09944b7c3a9872e8215
Resolved in OpenFOAM-dev by commit 6a2ecb4d0441e9a4906c71a577b626bcb6ff72b6


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3440 [OpenFOAM] Bug major always 2020-02-05 06:57 2020-02-07 11:08
Reporter: dhitomi Platform: GNU/Linux  
Assigned To: OS: RHEL/CentOS  
Priority: normal OS Version: 7.3  
Status: new Product Version: 6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: interFoam/multiphaseInterFoam
Description: There is a memory leak problem. You can recognize this problem for long run or using multiphaseInterFoam, regardless of platform.
Tags:
Steps To Reproduce: Just run those solvers, for example, for 2 days or more. In our cases, the amount of memory used can be a few times greater than that at start.
Additional Information: Perhaps, it seems that the same problem occurs when using interFoam-related solvers.
System Description
Attached Files:
Notes
(0011115)
henry   
2020-02-05 08:48   
Can you reproduce the problem with one of the tutorial cases and with OpenFOAM-7 or OpenFOAM-dev?
(0011116)
dhitomi   
2020-02-05 09:19   
We try it because we have not install OpenFOAM-7 yet.
(0011117)
henry   
2020-02-05 10:51   
I am unable to reproduce the problem, we will need much more detail on how to reproduce it before we can take this further.
See https://bugs.openfoam.org/rules.php
(0011124)
dhitomi   
2020-02-06 00:17   
We can reproduce this problem in some cases. In tutorial, we could not confirm the increase of memory used. (Because it is too small to confirm that, perhaps). We am going to ready to send you the data set(mesh, input data and so on). Please wait.
(0011125)
dhitomi   
2020-02-06 00:49   
In tutorial/multiphase/multiphaseInterFoam/laminar/damBreak4Fine, the amount of memory used is about 83000 KB(RES of top command) per process when start (Time = 0.0*). However, that increased by about 130000KB per process at Time = about 2070.
In the other hand, that is increased from RES 0.0888GB (%MEM 0.1%) to RES 1.6GB (%MEM 1.8). Actually, this calculation was able to stop the machine abnormally.

RES and %MEM stand for those of top command.

We investigate this furthermore.
(0011126)
dhitomi   
2020-02-06 00:50   
"The other hand" in previous note means our calculation case.
(0011128)
henry   
2020-02-06 09:35   
I am running the damBreak4Fine case with an end time of 2000s in OpenFOAM-dev and so far there is no increase in memory usage.

Which OpenFOAM version are you currently running?
Do you see the memory increase only in VoF solvers or all solvers?
Do you see the memory increase only when running in parallel or also serial?
Which MPI version are you using and have you tested any others?
Do you have access to any other machines with more recent GNU/Linux distributions to run tests?
(0011129)
dhitomi   
2020-02-06 09:42   
we could reproduce this problem in tutorial/multiphase/multiphaseInterFoam/laminar/damBreak4phaseFine.

The amount of memory used increased by about 115000KB per process at Time = about 1200 (about 230000 time steps), while it was 83000KB for under 100 time steps.

The reason why we think this is a memory leak is that the amount of memory used comes back to about 83000KB at restart of this calculation from Time = about 1200.

In our actual engineering case, the circumstance is the same. The amount of memory used comes back to that at start when restarting calculation. After all, the calculation could stop the machine abnormally, as mentioned above.

Now, we am going to send the excel file which is described the amount of memory used in tutorial and our engineering cases tomorrow morning.
(0011130)
henry   
2020-02-06 09:59   
I cannot reproduce the problem on tutorial/multiphase/multiphaseInterFoam/laminar/damBreak4phaseFine or any of the other tutorial cases I have tried.
Could you please provide answers to the questions I asked above?
(0011131)
dhitomi   
2020-02-06 10:02   
We used OpenFOAM-7, openmpi 3.1.4, RHEL/CentOS 7.3.

Now we are checking it on Ubunts (Virtual Box on windows10).
(0011132)
dhitomi   
2020-02-06 10:02   
We see that this problem occurs only using VOF solvers.
(0011133)
henry   
2020-02-06 10:35   
Do you see the memory increase only when running in parallel or also serial?
(0011134)
dhitomi   
2020-02-06 10:39   
Now we are checking that. Perhaps, it is parallel only in both ubunts and RHEL/CentOS.
Please wait for 12 hours.
(0011139)
dhitomi   
2020-02-07 06:25   
We are running many jobs to check it now. So please wait by next Wednesday.
(0011144)
henry   
2020-02-07 09:47   
I ran the damBreak4phaseFine case to time 2000s overnight in OpenFOAM-6, 7 and dev with two different versions of OpenMPI and do not see a memory usage increase in any of the runs.
(0011145)
dhitomi   
2020-02-07 10:36   
In our machine, we see the memory increase.
The tutorial case is small so that we are going to run it for about 5 days.
In our engineering case, we can see the memory increase. This case is remarkable.
The amount of the memory used reach a few times greater than that at start.
Could you check our case in your machine?
We can see the increase for 2 or 3 hours in 16 parallel.
Do you have any idea?
(0011146)
henry   
2020-02-07 10:47   
> In our machine, we see the memory increase.

Have you tried another machine? How about testing on AWS?

> The tutorial case is small so that we are going to run it for about 5 days.

At 2000s you reported a doubling in memory usage, I see no increase at all at the same time.

> Could you check our case in your machine?

Given that you see an increase in the tutorial case and I do not it is easier to start by resolving the issue on your machine on this standard case.
(0011147)
dhitomi   
2020-02-07 11:08   
I see.
We try to do that.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3418 [OpenFOAM] Feature minor have not tried 2019-12-28 18:14 2020-01-31 23:51
Reporter: handrake0724 Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: codedFunction1 implementation
Description: recently there were a need to implement wind load relative to the ship speed such that F = 0.5 rho A (Vw - Vs)^2 with Function1 class.
as comment https://bugs.openfoam.org/view.php?id=3381#c10923,
tried to implement codedFunction1 and found there was no way to access to Time.libs() to get dlLibraryTable in current Function1 structure if I am not wrong.

So, I modified Function1 class to make use of objectRegistry db such that constructor and selector have additional parameter as shown below:

    declareRunTimeSelectionTable
    (
        autoPtr,
        Function1,
        dictionary,
        (
            const word& entryName,
            const objectRegistry& obr,
            const dictionary& dict
        ),
        (entryName, obr, dict)
    );

        //- Construct from entry name
        Function1(const word& entryName, const objectRegistry& obr);

    //- Selector
    static autoPtr<Function1<Type>> New
    (
        const word& entryName,
        const objectRegistry& obr,
        const dictionary& dict
    );

But, this modification impacts on TurbulenceModels, dynamicMesh, finiteVolume/fields etc. as well as Function1 and its sub-classes.
Some classes e.g., radial, freePiston, damping is not possible to work with the modified Function1 class because those classes do not have a way to get objectRegistry object.
It looks like codedFunction1 is not possible to implement in the current Function1 structure.

Is there any way to get Time.lib() in the current Function1 implementation?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011006)
henry   
2019-12-28 18:20   
Function1 is designed to be lower-level than objectRegistry and should not directly depend on it.
(0011007)
handrake0724   
2019-12-29 12:54   
Thanks for the comment. I now understand the philosophy of Function1 class.
For the relative wind load external force, I will try to do it with restraint class which is more appropriate for this purpose.
maybe relative wind load external load is not a usual case for wind load analysis, coded version might be useful later.
(0011114)
henry   
2020-01-31 23:51   
Resolved by commit 0dd2e97bd8af78dd063d158bc0c4965f37529cdb


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2979 [OpenFOAM] Bug block always 2018-06-13 08:47 2020-01-28 19:31
Reporter: julien Platform: WSL Ubuntu 18.04  
Assigned To: chris OS: Windows 64 bits  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Unable to install openfoam 5 from "https://openfoam.org/download/5-0-ubuntu/" installation guide
Description: following the instructions give this error :


Get:26 http://archive.ubuntu.com/ubuntu bionic/universe amd64 libopenmpi-dev amd64 2.1.1-8 [925 kB]
Err:3 https://netix.dl.sourceforge.net/project/foam/foam/ubuntu bionic/main amd64 paraviewopenfoam54 amd64 0-2
  Undetermined Error [IP: 87.121.121.2 443]
Fetched 11.6 MB in 2min 4s (93.0 kB/s)
E: Failed to fetch https://netix.dl.sourceforge.net/project/foam/foam/ubuntu/dists/bionic/main/binary-amd64/openfoam5_20180529_amd64.deb Undetermined Error [IP: 87.121.121.2 443]
E: Failed to fetch https://netix.dl.sourceforge.net/project/foam/foam/ubuntu/dists/bionic/main/binary-amd64/paraviewopenfoam54_0-2_amd64.deb Undetermined Error [IP: 87.121.121.2 443]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
Tags:
Steps To Reproduce: Follow the instructions on "https://openfoam.org/download/5-0-ubuntu/"
Additional Information: Looking directly for
 "https://netix.dl.sourceforge.net/project/foam/foam/ubuntu/dists/bionic/main/binary-amd64/paraviewopenfoam54_0-2_amd64.deb"
on the net, I was unable to find the files.
Seems that the right adress is
"https://sourceforge.net/projects/foam/files/foam/ubuntu/dists/..."
System Description
Attached Files:
Notes
(0009746)
wyldckat   
2018-06-13 11:10   
The "netix" server is automatically provided by Sourceforge.net as one of several mirrors. It probably wasn't up-to-date or was down.

If you run "sudo apt update" and try to install again, hopefully it will trigger SF.net to switch to another mirror server.
(0009747)
julien   
2018-06-13 11:35   
After the update, the server "excellmedia" seems to be used, but the problem remain :

julien@DESKTOP-S1HKUNR:~$ sudo apt-get -y install openfoam5
...
0 upgraded, 26 newly installed, 0 to remove and 1 not upgraded.
Need to get 130 MB/142 MB of archives.
After this operation, 904 MB of additional disk space will be used.
Err:1 https://excellmedia.dl.sourceforge.net/project/foam/foam/ubuntu bionic/main amd64 openfoam5 amd64 20180529
  Could not connect to excellmedia.dl.sourceforge.net:443 (202.153.32.19). - connect (111: Connection refused)
Err:2 https://excellmedia.dl.sourceforge.net/project/foam/foam/ubuntu bionic/main amd64 paraviewopenfoam54 amd64 0-2
  Unable to connect to excellmedia.dl.sourceforge.net:https:
E: Failed to fetch https://excellmedia.dl.sourceforge.net/project/foam/foam/ubuntu/dists/bionic/main/binary-amd64/openfoam5_20180529_amd64.deb Could not connect to excellmedia.dl.sourceforge.net:443 (202.153.32.19). - connect (111: Connection refused)
E: Failed to fetch https://excellmedia.dl.sourceforge.net/project/foam/foam/ubuntu/dists/bionic/main/binary-amd64/paraviewopenfoam54_0-2_amd64.deb Unable to connect to excellmedia.dl.sourceforge.net:https:
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
(0009748)
wyldckat   
2018-06-13 12:08   
I've tested this on my Windows 10 machine at work and installed Ubuntu 18.04 from MS Store and had no problems with the download and installation.

It seems that is some weird network access issue in your machine, either due to a security measure or software. You can try to run:

    wget https://excellmedia.dl.sourceforge.net/project/foam/foam/ubuntu/dists/bionic/main/binary-amd64/openfoam5_20180529_amd64.deb

from within the Ubuntu command line, just to confirm if the same error occurs or not.

If it does give the same error, then:

1- Download this and the other file on your Windows machine with your Internet browser.

2- Then you can copy/move the two files in the Ubuntu command line... the path to the Windows "C:" drive is at "/mnt/c".

3- Then run the following commands for installing:

   sudo dpkg -i openfoam5_20180529_amd64.deb
   sudo dpkg -i paraviewopenfoam54_0-2_amd64.deb
   sudo apt-get install -f
   sudo dpkg-reconfigure openfoam5
   sudo dpkg-reconfigure paraviewopenfoam54

4. Follow the instructions from section "User Configuration" at https://openfoam.org/download/5-0-ubuntu/


Please let us know if any of this worked for you.
(0009749)
julien   
2018-06-13 13:00   
Ok, I tried the command line you proposed "wget..." and it worked!
I have now a package in my home/user file which I don't know how to install...
Can you help me with that?

What conclusions do you draw from that? Do you have any advices to try fixing the problem with my computer?
(0009750)
julien   
2018-06-13 13:05   
Sorry, I suppose I have to follow the points 3 and 4 to install.
(0009751)
julien   
2018-06-13 13:36   
Any way, the installation seems to work fine since it display the help manager.
Thank you for this rapid help!
How can I change the status of the thread?
(0009752)
wyldckat   
2018-06-13 13:48   
I'm glad that the manual installation method worked!

It seems like the problem you've gotten can occur sometimes, either due a 3rd party anti-virus or 3rd party firewall software or due to some weird IPv6 issues, from what I can see on the issues on WSL: https://github.com/Microsoft/WSL/issues?utf8=%E2%9C%93&q=is%3Aissue+apt-get+permission+denied - but it's not clear on what happened in your situation.


As for the status of this thread/report - @Chris: I don't know if you want to add this workaround to the page https://openfoam.org/download/windows-10/ - see comment ~0009748 above, or if we'll wait for a couple more similar occurrences to be reported here?
(0009753)
chris   
2018-06-13 15:34   
I tried it myself from an Ubuntu 18.04 instance with "apt-get -y install openfoam5". Initially I got:

Err:2 https://vorboss.dl.sourceforge.net/project/foam/foam/ubuntu bionic/main amd64 openfoam5 amd64 20180529
  Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 5.10.152.194 443]
Get:3 https://vorboss.dl.sourceforge.net/project/foam/foam/ubuntu bionic/main amd64 paraviewopenfoam54 amd64 0-2 [48.8 MB]
Fetched 268 MB in 3min 2s (1474 kB/s)

In other words, from the same server one pack downloaded and one failed.

When I tried again, I got:

Get:1 https://netcologne.dl.sourceforge.net/project/foam/foam/ubuntu bionic/main amd64 openfoam5 amd64 20180529 [81.3 MB]
Fetched 81.3 MB in 2s (35.2 MB/s)

Admittedly the first one was not "Connection: refused", unlike the report.

Lets wait on this. Documentation must be simple to be accessible to the widest audience, and adding information that is rarely needed makes it complex.
(0009778)
chris   
2018-06-16 12:05   
Let's close. If the problem recurs then we can look at this again.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3357 [OpenFOAM] Bug minor always 2019-10-01 14:27 2020-01-27 07:48
Reporter: Emeline Noel Platform: GNU/Linux  
Assigned To: will OS: Cent  
Priority: normal OS Version: 7  
Status: resolved Product Version: 6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: transformPoint for ACMI not done for TRANSLATIONAL transform
Description: Dear All,

Trying ACMI for periodic BC for a box with X+/X- patch wich are not exactly similar because of complex STL geometry that snappyHexMesh don't exactly respect (even with tunning tolerance for snap or feature ...), the translation between patch is not seen and owner and neighbourg patch are not seen to be partially covered but 100% uncovered!
Looking at the code of cyclicAMIPolyPatch.C with the transformPoint function, we see that when it is call from ACMI resetAMI, the separed() and separation() is zero even. These are varaible use in transformPoint so no transforation is apply. We can verify this with the debugSwith that help to have the XX-neighbour-trans.obj and xx-neighbour-org.obj. The two surface patch are at the same place, no transformation translation have been apply and so the X+ stay in X+ and don't overlap the X-, uncovered is 100%.
Rough change I made to make the case work :
In transformPoint test transform() == TRANSLATIONNAL instead of separated(), and use separationVector instead of separation(). The coverage is no more 0%, the patch obj trans and org are not at the same place. Transformation have been apply.

I know that the changes are not done in a good manner and that the value of separated and separation() should be good before being use in transformPoint. I would work on this later on. However, I think that it is perhaps easier for some OpenFOAM developper to see the issue explain here, and the way to do the correction in the conformal way.

Have a nice day,

Emeline

Tags:
Steps To Reproduce: After untar
./AllRun
Check .obj
Additional Information:
System Description
Attached Files: Case.tar (195,784 bytes) 2019-10-01 14:27
https://bugs.openfoam.org/file_download.php?file_id=2785&type=bug
Notes
(0011098)
will   
2020-01-23 13:23   
Fixed in dev by https://github.com/OpenFOAM/OpenFOAM-dev/commit/87bce82854ba42bf67e19fa34216b8af1db38851. Also, your separation vectors are the wrong way around. The convention is that the vector for a given patch is the one that points to that patch from the opposite side.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3437 [OpenFOAM] Patch text always 2020-01-26 13:25 2020-01-26 13:41
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Patch to couple of small typos
Description: I have attached a patch for a couple of misc typos in comments.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: typos.diff (1,473 bytes) 2020-01-26 13:25
https://bugs.openfoam.org/file_download.php?file_id=2888&type=bug
Notes
(0011111)
henry   
2020-01-26 13:41   
Resolved by commit f4e47fccbcd7dc8064d4adfcee3254beffd66145


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3436 [OpenFOAM] Bug major always 2020-01-24 14:17 2020-01-24 23:02
Reporter: shadowfax Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 19.10  
Status: new Product Version: dev  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: buoyantPimpleFoam: hotRoom tutorial crash
Description: Hello,

Running hotRoom tutorial with buoyantPimpleFoam solver results in Foam::error::printStack(Foam::Ostream&) error.
The problem seems to be related to setField utility as the temperature field is modified incorrectly.

The bousinesq version of this tutorial runs but the result is wrong due the incorrect setField modification.
This has been tested on clean compile OpenFOAM-dev:

commit f550db1a5f9a6bd348207d29679eed23bf80c785 (HEAD -> master, origin/master, origin/HEAD)
Author: Will Bainbridge <http://cfd.direct>
Date: Tue Jan 21 15:44:57 2020 +0000

    Scotch: Upgrade to 6.0.9
    
    This is to resolve a bug in the ptscotch rebalancing of the LES
    motorBike mesh when running with the new coupled patch ordering
Tags:
Steps To Reproduce: 1- Navigate to the hotRoom tutorial case directory.
2- Run the case using the provided Allrun script.
Additional Information:
System Description
Attached Files: log.buoyantPimpleFoam (2,582 bytes) 2020-01-24 14:17
https://bugs.openfoam.org/file_download.php?file_id=2884&type=bug
log.setFields (1,306 bytes) 2020-01-24 14:17
https://bugs.openfoam.org/file_download.php?file_id=2885&type=bug
T (2,678 bytes) 2020-01-24 14:17
https://bugs.openfoam.org/file_download.php?file_id=2886&type=bug
log.make (13,000 bytes) 2020-01-24 18:10
https://bugs.openfoam.org/file_download.php?file_id=2887&type=bug
Notes
(0011106)
henry   
2020-01-24 17:35   
We are unable to reproduce this problem on either of the OSs we use: OpenSuSE or Ubuntu with any version of gcc we support or Clang. Maybe you have old versions of your own or other libraries which ldd is loading.
(0011107)
shadowfax   
2020-01-24 18:10   
Well I'm currently using Ubuntu 19.10 with gcc-9, can you confirm whether this configuration is supported or not?
The same issue happens with OpenFOAM.com version compiled with gcc-8.

Both versions are clean compiled to avoid any conflict.
Would you please provide the gcc version that you are currently using on your system?

Also I have attached the build log.
(0011108)
henry   
2020-01-24 19:26   
> Well I'm currently using Ubuntu 19.10 with gcc-9, can you confirm whether this configuration is supported or not?

Yes

> Would you please provide the gcc version that you are currently using on your system?

Generally I am using the system compiler on OpenSuSE Tumbleweed which is currently gcc-9.1.1 but also test with

gcc-4.8.5 gcc-4.9.4 gcc-5.5.0 gcc-6.1.0 gcc-6.5.0 gcc-7.2.0 gcc-7.3.0 gcc-7.4.0 gcc-8.1.0 gcc-8.2.0

which I compile from sources.

I also test clang-7.0.1 and icpc-19.0.4
(0011109)
shadowfax   
2020-01-24 21:23   
In order to clean compile with gcc-7, I completely removed my OpenFOAM-dev local repository.
Unfortunately, the problem is still there after recompiling the source.

Further investigating the issue, I can say that there is no problem with buoyantPimpleFoam solver. In fact, setField utility writes wrong values instead of the provided value defined by setFieldDict. In this case, It writes 1.4822e-323 instead of 600 for the temperature field and this cause floating point exception. Manually replacing all the occurrence of 1.4822e-323 with 600 and the solver runs just fine.

Also tried running the damBreak case with interFoam and while the case runs normally, for some reasons my text editor can not open the 0/alpha file after setField modification. It just crash...

I have tried both cases with OpenFOAM-2.4.0 and foam-extend-4.1 and there is no problem.
(0011110)
shadowfax   
2020-01-24 23:02   
sorry for the typo in my last note, I meant recompiling with gcc-8.
Now I have tried with gcc-7 and the problem is fixed.

The problem occurs when compiling with gcc-8 or gcc-9.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3435 [OpenFOAM] Bug minor always 2020-01-24 08:53 2020-01-24 14:41
Reporter: user136 Platform: HPC-Cluster  
Assigned To: henry OS: CentOS  
Priority: normal OS Version: unknown  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: refineWallLayer: Option "-useSet" works not correctly
Description: Hi all,

when using refineWallLayer, the option "-useSet" should restrict the refinement to a certain cellSet.
But, instead it does the opposite: Cells in the cellSet are not refined, but all the others.

I see this on OF4.1, but since refineWallLayer didn't change much it should be same on OF7.

The reason is obvious in the source code: the cellSet cells are erased from the set of cells "cutCells"which are to be cut:

        cellSet cells(mesh, setName);

        forAllConstIter(cellSet, cells, iter)
        {
            cutCells.erase(iter.key());
        }

Best regards,

Carsten
Tags:
Steps To Reproduce: - Unpack zipfile
- Run:

blockMesh
setSet -batch setSet.batch
refineWallLayer -useSet c0 '(zmin)' 0.3

Look at the wall layers: They should be in cells with (0 < x < 0.5), (0 < y < 0.5), (z=0), bit instead they aree outside.
Additional Information:
System Description
Attached Files: refineWallLayerTest.zip (8,502 bytes) 2020-01-24 08:53
https://bugs.openfoam.org/file_download.php?file_id=2883&type=bug
Notes
(0011101)
henry   
2020-01-24 09:59   
On further review of the code I agree with your assessment, the documentation is ambiguous, the Info statement is confusing and the operation the opposite of that expected. I will correct the code.
(0011102)
henry   
2020-01-24 10:42   
Try

commit d7a452ccf2948827f4164919f19fb152bd0e0f6c (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://openfoam.org>
Date: Fri Jan 24 10:39:58 2020 +0000

    refineWallLayer: Changed name of the -useSet option to -inSet, corrected operation and documentation
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3435
(0011104)
user136   
2020-01-24 12:08   
Works as expected now.

Best regards,

Carsten
(0011105)
henry   
2020-01-24 14:41   
Resolved by commit d7a452ccf2948827f4164919f19fb152bd0e0f6c


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3434 [ThirdParty] Bug minor always 2020-01-23 10:54 2020-01-24 12:00
Reporter: fantaz Platform: linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 19.10  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Foam::sampledSurfaces::plane ctor compiler error
Description: When declaring the Foam::sampledSurfaces::plane instance with ctor with five arguments (take a look at the Steps to Reproduce), the compiler spits out an error:
...
error: no matching function for call to ‘Foam::sampledSurfaces::plane::plane(const Foam::word&, const Foam::fvMesh&, const Foam::plane&)
...
<dir_to_OF>/OpenFOAM-7/src/sampling/lnInclude/sampledPlane.H:100:26: note: no known conversion for argument 3 from ‘const Foam::plane’ to ‘const Foam::sampledSurfaces::plane&’
  100 | const plane& planeDesc,
      | ~~~~~~~~~~~~~^~~~~~~~~
<dir_to_OF>/OpenFOAM-7/src/sampling/lnInclude/sampledPlane.H:56:7: note: candidate: ‘Foam::sampledSurfaces::plane::plane(const Foam::sampledSurfaces::plane&)’
   56 | class plane
      | ^~~~~

Maybe I'm using the sampledSurfaces::plane wrong, bit it seems to me that the const plane& planeDesc argument in the Foam::sampledSurfaces::plane ctor should be of type Foam::plane, since the sampledSurfaces::plane ctor with three arguments, uses cuttingPlane constructor as shown below (copied from sampledPlane.C, lines 66-74), i.e.
Foam::sampledSurfaces::plane::plane
(
    const word& name,
    const polyMesh& mesh,
    const dictionary& dict
)
:
    sampledSurface(name, mesh, dict),
    cuttingPlane(Foam::plane(dict)),
...

I'm by no means an advanced user, but it seems to me that the argument
const plane& planeDesc
should be
const Foam::plane& planeDesc
Tags:
Steps To Reproduce: // Wherever in code, providing that the -I$(LIB_SRC)/sampling/lnInclude and -lsampling are added to EXE_INC to LIB_LIBS in options file, respectively.

...
#include "plane.H"
#include "sampledPlane.H"
...
void fun()
{
const point xyz(-1.5, 0, 0);
const vector dir(0, 1, 0);
const Foam::plane p(xyz, dir);
const word pname = "left";

// the last two arguments, zoneKey and triangulate are word::null and true, respectively
Foam::sampledSurfaces::plane sp(pname, mesh_, p);
}
Additional Information:
System Description
Attached Files:
Notes
(0011097)
henry   
2020-01-23 11:48   
User support request.
(0011103)
will   
2020-01-24 12:00   
On further consideration we have concluded that the constructor in question is in fact in error. It does not function as intended since the rename of the class has caused a clash with the Foam::plane class.

This issue has not surfaced previously because the constructor in question is not used anywhere. I have therefore removed it, and I consider that change to have resolved this report. See https://github.com/OpenFOAM/OpenFOAM-dev/commit/8e6d792ff5b6ece4b48a223bda526999a059ebca.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3414 [OpenFOAM] Bug minor always 2019-12-18 14:57 2020-01-21 08:54
Reporter: hk318i Platform: Ubuntu 18.04LTS  
Assigned To: henry OS: Other  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: #includeFunc doesn't work in parallel with codeStream
Description: Hello,

When running case in parallel with a ``functionObject`` where the function is included in ``controlDict`` using ``#includeFunc``, it doesn't work if the function includes ``codeStream``. It just stuck without error as

```
Using #codeStream at line 20 in file "..../pitzDaily/system/streamlines.seedSampleSet"
Using #codeStream with ".../pitzDaily/dynamicCode/platforms/linux64GccDPInt32Opt/lib/libcodeStream_da0a034ea863be5417dd3a56093413c219c90f7b.so"
```
I think something happens during loading which is limited to OF-7 and OF-dev only. I tested using OF-5 and OF6 which have no issue at all to run the case.

Tags:
Steps To Reproduce: Simply copy ''simpleFoam/pitzDaily'' and modify ``streamlines`` function to include any codeStream; for example the start point as

```
    start #codeStream
    {

      code
      #{

        os << "(-0.0205 0.001 0.00001)" << endl;
      #};
    };
```

It is a trivial example but sufficient to reproduce the issue.
Additional Information:
System Description
Attached Files:
Notes
(0010992)
henry   
2019-12-19 16:52   
Thanks for the detailed report

Resolved in OpenFOAM-7 by commit 37fa4bc3407472cc4faede31236cd3916f033a6a
Resolved OpenFOAM-dev by commit 2ef926732363fbc676098f16dd847bc832c5dd96


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3430 [OpenFOAM] Bug minor always 2020-01-15 11:41 2020-01-17 18:07
Reporter: HTauber Platform: Unix  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: snappyHexMesh doesn't work in parallel
Description: During the last updates I noticed that snappyHexMesh generates errors in parallel running.
Tags:
Steps To Reproduce: see shellAndTubeHeatExchanger from tutorials/heatTransfer/chtMultiRegionFoam
Additional Information:
Attached Files: log.snappyHexMesh (44,536 bytes) 2020-01-15 11:41
https://bugs.openfoam.org/file_download.php?file_id=2879&type=bug
Notes
(0011068)
henry   
2020-01-15 12:08   
commit 2771c1f85c267e9925c2796b52b3ae010fae6179
Author: Henry Weller <http://openfoam.org>
Date: Mon Jan 13 19:55:18 2020 +0000

    coupledPolyPatch: Added initialisation of ordering_ data member
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3428
(0011078)
henry   
2020-01-17 18:07   
Resolved by commit 2771c1f85c267e9925c2796b52b3ae010fae6179


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3426 [OpenFOAM] Bug minor always 2020-01-10 12:04 2020-01-17 18:05
Reporter: JeroenJanssen Platform: AWS  
Assigned To: henry OS: Linux Ubuntu  
Priority: normal OS Version: 18  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: no triangulated vtk files with cuttingPlane post processing
Description: After upgrading from OF6 to OF7, it seems that the 'triangulate' flag doesn't work anymore for the cuttingPlane postprocessor. The vtk files in the results all have meshes with faces with >=4 vertices, while the triangulate flag is set to true. All else works well (I do get triangulated vtk files for the 'patchInternalField', just not for the 'cuttingPlane').

Any help would be greatly appreciated.

Many thanks,
Jeroen
Tags:
Steps To Reproduce: After finishing the simpleFoam simulations I run the command:
mpirun -np 36 simpleFoam -parallel -postProcess -funcs "(surfaces)" -latestTime > log

An extract of the surfaces dictionary file:

...
surfaces
(
extractSurface_Ground_U13
    {
        type patchInternalField;
        patches (Ground Ground_Explicit Ground_Water);
        offsetMode uniform;
        offset (0 0 1.5);
        interpolate true;
        triangulate true;
    }

cuttingPlane14_X_000
    {
        type cuttingPlane;
        planeType pointAndNormal;
        pointAndNormalDict
        {
        basePoint (-798.600203421432 52.1308814897659 0);
        normalVector (0 1 -1.192093E-07);
        }
        interpolate true;
        triangulate true;
    }
)
...
Additional Information:
System Description
Attached Files: motorBike.zip (16,942 bytes) 2020-01-13 12:28
https://bugs.openfoam.org/file_download.php?file_id=2874&type=bug
U_yNormal.vtk (989,026 bytes) 2020-01-13 12:28
https://bugs.openfoam.org/file_download.php?file_id=2875&type=bug
log.snappyHexMesh (12,032 bytes) 2020-01-14 15:44
https://bugs.openfoam.org/file_download.php?file_id=2877&type=bug
log.snappyHexMesh.gz (15,935 bytes) 2020-01-14 16:35
https://bugs.openfoam.org/file_download.php?file_id=2878&type=bug
cuttingPlane_windAroundBuildings.PNG (342,414 bytes) 2020-01-17 13:00
https://bugs.openfoam.org/file_download.php?file_id=2880&type=bug
cuttingPlane_windAroundBuildings02.PNG (599,940 bytes) 2020-01-17 13:00
https://bugs.openfoam.org/file_download.php?file_id=2881&type=bug
log-2.snappyHexMesh (12,035 bytes) 2020-01-17 13:00
https://bugs.openfoam.org/file_download.php?file_id=2882&type=bug
Notes
(0011051)
henry   
2020-01-10 16:36   
We don't have access to the case you are running, can you reproduce the issue on one of the tutorial cases?
(0011053)
JeroenJanssen   
2020-01-13 12:28   
Hi Henry,

Thank you for your quick response.
No problem, please find attached the motorBike example (I only modified the 'cuttingPlane' dictionary, where I included the triangulate true - flag as I was used to in OF6 and before, and then the decomposeDict as I ran it on 36 cores). I've also included the resulting postProcessing file for U for timestep 500. As you can see there are a few tri's in there, but most of the faces have 4 or more vertices.
Hope that helps.

Thanks,
Jeroen
(0011054)
henry   
2020-01-13 14:36   
If you set
            triangulate rubbish;

you will find that there as no error message; there is no triangulate option in the latest cuttingPlane. However you can control the surface filtering which by default simplifies the triangulation into quads where possible but if you switch it off:

            filtering none;

then the original triangulated surface is written.
(0011055)
henry   
2020-01-13 14:41   
Alternatively you can use the original cutting plane implementation by selecting

            type plane;
            .
            .
            .
            triangulate false;

but this has all the limitations and quirks of that version and I would recommend that you use the new one.
(0011058)
JeroenJanssen   
2020-01-14 11:16   
Thanks Henry,
I've tried the filtering none option you suggested, but where should I place that line? I put it within the cuttingPlane dict, both in the main body as well as within the individual plane, but there is no difference in the resulting vtk file. Still faces with 4 or more vertices. I've also tried to change the flag to rubbish and don't get any errors.

Am I putting it in the correct place, or not?

Thank you for your help
(0011059)
henry   
2020-01-14 11:30   
With cuttingPlane in OpenFOAM-dev use

    filtering none;

instead and in place of

     triangulate true;
(0011063)
JeroenJanssen   
2020-01-14 15:44   
Thanks. I was using the OF7 distribution.
I just installed the dev and tried and it does create a triangulated vtk, however, running the motorBike example straight out the box causes snappyHexMesh to crash...
I've attached the log file for snappyHexMesh.
(0011066)
henry   
2020-01-14 16:35   
I've attached the log file for snappyHexMesh that I get with OpenFOAM-dev
(0011072)
JeroenJanssen   
2020-01-17 13:00   
Hi Henry,

Thanks. I've tried it again just now. Unfortunately it still crashes at the same point...
I've gone through these steps this morning:

- launch a fresh AWS instance with Linux Ubuntu Server 18.04 LTS (ami-0be057a22c63962cb)
- install OpenFOAM-dev (downloaded this morning) through the command line according the instructions (https://openfoam.org/download/dev-ubuntu/)
- copy the motorBike tutorial to the run folder
- run ./Allrun

snappyHexMesh crashes at the same location with an IOStream error:
[5] --> FOAM FATAL IO ERROR:
[5] incorrect first token, expected '(', found on line 0 the punctuation token '['
[5]
[5] file: IOstream at line 0.
[5]
[5] From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::List<T>&) [with T = Foam::Vector<double>]
[5] in file /home/ubuntu/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/ListIO.C at line 131.
[5]
FOAM parallel run exiting

I've gone through all the case files and compared the OF7 and OF-dev versions, they are both identical. The only small difference I can see between your and my log file is the OF Build (dev-7fdfe4224aad for mine and dev-2771c1f85c26 for yours) and I noticed that your log file has an additional line printed in line 33:
SetNaN : Initialising allocated memory to NaN (FOAM_SETNAN).

I've also run another tutorial windAroundBuildings. It succeeds on a single core, but crashes too in parallel with the same error. (Let me know if you'd prefer for me to raise a separate issue, as it seems this is probably not related to my original question anymore).

In addition, I put a cuttingPlane in this case and can confirm that it produces triangulated vtk files (see the images attached). The meshes are not very pretty, as it introduces triangles with a very high aspect ratio between each cell. I use these triangulated .vtk files to visualise results back in Rhino (3d CAD package), which only allows for tri or quad meshes. As these vtk files are quite large usually, I expect these additional triangles will make these meshes quite heavy, it would be great to have this original triangulate flag back in the dictionaries.

I hope that helps getting to the bottom of this...

Thanks,
Jeroen


PS: Also... The interface of this site is not that great. I had to type this twice as it timed out while I was typing and finding some stuff out (the suggested back button is bringing you back to the main page and therefore all the typed input and files disappear ...)
(0011073)
henry   
2020-01-17 13:49   
You will need

commit 2771c1f85c267e9925c2796b52b3ae010fae6179
Author: Henry Weller <http://openfoam.org>
Date: Mon Jan 13 19:55:18 2020 +0000

    coupledPolyPatch: Added initialisation of ordering_ data member
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3428

which is more recent than commit-7fdfe4224aad.

Try compiling the latest OpenFOAM-dev sources.
(0011074)
henry   
2020-01-17 13:51   
> PS: Also... The interface of this site is not that great. I had to type this twice as it timed out while I was typing and finding some stuff out (the suggested back button is bringing you back to the main page and therefore all the typed input and files disappear ...)

Agreed, I have also had this problem in the past. Have you reported it to the maintainers of the Mantis software?
(0011076)
JeroenJanssen   
2020-01-17 17:48   
yes that worked!
It's fully running and exporting the triangulated .vtk files.
Thanks!

ok, no, I didn't report it yet, but I will push my comment through to Mantis.
(0011077)
henry   
2020-01-17 18:05   
Resolved by commit 2771c1f85c267e9925c2796b52b3ae010fae6179


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3431 [OpenFOAM] Bug crash always 2020-01-17 11:01 2020-01-17 15:05
Reporter: jtriesch Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: gmshToFoam crashes due to parsing of variable identifier $
Description: gmshToFoam crashes due to incorrect parsing of Gmsh input files *.msh, with Gmsh file export version 2.2. Error message "wrong token type - expected word, found on line 0 the variable $MeshFormat" indicates a parsing issue. I suspect this is related to commit 3192d64875227d8765a8fe076e94b7a4e9cccdf4 which introduced a new variable type.

Can be fixed by substituting 'variable' for 'word' as type in lines 267, 322, 395, 698, and 814 of gmshToFoam.C.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011075)
henry   
2020-01-17 15:05   
Thanks for the report and proposed update.

Resolved by commit 30970970030fe6100cb75d7bff9c5e6eb9b54645


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3428 [OpenFOAM] Bug crash always 2020-01-13 18:17 2020-01-13 19:56
Reporter: fede Platform: Linux  
Assigned To: henry OS: Debian  
Priority: normal OS Version: 9  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: missing orderType definition in constructor - coupledPolyPatch.C
Description: In coupledPolyPatch.C, definition of the protected variable ordering_ is missing in some constructors. This causes crashes in the code anytime utilities (decomposePar for example) operate on a mesh where cyclicAMI constraints are present.

Please find attached the corrected version of coupledPolyPatch.C, that fixes the issue.

Wish this helps.
Tags:
Steps To Reproduce: Please run the Allrun script in the tutorial case:


           $FOAM_TUTORIALS/incompressible/simpleFoam/pipeCyclic
Additional Information:
System Description
Attached Files: coupledPolyPatch.C (9,349 bytes) 2020-01-13 18:17
https://bugs.openfoam.org/file_download.php?file_id=2876&type=bug
Notes
(0011056)
henry   
2020-01-13 18:38   
I just ran the $FOAM_TUTORIALS/incompressible/simpleFoam/pipeCyclic and it runs fine so I am not able to reproduce the problem. Nevertheless I will check the patch you have provided.
(0011057)
henry   
2020-01-13 19:56   
Resolved by commit 2771c1f85c267e9925c2796b52b3ae010fae6179


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3411 [OpenFOAM] Contribution feature N/A 2019-12-12 23:01 2020-01-13 09:58
Reporter: blttkgl Platform: Unix  
Assigned To: OS: Other  
Priority: low OS Version: (please specify)  
Status: new Product Version: dev  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MIxture fraction functionObject
Description: Mixture fraction (Z) is a normalized quantity for measuring the fuel/oxidizer ratio in a mixture, where Z=0 corresponds to pure oxidizer, and Z=1 corresponds to pure fuel. It is widely used by the researchers in combustion field.

I attach a patch which includes a functionObject to create the mixture fraction Z field for multi-species solvers, for example reactingFoam, based on Armin Wehrfritz's original implementation. To be able to define what "oxidizer" and "fuel" are, user should define their chemical composition in a mixtureFractionProperties dictionary. That's why, I have also modified the counterFlowFlame2D_GRI tutorial to use this new mixtureFraction functionObject.

The implementation is templated on the XiReactionRate functionObject, so I would say it follows OpenFOAM coding guidelines pretty well. Please let me know if you want something changed.

Best,

Bulut
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: mixtureFraction.patch (18,563 bytes) 2019-12-12 23:01
https://bugs.openfoam.org/file_download.php?file_id=2853&type=bug
Notes
(0011052)
blttkgl   
2020-01-13 09:58   
I don't know if you had the chance to look at this but a small update.

I realized after testing that the implementation I made, which calculates the mixture fraction inside the write() function fails for instance if the user wants to get cutplanes more often than field writing frequency. With this in mind I think the calculation of the mixture fraction should be in execute() function, while write() function should only have the command to write the field. In this case the user can decide how often should mixture fraction is calculated (executeControl) and how often it is written as a field (writeControl).

I can push an update on this if you are interested.

Best,

Bulut


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3422 [OpenFOAM] Bug minor always 2020-01-07 19:03 2020-01-09 10:29
Reporter: jfp6 Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: foamJob not reading macro for numberOfSubdomains in decomposePar
Description: Between version dev-263a22a67bf4 and dev-7cd43ea5f827 the functionality of how foamJob writes the number of cores for mpirun from a macro has changed. Using dev-263a22a67bf4 I could use a macro to specify the numberOfSubdomains and when running foamJob it would write "...Executing: /usr/bin/mpirun -np 4 ...". With dev-7cd43ea5f827 it populates with "...Executing: /usr/bin/mpirun -np $test ..." instead of the number. The macro is read correctly from decomposePar when running decomposePar for both versions. When using "foamJob decomposePar", the macro also works for both versions. This problem only exists for foamJob when populating the number of cores for mpirun.
Tags:
Steps To Reproduce: For the damBreak case (or any case that is ready to be decomposed) add the file test with the contents test 4;

echo "test 4;" > system/test

Next modify the system/decomposePar file to have the following two lines at the beginning:

#include "./system/test"
numberOfSubdomains $test;

Run the case manually:

blockMesh
setFields
decomposePar
foamJob -p interFoam

"...Executing: /usr/bin/mpirun -np $test ..." will fail to run because the number of cores is not specified.
Additional Information:
System Description
Attached Files:
Notes
(0011045)
henry   
2020-01-07 19:44   
foamJob has not changed but the default expansion behavior of foamDictionary (which foamJob uses to get the numberOfSubdomains) has. I will push a fix for this change in default behavior shortly.
(0011046)
jfp6   
2020-01-07 20:35   
Thanks for the clarification and your help with the fix.
(0011047)
henry   
2020-01-07 21:26   
This should be resolved by commit d8209247b13a7bf0a7074cff71060735cefd2498


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3301 [OpenFOAM] Bug trivial always 2019-07-02 08:29 2020-01-07 11:28
Reporter: paulmedwards Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Issue compiling in a path containing a symlink
Description: The `/etc/bashrc` will take the physical path for `FOAM_INST_DIR` here: https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/etc/bashrc#L46. This is then used for other environment variables, e.g. WM_PROJECT_INST_DIR and WM_PROJECT_DIR.

In the wmake command it compares the current working directory with `WM_PROJECT_DIR` here: https://github.com/edwardsp/OpenFOAM-dev/blob/master/wmake/wmake#L398. Since just `$PWD`is used this will not match if there are symlinks in the path.

A possible solution is to change directory to `pwd -P`.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010538)
henry   
2019-07-02 08:58   
It is not clear how to reproduce this problem, we compile OpenFOAM on many systems with different compilers and operating systems and have not had any such problems.
Are you sure your proposed change will work on all systems? How much testing have you performed?
(0010539)
henry   
2019-07-02 09:02   
In wclean we have

    expandPath "$PWD"
    if [ "$exPath" = "$WM_PROJECT_DIR" ]

because apparently `pwd -P` does not resolve all potential problems:

expandPath()
{
    if [ -d "$1" ]
    then
        exPath=$(cd "$1" && pwd -P)
    else
        exPath=$(cd $(dirname "$1") && pwd -P)
    fi
}

we could use this in wmake also.
(0010541)
paulmedwards   
2019-07-02 09:44   
I haven't done extensive testing here. I have created a script to automate building OpenFOAM and the fix I have is to just switch to the physical path before sourcing bashrc and building: `cd $(readlink -f $BUILD_DIR)`. It was a problem for me as my cluster setup had a frontend as the NFS server. The cluster nodes mount in a different place to where the device is mounted and so symlinks are created on the frontend to keep consistent paths.

If WM_INST_DIR is set explicitly to the path with symlinks I would expect it to work (i.e. bashrc#L46 was changed to `export FOAM_INST_DIR=/path/with/symlink`). It is the detection that takes the physical path but wmake just uses the path as it is. TBH I think, if a change were to be made, it would be better to remove the `pwd -P` from the detection in bashrc#L46.

This is how I build and I've added some commands to create a symlink to demonstrate the error:

8<---------------------------------------------------
BUILD_DIR=/scratch
INSTALL_DIR=/apps

# openfoam will get confused if the BUILD_DIR is a symlink
cd $(readlink -f $BUILD_DIR)

#
# this is the part that adds a symlink to show the error
#
mkdir foo
ln -s foo bar
cd bar

mkdir OpenFOAM
cd OpenFOAM
git clone git://github.com/OpenFOAM/OpenFOAM-6.git
git clone git://github.com/OpenFOAM/ThirdParty-6.git

export PATH=/usr/mpi/gcc/openmpi-4.0.2a1/bin:$PATH
source OpenFOAM-6/etc/bashrc

cd OpenFOAM-6
./Allwmake -j 2>&1 | tee build.log
--------------------------------------------------->8



This is the output:

8<---------------------------------------------------
...
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file PstreamGlobals.C
Making dependency list for source file UPstream.C
Making dependency list for source file UIPread.C
Making dependency list for source file UOPwrite.C
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -DOMPI_SKIP_MPICXX -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/hwloc/hwloc201/hwloc/include -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/event/libevent2022/libevent -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/event/libevent2022/libevent/include -I/usr/mpi/gcc/openmpi-4.0.2a1/include -pthread -IlnInclude -I. -I/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/src/OpenFOAM/lnInclude -I/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/src/OSspecific/POSIX/lnInclude -fPIC -c UOPwrite.C -o Make/linux64GccDPInt32OptSYSTEMOPENMPI/UOPwrite.o
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -DOMPI_SKIP_MPICXX -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/hwloc/hwloc201/hwloc/include -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/event/libevent2022/libevent -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/event/libevent2022/libevent/include -I/usr/mpi/gcc/openmpi-4.0.2a1/include -pthread -IlnInclude -I. -I/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/src/OpenFOAM/lnInclude -I/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/src/OSspecific/POSIX/lnInclude -fPIC -c UIPread.C -o Make/linux64GccDPInt32OptSYSTEMOPENMPI/UIPread.o
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -DOMPI_SKIP_MPICXX -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/hwloc/hwloc201/hwloc/include -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/event/libevent2022/libevent -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/event/libevent2022/libevent/include -I/usr/mpi/gcc/openmpi-4.0.2a1/include -pthread -IlnInclude -I. -I/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/src/OpenFOAM/lnInclude -I/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/src/OSspecific/POSIX/lnInclude -fPIC -c UPstream.C -o Make/linux64GccDPInt32OptSYSTEMOPENMPI/UPstream.o
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -DOMPI_SKIP_MPICXX -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/hwloc/hwloc201/hwloc/include -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/event/libevent2022/libevent -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/event/libevent2022/libevent/include -I/usr/mpi/gcc/openmpi-4.0.2a1/include -pthread -IlnInclude -I. -I/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/src/OpenFOAM/lnInclude -I/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/src/OSspecific/POSIX/lnInclude -fPIC -c PstreamGlobals.C -o Make/linux64GccDPInt32OptSYSTEMOPENMPI/PstreamGlobals.o
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -DOMPI_SKIP_MPICXX -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/hwloc/hwloc201/hwloc/include -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/event/libevent2022/libevent -I/usr/mpi/gcc/openmpi-4.0.2a1/include/openmpi/opal/mca/event/libevent2022/libevent/include -I/usr/mpi/gcc/openmpi-4.0.2a1/include -pthread -IlnInclude -I. -I/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/src/OpenFOAM/lnInclude -I/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/src/OSspecific/POSIX/lnInclude -fPIC -shared -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPInt32OptSYSTEMOPENMPI/UOPwrite.o Make/linux64GccDPInt32OptSYSTEMOPENMPI/UIPread.o Make/linux64GccDPInt32OptSYSTEMOPENMPI/UPstream.o Make/linux64GccDPInt32OptSYSTEMOPENMPI/PstreamGlobals.o -L/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/platforms/linux64GccDPInt32OptSYSTEMOPENMPI/lib \
    -pthread -Wl,-rpath -Wl,/usr/mpi/gcc/openmpi-4.0.2a1/lib64 -Wl,--enable-new-dtags -L/usr/mpi/gcc/openmpi-4.0.2a1/lib64 -lmpi -o /mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/platforms/linux64GccDPInt32Opt/lib/openmpi-system/libPstream.so
touch: cannot touch ‘/mnt/resource/scratch/foo/OpenFOAM/OpenFOAM-6/platforms/linux64GccDPInt32OptSYSTEMOPENMPI/src/Pstream/mpi/using:openmpi-system’: No such file or directory
--------------------------------------------------->8
(0010543)
henry   
2019-07-02 09:52   
> I think, if a change were to be made, it would be better to remove the `pwd -P` from the detection in bashrc#L46.

This line has been changed over and over again and there is always some unusual installation configuration for which it causes problem. If we change it we would expect that many users installations would no longer compile and/or run.

Does using

    expandPath "$PWD"
    if [ "$exPath" = "$WM_PROJECT_DIR" ]

in wmake help? At least this change would be consistent with wclean.
(0010545)
paulmedwards   
2019-07-02 10:29   
This works for me:

8<----------------------------------------------------------
diff --git a/wmake/wmake b/wmake/wmake
index 4836880..83abfab 100755
--- a/wmake/wmake
+++ b/wmake/wmake
@@ -395,10 +395,11 @@ fi
 #------------------------------------------------------------------------------
 
 objectsDir=$MakeDir/$WM_OPTIONS
-if [[ "$PWD" = *"$WM_PROJECT_DIR"* ]]
+expandPath "$PWD"
+if [[ "$exPath" = *"$WM_PROJECT_DIR"* ]]
 then
     platformPath=$WM_PROJECT_DIR/platforms/${WM_OPTIONS}
- objectsDir=$platformPath${PWD//$WM_PROJECT_DIR/}
+ objectsDir=$platformPath${exPath//$WM_PROJECT_DIR/}
 fi
 
 (
---------------------------------------------------------->8
(0010547)
henry   
2019-07-02 11:59   
Resolved by commit 9980357df166e81b5d67fe6de33f9fff7869e373
(0010572)
henry   
2019-07-16 10:05   
See https://bugs.openfoam.org/view.php?id=3303


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3419 [OpenFOAM] Bug trivial always 2019-12-29 16:01 2019-12-30 07:45
Reporter: fede Platform: Linux  
Assigned To: henry OS: Debian  
Priority: normal OS Version: 9  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: compilation warning
Description: Hello Henry,
the variable 'receiveFacei' at line 269 in

        $FOAM_SRC/lagrangian/basic/particle/particleTemplates.C

is unused. I think it can be removed.

Happy New Year,
/federico
Tags:
Steps To Reproduce: Just recompile the code from scratch or compile a custom solver using the lagrangian class.

Additional Information:
System Description
Attached Files:
Notes
(0011008)
henry   
2019-12-30 07:45   
Resolved by commit b460b9e93d2c67da2fd534118efeb58236efe640


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3417 [OpenFOAM] Feature minor always 2019-12-23 09:43 2019-12-23 10:46
Reporter: jkau Platform: Linux  
Assigned To: henry OS: CentOS  
Priority: normal OS Version: 8  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: rigidBodyMeshMotionSolver does not account for force ramp
Description: force ramp is only included in rigidBodyMeshMotion, but not in rigidBodyMeshMotionSolver. Attached path fixes this issue
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: ramp.patch (3,321 bytes) 2019-12-23 09:43
https://bugs.openfoam.org/file_download.php?file_id=2861&type=bug
Notes
(0011000)
henry   
2019-12-23 10:46   
I could not apply the patch you provided as it was not compatible with the latest OpenFOAM-dev. However I have transferred the ramp functionality from rigidBodyMeshMotion to rigidBodyMeshMotionSolver.

Resolved by commit 5a2956218038d46253d5897ea945365cc99f124d


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3416 [OpenFOAM] Bug minor always 2019-12-20 16:39 2019-12-21 06:24
Reporter: wwzhao Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: Inconsistent behavior between foamGet and findEtcDirs
Description: In foamGet, line 149, it searches file at "$WM_PROJECT_INST_DIR/site/$WM_PROJECT_VERSION/etc".

While in findEtcDirs function in etcFiles.C, line 87, it searches file at "searchDir/"site/etc"/FOAMversion".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010997)
henry   
2019-12-20 23:01   
I have updated etcFiles.C to be consistent:

commit 33cfa1319873af9eab9df954e835a87e3b6743a3 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://openfoam.org>
Date: Fri Dec 20 23:00:26 2019 +0000

    etcFiles: Corrected handling of "site" to correspond to the documentation
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3416

let me know if this resolves the issue you are having.
(0010998)
wwzhao   
2019-12-21 03:24   
Thank you, henry. It is resolved.
(0010999)
henry   
2019-12-21 06:24   
Resolved in OpenFOAM-7 by commit 33cfa1319873af9eab9df954e835a87e3b6743a3
Resolved in OpenFOAM-dev by commit 000a3bbd8dcff2fb00250ea07310a16e3db8a835


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3413 [OpenFOAM] Bug minor always 2019-12-17 08:35 2019-12-19 14:25
Reporter: SteffenB Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: foamSetupCHT creates wrong regionProperties if no fluid included
Description: When using the template file for creating a chtMultiRegionFoam case regionProperties requires an entry for fluid. If no fluid is included in the case (pure conduction model) the "foamSetupCHT" command creates a regionProperties file containing this:
regions 1 ( solid 2 ( body1 body2 ) );

The required structure for chtMultiRegionFoam in this case would be
 regions 2 ( fluid 0 () solid 2 ( body1 body2 ) );

I guess this just needs to be changed in the script of foamSetupCHT.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: regionProperties_case.zip (76,611 bytes) 2019-12-18 12:58
https://bugs.openfoam.org/file_download.php?file_id=2858&type=bug
Notes
(0010987)
henry   
2019-12-17 14:12   
Could you provide a suitable case and steps to reproduce the problem?
(0010989)
SteffenB   
2019-12-18 12:58   
Ok. I modified the chtMultiRegionFoam tutorial case of the coolingSphere to fit my problem. I renamed the "fluid" region into outerSolid and adjusted the boundary in the templates/solids/T file to fit.
Then i ran "Allmesh" and used "foamSetupCHT" afterwards. This way the problematic regionProperties file is created in constant. And chtMultiRegionFoam stops, when started, because "fluid" is missing in the regionProperties file.
After adjusting this file the way I previously mentioned (I appended the correct regionProperties file in the main folder of the given example), the simulation works flawlessly.
(0010990)
henry   
2019-12-19 14:25   
Resolved by commit a9ddd758e8f16815c7c3252867844af03437f63b


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3409 [OpenFOAM] Bug minor always 2019-12-09 08:39 2019-12-13 08:18
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Regression bug in Ensight part
Description: In commit (https://github.com/OpenFOAM/OpenFOAM-dev/commit/409548cbccac26e5c9632d2543505f659da58945)

"os.writeKeyword" was replaced with "writeKeyword(os, ..)" and I assume this was made with search&replace with the assumption that os is a regular OStream. However, in some Ensight-related files os is "ensightGeoFile" or "ensightFile", which have their own specializations of writeKeyword (=write + add newline + some additional logic). The commit makes them use the regular writeKeyword which produces invalid files due to missing newline.

I have attached a diff-file which simply reverses the changes in the affected files.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch.diff (3,592 bytes) 2019-12-09 08:39
https://bugs.openfoam.org/file_download.php?file_id=2852&type=bug
Notes
(0010975)
henry   
2019-12-10 09:58   
Is the EnSight converter still needed? My understanding is that EnSight is now released with an OpenFOAM reader, can we now drop the reader and converter supplied with OpenFOAM?
(0010977)
tniemi   
2019-12-10 11:12   
Well, I don't know about the EnSight software, but I have found the EnSight format to be better than VTK for sampled surfaces. ParaView can read EnSight and the format allows to store mesh in a separate file, which combined with binary writing can reduce disk space usage by a huge fraction compared to (legacy) VTK-files where each time step must have a copy of the surface mesh.
(0010979)
henry   
2019-12-12 13:09   
resolved by commit 52255e53a7a983995aa2e27b64b8fcc3399d15b6


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3390 [OpenFOAM] Bug major always 2019-11-18 12:57 2019-12-12 11:38
Reporter: MSontheimer Platform: Unix  
Assigned To: will OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Wrong liquid properties coefficients of ethanol (Cp, h)
Description: The calculation of liquid properties "heat capacity Cp" and "enthalpy h" of ethanol (C2H5OH) based on the NSRDSfunc0 function is wrong due to wrong coefficients. This was found by comparing the OpenFOAM calculations with CoolProp 6.3.0 (see attached image) and literature data.

I don't have access to the NSRDS data base, so I cannot check the coefficients reported there. However, one could also find new coefficients based on the CoolProp database (see additional information).
Tags:
Steps To Reproduce: Use the NSRDS functions implemented in $FOAM_SRC/thermophysicalModels/thermophysicalProperties/thermophysicalFunctions/NSRDSfunctions with the coefficients provided in $FOAM_SRC/thermophysicalModels/thermophysicalProperties/liquidProperties/C2H5OH/C2H5OH.C and calculate heat capacity and enthalpy for different temperatures and compare the results with literature data.
Additional Information: One can use CoolProp to find new coefficients for ethanol. A least-squares fit within the temperature range T=[200K, 350K] (up to boiling temperature) for NSRDSfunc0 leads to the following coefficients for the heat capacity of ethanol:

Cp_
(
        3086.27257308567,
       -13.9017298192482,
        0.04495256866223873,
       -1.89534803995077e-05,
        0.0,
        0.0
)

with an average error of 0.024% and maximum error of 0.062%.

The coefficients for enthalpy are found by integration, and the integration constant is calculated from enthalpy of formation and latent heat (consistency for "latentHeat"-mode, see https://bugs.openfoam.org/view.php?id=3085):

h_latent = h_vapor - h_liquid => h_latent(T_std) = h_fv - h_liquid(T_std) => h_liquid(T_std) = h_fv - h_latent(T_std).

The latent heat of vaporization is calculated using the OpenFOAM coefficients (since they agree with the CoolProp data), and the enthalpy of formation of vapor is h_fv = -235.31e6 J/kmol (Çengel & Boles: Thermodynamics: An Engineering Approach. 2006), and T_std=298.15K is the standard-state temperature.

This finally leads to the following coefficients:

h_
(
       -6710293.74515003,
        3086.27257308567,
       -6.95086490962410,
        0.01498418955407958,
       -4.73837009987693e-06,
        0.0
)

Results with old and new coefficients are shown in the attached images. Experimental data for Cp are taken from https://webbook.nist.gov/cgi/cbook.cgi?ID=C64175&Mask=2.
Attached Files: OpenFOAM_CoolProp_Comparison.png (299,110 bytes) 2019-11-18 12:57
https://bugs.openfoam.org/file_download.php?file_id=2832&type=bug
comparison_old_new_coeffs.png (56,168 bytes) 2019-11-18 12:57
https://bugs.openfoam.org/file_download.php?file_id=2833&type=bug
Notes
(0010926)
henry   
2019-11-20 12:45   
If someone here has access to the NSRDS database it would be REALLY useful if all the liquid properties coefficients could be checked and corrected as necessary.
(0010978)
will   
2019-12-12 11:38   
We now have obtained (with some difficulty) a copy of the 1985 Daubert and Danner reference (see NSRDS0ThermophysicalFunction.H). The liquid Cp coefficients were clearly taken from here and there are two mistakes; "b" is a factor of ten too large, and "c" has the wrong sign. The correct set is as follows:

    Cp_
    (
        2052.57331394213,
       -0.121990926653498, // <-- Was -1.21990926653498
       -0.00714146172046278, // <-- Was 0.00714146172046278
        5.20523562482363e-05,
        0.0,
        0.0
    ),

The Cp/H plots are now much closer similar to yours, but there is still a noticeable difference (about 13%). The referred data is old and is probably not as accurate as the new values that you have fitted. However, in this instance, I think we have to implement something for which we can provide a reference. If you want to use your coefficients you can do so via the "liquid" type which lets you choose NSRDS functions and coefficients at run-time.

Resolved in dev by https://github.com/OpenFOAM/OpenFOAM-dev/commit/d37fbcc39c834c2bbc436d0e5dd5e588aede0b5a


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3405 [OpenFOAM] Bug text always 2019-12-04 14:25 2019-12-07 13:56
Reporter: HTauber Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: Typos in User Guide
Description: Some typos in User Guide version 7 from 10th July 2019
Tags:
Steps To Reproduce: file appended
Additional Information:
System Description
Attached Files: OpenFOAMUserGuide-A4_korr.pdf (1,133,814 bytes) 2019-12-04 14:25
https://bugs.openfoam.org/file_download.php?file_id=2851&type=bug
Notes
(0010969)
chris   
2019-12-07 12:21   
Thanks for a very comprehensive set of typo corrections. It was a great job!
The corrections have been incorporated in the Guide and will be pushed to repositories shortly.
Thanks again,
Chris
(0010970)
henry   
2019-12-07 13:56   
Resolved in OpenFOAM-7 by commit e9752a8928897c5c4240a941307308dce5ae1b3c
Resolved in OpenFOAM-dev by commit 5ae7052e12be90559816628850356911adb911f5


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3407 [OpenFOAM] Bug text always 2019-12-05 12:18 2019-12-05 22:41
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Minor typos in surfaceInterpolate function object
Description: There are very minor typos in surfaceInterpolate function object, the description has been likely copied from nearWallField.

In line 52 (https://github.com/OpenFOAM/OpenFOAM-dev/blob/c0cffb357da44ede4a26554caa2563d31d5757be/src/functionObjects/field/surfaceInterpolate/surfaceInterpolate.H#L52) the "type name: nearWallFields" should be "type name: surfaceInterpolate". Also, in line 45 the example refers to pNear and UNear, which could be named eg. pInterp and UInterp or so.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010964)
henry   
2019-12-05 22:41   
Resolved by commit d32e012238b74ce7383c904267087efd132d8f7a


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3397 [OpenFOAM] Bug minor always 2019-11-26 14:21 2019-11-26 16:36
Reporter: handrake0724 Platform:  
Assigned To: will OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Airy wave makes an error when wave length is less than 2
Description: in wave tutorial of tutorial/multiphase/interFoam/liminar/wave,
if Airy wave has the following setup (wave length being less than 2 or wave number being larger than pi), it make an overflow error in exp or sinh functions.
But the Airy wave setup has nothing wrong in linear wave theory point of view.

waves
(
    Airy
    {
        length 2;
        amplitude 0.01;
        phase 0;
        angle 0;
        // depth 10; // for shallow
    }
)

call stack shows the error was originated from waveSuperposition::UGas as shown below

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/usr/lib/libc.so.6"
#3 __sinh_finite in "/usr/lib/libm.so.6"
#4 sinhf32x in "/usr/lib/libm.so.6"
#5 Foam::sinh(Foam::Field<double>&, Foam::UList<double> const&) at ??:?
#6 Foam::sinh(Foam::tmp<Foam::Field<double> > const&) at ??:?
#7 Foam::waveModels::Airy::vi(int, double, Foam::Field<Foam::Vector2D<double> > const&) const at ??:?
#8 Foam::waveModels::Airy::velocity(double, Foam::Field<Foam::Vector2D<double> > const&) const at ??:?
#9 Foam::waveSuperposition::velocity(double, Foam::Field<Foam::Vector<double> > const&) const at ??:?
#10 Foam::waveSuperposition::UGas(double, Foam::Field<Foam::Vector<double> > const&) const at ??:?

or

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/usr/lib/libc.so.6"
#3 ? in "/usr/lib/libm.so.6"
#4 expf64 in "/usr/lib/libm.so.6"
#5 Foam::exp(Foam::Field<double>&, Foam::UList<double> const&) at ??:?
#6 Foam::exp(Foam::UList<double> const&) at ??:?
#7 Foam::waveModels::Airy::vi(int, double, Foam::Field<Foam::Vector2D<double> > const&) const at ??:?
#8 Foam::waveModels::Airy::velocity(double, Foam::Field<Foam::Vector2D<double> > const&) const at ??:?
#9 Foam::waveSuperposition::velocity(double, Foam::Field<Foam::Vector<double> > const&) const at ??:?
#10 Foam::waveSuperposition::UGas(double, Foam::Field<Foam::Vector<double> > const&) const at ??:?


 
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010941)
will   
2019-11-26 16:36   
It's z/(2*pi*l), or z*k that when much greater than 2 triggers the error, not the length/wavenumber itself. That's good, because otherwise we'd have an issue with clipping a dimensioned number.

My suspicion is that if the decay functions (exp/sinh/etc...) are overflowing, then the parameters are unlikely to be realistic. In this example, setting an amplitude of 1cm in a domain 600m tall... However, it is preventable by similar means to some clipping that we already do for depth, so there's not really any disadvantage in your proposal.

Resolved by https://github.com/OpenFOAM/OpenFOAM-dev/commit/d0768e6039ba526d4fde446fd22fd6ff76577417


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3386 [ThirdParty] Bug text always 2019-11-13 01:28 2019-11-26 15:12
Reporter: lichuanlong Platform: Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: the guide for compile openfoam need upgrade .
Description: https://openfoam.org/download/source/software-for-compilation/
In 1st step of compile preview ,there is an setting for qt:
export QT_SELECT=qt4

if qt set to 4, there will be errors when compile preview.

the error like this below.

CMake Error at VTK/CMake/vtkQt.cmake:6 (message):
  Expected value for VTK_QT_VERSION is '5'
Call Stack (most recent call first):
  VTK/GUISupport/Qt/CMakeLists.txt:1 (include)


-- Configuring incomplete, errors occurred!
See also "/home/parallels/myOpenFOAM/ThirdParty-7/build/linux64Gcc/ParaView-5.6.0/CMakeFiles/CMakeOutput.log".
See also "/home/parallels/myOpenFOAM/ThirdParty-7/build/linux64Gcc/ParaView-5.6.0/CMakeFiles/CMakeError.log".
Tags:
Steps To Reproduce: export QT_SELECT=qt4
and run makeParaView
Additional Information: I think it should be set to 5
export QT_SELECT=qt5
or don't use QT_SELECT
System Description
Attached Files:
Notes
(0010920)
chris   
2019-11-18 09:27   
Updated the compilation information.
We are using ParaView 5.6.x now, which is not properly supported by the system libraries of Ubuntu 16.04.
So the instructions use a minimum Ubuntu version of 18.04 now and install QT5, deprecating QT4.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3393 [OpenFOAM] Feature minor always 2019-11-20 13:13 2019-11-21 13:02
Reporter: blttkgl Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: low OS Version: 15.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: ISAT statistics
Description: Hey,

Original reporter from https://bugs.openfoam.org/view.php?id=3392

I re-checked the patch provided by Prof. Contino, and apparently there is a bug where he removed the timeIncr variable added to the cpu times, so the library won't compile without undefined variable.

I provide a patch that should work, attached. I unfortunately do not have the dev installed in my workstation, so maybe you could try it.

Pseudocode is:

Initialize time (line 629)
Add the time it takes to search the tree (line 642)
initialize time once more (line 650)
add the time it takes for mechanism reduction (line 658)
add the time for solving chemistry (line 695)
add the time for add (line 722) or grow (line 727)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: TDACChemistryModel.C (23,405 bytes) 2019-11-20 13:13
https://bugs.openfoam.org/file_download.php?file_id=2836&type=bug
ISAT_statistics_new.png (1,682,601 bytes) 2019-11-21 12:46
https://bugs.openfoam.org/file_download.php?file_id=2837&type=bug
ISAT_statistics_old.png (1,726,831 bytes) 2019-11-21 12:46
https://bugs.openfoam.org/file_download.php?file_id=2838&type=bug
ISAT.patch (2,501 bytes) 2019-11-21 12:46
https://bugs.openfoam.org/file_download.php?file_id=2839&type=bug
printCPUT.py (10,721 bytes) 2019-11-21 12:46
https://bugs.openfoam.org/file_download.php?file_id=2840&type=bug
Notes
(0010928)
henry   
2019-11-20 14:27   
Thanks for the additional report about the patch, I have reverted it pending a version that compiles and tested in OpenFOAM-dev.
(0010929)
blttkgl   
2019-11-21 12:46   
Hey,

I compiled and tested the version I posted earlier on OpenFOAM dev.

Steps to reproduce:

- Run the counterFlowFlame2D_GRI_TDAC tutorial with reduction->off and tEnd=0.25 seconds on 4 processors..
- Use the (quite messy) python script I provide to look at the cpu statistics of the ISAT for old and new way.

You can see in figures (especially bottom middle figure), the cpu_solve is now not included in cpu_add and cpu_grow, which shows more clearly that even utilizing ISAT majority of the time is still spent on solving the ODE, and not binary tree add/grow operation, which is what one might get from the old way.

I also attach a patch that could be applied to the current -dev head.

Best,

Bulut Tekgul
(0010930)
blttkgl   
2019-11-21 12:46   
python code
(0010931)
henry   
2019-11-21 13:02   
Thanks for the correction

Resolved by commit e18c81e84ff3cd5f293001585489d966d7189dd0


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3392 [OpenFOAM] Feature minor always 2019-11-20 08:24 2019-11-20 13:07
Reporter: blttkgl Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: low OS Version: 15.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: ISAT statistics are misleading
Description: In TDACChemistryModel, the cpu time statistics generated for ISAT are a bit misleading.

Algorithm goes so that for each cell:

* If retrieve is successful, time it takes is written to cpu_retrieve
* If retrieve returns false, chemistry is solved and cpu time written to cpu_solve
* Then this solved chemistry is either added to the binary tree, or used to grow an existing binary tree. Time it takes for this operation is written to cpu_add or cpu_grow.

Currently, cpu_add and cpu_grow also includes to time for solving the chemistry cell, so cpu_add = addTime+ solveTime and cpu_grow = growTime + solveTime. When processing the statistics, especially for a parallel job where the user is trying to locate the bottleneck rank for each individual operation, this may be misleading.

Of course one can simply substract cpu_solve from cpu_add and cpu_grow for each time step, but I think cpu_add and cpu_grow should only reflect the time it takes to perform those individual operations.
Tags:
Steps To Reproduce: In OpenFOAM-dev, in OpenFOAM-dev/src/thermophysicalModels/chemistryModel/chemistryModel/TDACChemistryModel/TDACChemistryModel.C , check line 697 to 734

Additional Information:
System Description
Attached Files: TDACChemistryModel.C (23,390 bytes) 2019-11-20 12:27
https://bugs.openfoam.org/file_download.php?file_id=2835&type=bug
Notes
(0010924)
fcontino   
2019-11-20 12:27   
This is an excellent point. The statistics would be easier to understand without accumulation in the different times. I have adjusted the code accordingly. Could you please check if it works as you think is more efficient? (see uploaded file)
(0010925)
blttkgl   
2019-11-20 12:36   
Exactly, timeTmp (solve time) is removed from addNewLeafCpuTime and growCpuTime. We are using the ISAT logs like this and it makes more sense when benchmarking the performance.


Bulut
(0010927)
henry   
2019-11-20 12:51   
Resolved by commit f66ea315840b4e2bfb86f522a9467adef89562a9


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3389 [OpenFOAM] Bug major always 2019-11-15 06:20 2019-11-15 09:03
Reporter: adcpk Platform: Linux  
Assigned To: henry OS: Ubuntu  
Priority: high OS Version: 18.04.3 LTS  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: instantaneous reaction rate is not performed
Description: When the reaction rate is set to instantaneous, the reaction is disappeared.
This bug is due to the mistake in "src/combustionModels/laminar/laminar.C", the instantaneous reaction rate is totally not performed in function "correct".

 
Tags:
Steps To Reproduce: add following set in constant/combustionProperties
integrateReactionRate off;
Additional Information: //openfoam6
template<class ReactionThermo>
 void Foam::combustionModels::laminar<ReactionThermo>::correct()
 {
     if (this->active())
     {
         if (integrateReactionRate_)
         {
             //some codes
         }
         else
         {
             this->chemistryPtr_->calculate();
         }
     }
 }

//openfoam7
template<class ReactionThermo>
 void Foam::combustionModels::laminar<ReactionThermo>::correct()
 {
     if (integrateReactionRate_)
     {
         //some codes
     }
 }

//suggested
template<class ReactionThermo>
 void Foam::combustionModels::laminar<ReactionThermo>::correct()
 {
     if (integrateReactionRate_)
     {
         //some codes
     }
    else
     {
         this->chemistryPtr_->calculate();
     }
 }
System Description
Attached Files:
Notes
(0010911)
henry   
2019-11-15 09:03   
Thanks for the report.

Resolved in OpenFOAM-7 by commit ca808c8420bf6f92640a723e576ab79c830d5ed2
Resolved in OpenFOAM-dev by commit e286cf4ef942c0a6951a92e5022cb98c5ea2ad28


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3361 [OpenFOAM] Bug major always 2019-10-07 11:12 2019-11-14 12:03
Reporter: niklas.wikstrom Platform: x86_64  
Assigned To: henry OS: Fedora  
Priority: normal OS Version: 29  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: snappyHexMesh region refinement contaminates entire geometry facet
Description: A distance refinement region sometimes refines entire triSurface facet. This happens when a refinement region entry specifies a distance that crosses at least one of the facet's edges.

The problem occurs in parallel or serial runs and with OpenFOAM versions 5 to dev (7).

On a geometry that has this problem it is allways reproducable, but manually generating a similar geometry to reproduce the problem is difficult.
Tags:
Steps To Reproduce: Extract attached snappyBugReportRoom.tgz, run blockMesh and snappyHexMesh.
Additional Information: The image file, attached, shows the overly refined facet and visualizes the distance refinement geometry object (pink), pointed at by the yellow line.
System Description
Attached Files: geomFacetRef.png (928,134 bytes) 2019-10-07 11:12
https://bugs.openfoam.org/file_download.php?file_id=2794&type=bug
snappyBugReportRoom.tgz (4,846 bytes) 2019-10-07 11:12
https://bugs.openfoam.org/file_download.php?file_id=2795&type=bug
snappyHexMeshM.C (46,072 bytes) 2019-10-08 09:08
https://bugs.openfoam.org/file_download.php?file_id=2796&type=bug
Notes
(0010802)
niklas.wikstrom   
2019-10-07 11:14   
Forgot to add: This issue is caused by the call to surfaces.setMinLevelFields(shells); in snappyHexMesh.C. Removing the call fixes the issue, but introduces other refinement problems.
(0010803)
wyldckat   
2019-10-07 16:23   
I've had this issue for years and never reported it because I wasn't aware of how much it affects others.

In a custom version we have internally, we have an option for turning off the following lines:
- Starting here: https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/mesh/snappyHexMesh/refinementSurfaces/refinementSurfaces.C#L440
- Ending here: https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/mesh/snappyHexMesh/refinementSurfaces/refinementSurfaces.C#L448

This has been a custom option for us here at our office, but I've never tested this further to see how this affects other geometries.

@niklas.wikstrom: Perhaps by only commenting out the lines I've pointed out, instead of simply commenting 'setMinLevelFields', does it reduce the occurrence of the refinement problems you've seen? Or do the same issue occur?
(0010804)
niklas.wikstrom   
2019-10-08 05:18   
Yes, It's been around, and I mostly have gotten around it through geometry refinements :-D

Thanks a lot! I'll try the modification.

/Niklas
(0010805)
niklas.wikstrom   
2019-10-08 09:08   
It seems to work fine, although I overloaded the setMinLevelFields() in a modified snappyHexMesh.C, thus keeping the src tree intact. (Attaching my local version of snappyHexMesh.C, this is for v5, but minor changes to dev)

Thank you again.

/N
(0010806)
henry   
2019-10-08 14:40   
This change could be put on an optional switch, what do you think would be an appropriate name for it?

A better option would be to change the refinement approach so that it isn't so sensitive to the aspect ratio of the triangles (I am assuming the issue is with long thin triangles), any thoughts?
(0010808)
wyldckat   
2019-10-08 15:38   
@henry: We defined the switch as 'triSurfacesLevelsOnly' in the 'castellatedMeshControls' dict.

I have the very vague idea that the problem occurs when the triangle was large/long enough to overlap multiple refinement regions, resulting in being affected by the other refinement definitions.

From what I can remember, there was no clear fix at the time when I saw and tried to fix this issue, only turning off that particular detection would do the trick.
(0010809)
niklas.wikstrom   
2019-10-08 15:54   
Good with a switch in the dictionary. Note, however, that the facet in my example above does not have a large aspect ratio; just three or so, but the facet gets refined as soon as the distance ref reaches across its edge(s?). The switch name 'triSurfacesLevelsOnly' might need some explanation ;-)

It would be interesting to know when the feature is needed, but I guess I'll figure it out if I run without it for a while.

Thanks for helping!
(0010810)
henry   
2019-10-08 16:06   
@niklas.wikstrom Do you have a better name in mind?

Is this feature needed at all? Shall I simply remove it?
If I add a switch what should the default be? If it is true how will people know that they need to set it to false?
(0010814)
niklas.wikstrom   
2019-10-08 16:57   
Very vague suggestions below, since I do not know what else the thing affects.

Name:
shellLevelToFacets

Default:
false
Will show faster if it's needed or not, set the default to false and wait for bug reports...

Needed?
I do not know, but I assume there was a good reason for it. Better keep it.
(0010816)
henry   
2019-10-08 17:25   
The problem is that if it is needed and was put in for good reason it should be on by default for backward compatibility unless we know for sure that it actually generally not needed and then we need to know for what cases it is needed so that we can inform people of the change in default behavior.
(0010818)
niklas.wikstrom   
2019-10-08 20:37   
I realise that. It is safer. I will run without the thing and if I find some inconsistency or find out what it is all about, I will report back.
/N
(0010888)
henry   
2019-11-12 16:10   
Is there any progress and/or recommendations on this or should I close the report?
(0010895)
niklas.wikstrom   
2019-11-13 14:34   
Hello!
I have not seen any issues with the feature turned off, but have not much statistics. However, I think it is a good idea to add the option "shellLayerToFaces" with default value "true" to snappyHexMesh. And then close the issue.
(0010896)
henry   
2019-11-13 14:39   
How should I document this change? Can any particular recommendations be made? When should users consider changing this switch?
If we don't say anything it will just be a hidden switch that no one knows about or knows how to use so there wouldn't be much point having it.
(0010897)
wyldckat   
2019-11-13 15:17   
If I'm not mistaken, the description can be along these lines:

   This option will allow tessellated surfaces (shells?) to inherit refinement levels from other overlapping features. If you see unwanted refinement spreading onto triangles, turn off this option.


As a side note, I very vaguely remember seeing this happen when larger triangles were overlapping smaller features that I wanted to have refined and yet the large triangle centres would get caught on the overlapping heuristic.
(0010901)
henry   
2019-11-14 12:03   
It is not clear for what cases this refinement condition is useful and given the difficulty in choosing a suitable name for the option, how to control it, what the default should be or when to recommend it should be switched on or off it makes sense to remove it for now and reinstate under an option if cases are found and reported which benefit from this option.

commit a64d71929f0a51229ef6c5603af1d1ca21dad5f1
Author: Henry Weller <http://openfoam.org>
Date: Thu Nov 14 11:51:13 2019 +0000

    snappyHexMesh::refinementSurfaces: Removed problematic shell refinement transfer to surface
    
                // Find out if triangle inside shell with higher level
                // What level does shell want to refine fc to?
                //
                // Note: it is not clear for what cases this additional requirement
                // is beneficial but for triangulated surfaces with triangles that
                // span refinement regions it introduces unnecessary refinement so
                // it has been removed.
                //
                // This option can be reinstated under a switch if cases are
                // provided which demonstrate the benefit.
                /*
                labelList shellLevel;
                shells.findHigherLevel(ctrs, minLevelField, shellLevel);
    
                forAll(minLevelField, i)
                {
                    minLevelField[i] = max(minLevelField[i], shellLevel[i]);
                }
                */


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3384 [OpenFOAM] Bug minor always 2019-11-11 10:26 2019-11-13 09:58
Reporter: HTauber Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: surfaceFieldValue causes error at inlet patches
Description: In the case tutorials/lagrangian/simpleReactingParcelFoam/verticalChannel I make an additional entry in controlDict/functions for the patch "inletSides".

    surfaceFieldValue2
    {
        type surfaceFieldValue;
        libs ("libfieldFunctionObjects.so");
        enabled yes;
        writeControl writeTime;
        log yes;
        writeFields no;
        regionType patch;
        name inletSides;
        operation weightedAverage;
        weightField phi;
        fields
        (
            T
            //p -> comes to an error
        );
    }

The result for the field "T" in postProcessing is as follows:

# Time weightedAverage(T)
0 -1.0787610941e+308
10 -1.7686424138e+308

For the field "p" I get an error at the run:

surfaceFieldValue surfaceFieldValue2 write:
    weightedAverage(inletSides) of T = -1.078761094e+308
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 double Foam::functionObjects::fieldValues::surfaceFieldValue::processSameTypeValues<double>(Foam::Field<double> const&, Foam::Field<Foam::Vector<double> > const&, Foam::Field<double> const&) const at ??:?
#4 double Foam::functionObjects::fieldValues::surfaceFieldValue::processValues<double>(Foam::Field<double> const&, Foam::Field<Foam::Vector<double> > const&, Foam::Field<double> const&) const at ??:?
#5 bool Foam::functionObjects::fieldValues::surfaceFieldValue::writeValues<double>(Foam::word const&, Foam::Field<double> const&, bool) at ??:?
#6 Foam::functionObjects::fieldValues::surfaceFieldValue::write() at ??:?
#7 Foam::functionObjects::timeControl::write() at ??:?
#8 Foam::functionObjectList::start() at ??:?
#9 Foam::Time::run() const at ??:?
#10 Foam::Time::loop() at ??:?
#11 ? in "/opt/openfoam-dev/platforms/linux64GccDPInt32Opt/bin/simpleReactingParcelFoam"
#12 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#13 ? in "/opt/openfoam-dev/platforms/linux64GccDPInt32Opt/bin/simpleReactingParcelFoam"
Gleitkomma-Ausnahme
Tags:
Steps To Reproduce: tutorials/lagrangian/simpleReactingParcelFoam/verticalChannel
Additional Information:
System Description
Attached Files:
Notes
(0010879)
henry   
2019-11-11 11:36   
The problem with this setup is that the weighting field phi is 0 on the inletSides patch at the start of the run; it is set on the first U BC update, so you will need to set

        executeAtStart no;

to avoid weighting by a 0 field.
(0010880)
HTauber   
2019-11-11 12:06   
I have added "executeAtStart no", but the error messages have remained the same.
(0010881)
henry   
2019-11-11 12:11   
(Last edited: 2019-11-11 12:14)
For me it starts fine with

        executeAtStart no;

however it fails on the first dump, I will investigate further.

(0010882)
henry   
2019-11-11 12:22   
Try this:

commit a5c33c5e18401fc369fc0d120e31d32641e378b6 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://openfoam.org>
Date: Mon Nov 11 12:20:35 2019 +0000

    functionObject::surfaceFieldValue: Added support for weighting with negative fields
    
    For example this allows the an inlet flux to be used to create a weighted
    average.
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3384
(0010883)
tniemi   
2019-11-11 12:52   
Just by looking at the commit, is the Info-output intentional (line 156)?
(0010885)
henry   
2019-11-11 13:21   
No, temporary diagnostics statement I put in for testing. I think the fix resolves the issue so I have removed the diagnostics.
(0010892)
henry   
2019-11-13 09:58   
Resolved by commit a5c33c5e18401fc369fc0d120e31d32641e378b6


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3371 [OpenFOAM] Bug minor always 2019-10-15 22:01 2019-11-12 16:42
Reporter: NauticalMile Platform: Unix  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 16.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: blockMesh quits for some combinations of vertex position and vertex / edge / face projection
Description: I have been programatically generating blockMeshDict files and noticed some funny behaviour at times.

In the attached case file, I have 3 blockMeshDict files:

1) blockMeshDictA (MESHES) : filled cylinder using 8 exterior vertices spaced evenly around the cylinder axis to create 4 blocks, each with 6 vertices.
2) blockMeshDictB (FAILS) : same as blockMeshDictA, except vertices have been rotated counter-clockwise about the axis by pi/8 radians.
3) blockMeshDictC (FAILS) : same as blockMeshDictB, except the cylinder is a tube, with an inner radius of 0.25. While blockMeshDictA and B are shorter and easier to read, they use blocks with fewer than 8 vertices. The fact that this mesh also fails suggests the problem is not linked to the number of vertices in the participating blocks.

When I say FAILS, the command line output looks like this:

$ blockMesh
/*---------------------------------------------------------------------------*\
  ========= |
  \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
   \\ / O peration | Website: https://openfoam.org
    \\ / A nd | Version: dev
     \\/ M anipulation |
\*---------------------------------------------------------------------------*/
Build : dev-6f1c3362a637
Exec : blockMesh
Date : Oct 15 2019
Time : 15:32:29
Host : [...]
PID : 932
I/O : uncollated
Case : [...]/OF_case
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Overriding DebugSwitches according to controlDict
Creating block mesh from
    "[...]/OF_case/system/blockMeshDict"
Creating block edges
Creating block faces
Creating topology blocks
$

I believe this is a bug because all that has changed between blockMeshDictA and B is the cylinder orientation, and A meshes while B does not.

blockMeshDictB can be modified to produce a mesh using one of three methods which I could find:

1) Commenting out the 3rd face projection on line 69
2) Commenting out the 6th edge projection on line 52
3) Re-ordering the nodes on line 52 (i.e. changing 7 9 --> 9 7)

For this trivial example, face projections are unnecessary, but for the more complicated meshes I wish to generate (e.g. two tubes of differing sizes intersecting at a right angle), the vertices, edges, AND faces need to be projected to ensure the geometry is modeled correctly. I would try to work around the issue by carefully controlling the node ordering, but I can't figure out a consistent fix because I don't know what the root cause is.
Tags:
Steps To Reproduce: cd OF_case
blockMesh -dict blockMeshDictB #or A or C
Additional Information:
System Description
Attached Files: OF_case.zip (4,089 bytes) 2019-10-15 22:01
https://bugs.openfoam.org/file_download.php?file_id=2814&type=bug
Notes
(0010889)
henry   
2019-11-12 16:20   
I tested the three mesh files and they all fail, even blockMeshDictA

blockMesh -dict system/blockMeshDictA
/*---------------------------------------------------------------------------*\
  ========= |
  \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
   \\ / O peration | Website: https://openfoam.org
    \\ / A nd | Version: dev
     \\/ M anipulation |
\*---------------------------------------------------------------------------*/
Build : dev-da429d77f5bf
Exec : blockMesh -dict system/blockMeshDictA
Date : Nov 12 2019
Time : 16:19:55
Host : "dm"
PID : 19776
I/O : uncollated
Case : /home/dm2/henry/OpenFOAM/henry-dev/run/Bugs/blockMesh/OF_case
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
SetNaN : Initialising allocated memory to NaN (FOAM_SETNAN).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Overriding DebugSwitches according to controlDict
Creating block mesh from
    "/home/dm2/henry/OpenFOAM/henry-dev/run/Bugs/blockMesh/OF_case/system/blockMeshDictA"
Creating block edges
Creating block faces
Creating topology blocks
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib64/libc.so.6"
#3 Foam::blockFaces::projectFace::project(Foam::blockDescriptor const&, int, Foam::Field<Foam::Vector<double> >&) const at ??:?
#4 Foam::blockDescriptor::correctFacePoints(Foam::FixedList<Foam::Field<Foam::Vector<double> >, 6u>&) const at ??:?
#5 Foam::block::createPoints() at ??:?
#6 Foam::block::block(Foam::dictionary const&, int, Foam::Field<Foam::Vector<double> > const&, Foam::PtrList<Foam::blockEdge> const&, Foam::PtrList<Foam::blockFace> const&, Foam::Istream&) at ??:?
#7 Foam::block::New(Foam::dictionary const&, int, Foam::Field<Foam::Vector<double> > const&, Foam::PtrList<Foam::blockEdge> const&, Foam::PtrList<Foam::blockFace> const&, Foam::Istream&) at ??:?
#8 void Foam::PtrList<Foam::block>::read<Foam::block::iNew>(Foam::Istream&, Foam::block::iNew const&) at ??:?
#9 Foam::blockMesh::createTopology(Foam::IOdictionary const&, Foam::word const&) at ??:?
#10 Foam::blockMesh::blockMesh(Foam::IOdictionary const&, Foam::word const&) at ??:?
#11 ? at ??:?
#12 __libc_start_main in "/lib64/libc.so.6"
#13 ? at /home/abuild/rpmbuild/BUILD/glibc-2.29/csu/../sysdeps/x86_64/start.S:122
Floating point exception (core dumped)
(0010890)
henry   
2019-11-12 16:34   
The issue relates to the edge projection producing the correct surface so that the face projection does nothing and produces a 0 initial residual for the iteration but this is used to normalise subsequent residuals to it fails due to a /0. I am testing a fix, will push shortly.
(0010891)
henry   
2019-11-12 16:42   
Resolved in OpenFOAM-7 by commit 1e109ebe0c17e31207112de2cc13511e9fe87842
Resolved in OpenFOAM-dev by commit e7128a08529cb1b483b83f51c944a10ff73864b4


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3378 [OpenFOAM] Bug minor always 2019-10-31 12:00 2019-11-11 08:49
Reporter: HTauber Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: foamMonitor: Error message at live monitoring of probes
Description: The live plot of probes produces an error message
- my input: $ foamMonitor postProcessing/probes/0/p


"postProcessing/probes/0/p" using 1:6 with lines title "data4"
^
"/tmp/tmp.Ua3yQn", line 12: invalid command

/opt/openfoam-dev/bin/foamMonitor: 211: kill: No such process
Tags:
Steps To Reproduce: tutorials/incompressible/pimpleFoam/RAS/TJunction
Additional Information:
System Description
Attached Files: p (1,314 bytes) 2019-11-04 15:27
https://bugs.openfoam.org/file_download.php?file_id=2820&type=bug
Notes
(0010857)
henry   
2019-10-31 12:11   
Can you provide a patch which resolves this problem?
(0010858)
HTauber   
2019-10-31 12:17   
I'm sorry, but I have little experience with C++
(0010859)
henry   
2019-10-31 13:09   
foamMonitor is a script, not C++, it is in the bin directory:

#!/bin/sh
#------------------------------------------------------------------------------
# ========= |
# \\ / F ield | OpenFOAM: The Open Source CFD Toolbox
# \\ / O peration | Website: https://openfoam.org
# \\ / A nd | Copyright (C) 2015-2019 OpenFOAM Foundation
# \\/ M anipulation |
#------------------------------------------------------------------------------
# License
# This file is part of OpenFOAM.
#
# OpenFOAM is free software: you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# OpenFOAM is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
# for more details.
#
# You should have received a copy of the GNU General Public License
# along with OpenFOAM. If not, see <http://www.gnu.org/licenses/>.
#
# Script
# foamMonitor
#
# Description
# Monitor data with Gnuplot from time-value(s) graphs written by OpenFOAM
# e.g. by functionObjects
# - requires gnuplot
#
#------------------------------------------------------------------------------
.
.
.
(0010860)
HTauber   
2019-10-31 15:47   
I'll take a look at it
(0010861)
HTauber   
2019-11-04 14:53   
The problem is caused by having more spaces between "#" and "Time" as you see in file postProcessing/probes/0/p

# Probe 0 (1e-06 0 0.01)
# Probe 1 (0.21 -0.20999 0.01)
# Probe 2 (0.21 0.20999 0.01)
# Probe 3 (0.21 0 0.01)
# Probe 0 1 2 3
# Time

The cut command in the foamMonitor script (row 181 and 182) causes this problem as described in the following link
https://stackoverflow.com/questions/816820/use-space-as-a-delimiter-with-cut-command

The following modification in the foamMonitor script would resolve this problem:
-181: xlabel=$(echo "$keys" | cut -d " " -f2)
+181: xlabel=$(echo "$keys" | tr -s " " | cut -d " " -f2)
-182: keys=$(echo "$keys" | cut -d " " -f3-)
+182: keys=$(echo "$keys" | tr -s " " | cut -d " " -f3-)
(0010862)
HTauber   
2019-11-04 15:18   
This is the correct postProcessing file:

# Probe 0 (1e-06 0 0.01)
# Probe 1 (0.21 -0.20999 0.01)
# Probe 2 (0.21 0.20999 0.01)
# Probe 3 (0.21 0 0.01)
# Probe 0 1 2 3
# Time
  ^^^^
(0010863)
HTauber   
2019-11-04 15:27   
When copying the spaces will be removed. Therefore the file is attached to see the right positions.
(0010866)
will   
2019-11-05 09:31   
The problem isn't foamMonitor, the problem is the output of probes. All other data output of this kind that I can find (residuals, forces, interfaceHeight) has the following format:

# Arbitrary number of lines of header
# ...
# ...
# ...
# x-name y0-name y1-name y2-name
  1 2 3 4
  5 6 7 8

Whether as probes has this:

# Arbitrary number of lines of header
# ...
# ...
# ...
# y-name y0-subName y1-subName y2-subName
# x-name
  1 2 3 4
  5 6 7 8

Probes predates everything else, so the difference is probably just historic.

FoamMonitor can't be expected to be compatible with a variety of inconsistent input formats. Probes needs fixing so it matches the formatting of the other functions.
(0010870)
henry   
2019-11-05 15:23   
Try with this:

commit 19c03e4dd044ad47e2d03e45c4da74f889d556a3
Author: Henry Weller <http://openfoam.org>
Date: Tue Nov 5 15:19:03 2019 +0000

    sampling::probes: Improved the output table format to be more consistent with logFiles
    
    Columns are now fixed width, left justified and the column headings are on one
    line.
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3378#c10866
(0010877)
HTauber   
2019-11-11 08:41   
Thanks, it works now.
(0010878)
henry   
2019-11-11 08:49   
Resolved by commit 19c03e4dd044ad47e2d03e45c4da74f889d556a3


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3025 [OpenFOAM] Bug major always 2018-08-03 19:24 2019-10-21 08:25
Reporter: schuylerhinman Platform: Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 16.04  
Status: resolved Product Version: 6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 6  
    Target Version:  
Summary: wallHeatFlux Utility - Error in new versions - internalEnergy/Enthalpy mismatch for sonicFoam and rhoCentralFoam
Description: Our lab uses rhoCentralFoam and sonicFoam extensively along with the wallHeatFlux utility. We recently upgraded from 2.3 to the newest version. We have stuck with 2.3 this long as we had tested it extensively and made a few small local modifications. In doing some of our routine benchmarking, we have found that the new wallHeatFlux utility gives the wrong answer as it calls whatever form of energy is used in the solver - and perhaps the incorrect formulation of alpha. If we change the dictionary to sensibleEnthalpy, the wallHeatFlux calculation is corrected back to the answer provided by OF2.3 - which is the correct answer.

We benchmark rhoCentralFoam against our own in-house boundary layer solver. OF 2.3 post-processing matches closely to our in-house solver prediction which is an exact numerical solution of the compressible boundary layer equations.

The difference is substantial ~30% for this test case between OF 2.3 and 5/6 postprocessing. This error is nearly constant (corresponding to roughly the % difference between Cv and Cp). Most likely, the utility should be modified to always use alpha_h and wall-normal gradient in enthalpy, or simply Fourier's law.

We have tested this rigorously, including with:
-OF2.3,
-OF5,
-OF6,
-constant Cp,
-Constant viscosity,
-Sutherland's law,
-JANAF implementations.

The error occurs in both 5 and 6 in any of these thermophysical configurations. Please advise if we have overlooked something simple.

Regards,

Dr. W. Schuyler Hinman and Henry Stoldt (MSc. Research Student)
Tags:
Steps To Reproduce: Run post-processing in the older version (2.3) on final time step. Run post-processing again in 5 or 6. The results do not match. If you change to sensibleEnthalpy in the thermophysical properties dictionary and post-process again in 6, you recover the original (correct) answer.

Here is a link to a google drive containing the test case:

https://drive.google.com/open?id=1YSyrF9y2GIGmdfycc0V93rBG24a2tj_X
Additional Information: We have also found a discrepancy in the solution itself between 2.3 and 6, likely a result of a similar mismatch between alpha and gradient in energy/enthalpy. A separate bug report is to follow.
Attached Files: wallHeatFluxBug_rhoCentralFOam.ods (39,734 bytes) 2018-08-03 19:24
https://bugs.openfoam.org/file_download.php?file_id=2496&type=bug
Notes
(0009895)
henry   
2018-08-03 20:07   
Are your tests laminar or turbulent? If turbulent with which model?
(0009896)
schuylerhinman   
2018-08-03 20:18   
These are all laminar. This is to ensure the most basic benchmarking. We use a different case for testing turbulent BL.
(0009897)
henry   
2018-08-03 20:32   
I see the problem and there are a couple of ways to fix it, will work on it over the weekend.
(0009898)
schuylerhinman   
2018-08-03 20:36   
Thank you very much Henry. We are heavy users of OpenFOAM and greatly appreciate all your hard work. This was our first chance to try to contribute to the project.

Keep up the great work!

Please see the next bug I am about to file. It may or may not be related.
(0009902)
henry   
2018-08-05 12:31   
Resolved in OpenFOAM-6 by commit 1a0c91b3baa88265a11ad9dbf76c15375daf8087
Resolved in OpenFOAM-dev by commit f7100178e4c2d916da550071aa96447eefaff45c


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3372 [OpenFOAM] Patch text always 2019-10-16 05:32 2019-10-18 11:58
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Some additional corrections to typos
Description: In my previous run with cspell I missed some files and some typos, so I decided to make one additional, more thorough run. This resulted in quite a big list of additional typos.

I have attached two patches, the first one is big but all the changes are made to comments. The second patch is smaller, but contains some changes to code. However, even in these most of the changes are related to Info-messages and only couple of them are actual code pieces.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: typos_in_comments.diff (157,985 bytes) 2019-10-16 05:32
https://bugs.openfoam.org/file_download.php?file_id=2815&type=bug
typos_in_code.diff (28,903 bytes) 2019-10-16 05:32
https://bugs.openfoam.org/file_download.php?file_id=2816&type=bug
Notes
(0010845)
henry   
2019-10-18 11:58   
Thanks Timo

Resolved by
commit 81fca4c43af8ee439b3811660f1bdad78c4ae1b9
commit 4e6695e32dcc995840c92ee939d40a4fba54f99d


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3373 [OpenFOAM] Patch text always 2019-10-17 18:00 2019-10-17 18:47
Reporter: tteichmann Platform: all  
Assigned To: henry OS: all  
Priority: low OS Version: all  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Correct header of bin/sonicFoam
Description: The header was likely copied from some older script and not updates. The attached patch updates the header to actually reflect what the script does.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch.diff (1,005 bytes) 2019-10-17 18:00
https://bugs.openfoam.org/file_download.php?file_id=2817&type=bug
Notes
(0010844)
henry   
2019-10-17 18:47   
Resolved by commit 7ec1f0d6a8f4dfe237d18caf5905e3ff9f05efef


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3370 [OpenFOAM] Patch minor sometimes 2019-10-13 19:45 2019-10-14 09:33
Reporter: tniemi Platform:  
Assigned To: will OS:  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: fieldValues: guard against division by zero
Description: I have attached a patch which adds protection against division by zero to volFieldValue and surfaceFieldValue for weighted operations. Since the recent commit which added executeAtStart, it is quite easy to hit division by zero if weighting with eg. phi or alphaRhoPhi.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: fieldValues.diff (2,660 bytes) 2019-10-13 19:45
https://bugs.openfoam.org/file_download.php?file_id=2813&type=bug
Notes
(0010842)
will   
2019-10-14 09:33   
Thanks for the patch. Resolved by https://github.com/OpenFOAM/OpenFOAM-dev/commit/8ea55e8f06d6028afa9d3b38033132606c35c09d


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3369 [OpenFOAM] Patch text always 2019-10-13 18:14 2019-10-14 09:33
Reporter: tniemi Platform:  
Assigned To: will OS:  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Corrections to misc. typos
Description: I played around with cspell and fixed a bunch of typos. They are mostly in comments, except for solidEqulibriumEnergySource where the typo is in the class name.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch_typos.diff (145,811 bytes) 2019-10-13 18:14
https://bugs.openfoam.org/file_download.php?file_id=2812&type=bug
Notes
(0010841)
will   
2019-10-14 09:33   
Thanks for the patch. Resolved by https://github.com/OpenFOAM/OpenFOAM-dev/commit/2b0c5028a417e2bee480176daa3886d1d7821572


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3367 [OpenFOAM] Bug text always 2019-10-10 17:01 2019-10-10 17:19
Reporter: tteichmann Platform: all  
Assigned To: henry OS: all  
Priority: low OS Version: all  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: mhdFoam: Typo in description
Description: pH -> pB

can be quite confusing if you read the description and go through the code.
Tags:
Steps To Reproduce:
Additional Information: pull request available at: https://github.com/OpenFOAM/OpenFOAM-dev/pull/23/commits/dccde923d7ba67cba01dd9f883da7db5c7d7f7d1
Attached Files:
Notes
(0010831)
henry   
2019-10-10 17:19   
Resolved by commit 19fd11d41846d5a1aa0b1ec6dcc5a14b108f4c78


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3365 [OpenFOAM] Contribution minor have not tried 2019-10-09 14:07 2019-10-09 15:10
Reporter: handrake0724 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: dev  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: DFBI motion solver
Description: I wrote a DFBI (Dynamic Fluid Body Interaction) class which cause to move computational domain with body motion.
body motion is calculated based on hydrodynamic loads and restraints.

most of the codes look like rigidBodyMeshMotion class but inherited from points0MotionSolver.
I found that restraints are not affected by ramp function but usually restraints forces are expected to work after ramp ends in order to have only flow fields developed.

This class is of use in offshore fields i.e. VIM simulations for an alternative solution to morphing mesh. others may find their own usage.

I have attached source code and tutorial case.

Please review if it is useful.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: rigidBodyDFBIMotionSolver.tar.gz (4,707 bytes) 2019-10-09 14:07
https://bugs.openfoam.org/file_download.php?file_id=2803&type=bug
freeDecayingCylinder.tar.gz (3,661 bytes) 2019-10-09 14:07
https://bugs.openfoam.org/file_download.php?file_id=2804&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3306 [OpenFOAM] Contribution minor always 2019-07-13 16:19 2019-10-08 16:19
Reporter: Shorty Platform: Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Extension to the age function object
Description: Hi everybody,

I am already in contact with Henry. However, I want to sum it up for transparency here. As I am implementing the comfort library into a function object right now, I want to avoid duplication of code (also Henry mentioned that). The mean age of air calculation (which is a common quantity for HVAC applications) can be calculated by the already implemented age function object library. However, this quantity needs the diffusion term (e.g., Bartak M. et al., Experimental and numerical study of local mean age of air). The Schmidt number of (laminar and turbulent) are set to 1. Thus, we can use the muEff or nuEff quantity from the turbulence model.

For that purpose, I added the diffusion term which can be switched on and off now.
Additionally, to that, I added the convergence criteria for the correction loop (nCorr).

For that extension (diffusion), I also have a tutorial in mind that demonstrates the usage as well as a comparison to experimental data.
I can also work on that tutorial and validation.

Tobi
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: age.tar.gz (3,140 bytes) 2019-07-13 16:19
https://bugs.openfoam.org/file_download.php?file_id=2712&type=bug
updated_Age_functionObject.tgz (3,308 bytes) 2019-07-14 21:49
https://bugs.openfoam.org/file_download.php?file_id=2713&type=bug
Notes
(0010558)
Shorty   
2019-07-14 21:49   
Hi all, after some more discussion with Henry and his tweaking, the new function object is attached. The new age function object now includes the option to add the diffusion term using the coefficient muEff or nuEff and a tolerance abort extension.
(0010811)
henry   
2019-10-08 16:19   
Resolved by commit a2a74cbb7921c2e0de3e5aa1f319e5913b65e771


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3358 [OpenFOAM] Contribution minor have not tried 2019-10-02 11:09 2019-10-08 15:05
Reporter: handrake0724 Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: external force restraint class
Description: I have made a restraint class mimicking external force using Function1 class.

When simulating towing tunnel test or roll damping or VIM test,
it is necessary to have a external force like force compensation of drag as a static force.
or it is useful to give a initial excitation force for roll or initial offset for decay test with morphing mesh.

At the moment, it is not possible to use time information in restraint class and static force is only available.
but, once time information is available later, this class can be modified and find more flexible usages.

Please review this class if it is useful.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: externalFunction1Force.tar.gz (1,994 bytes) 2019-10-02 11:09
https://bugs.openfoam.org/file_download.php?file_id=2786&type=bug
patch.diff (17,781 bytes) 2019-10-02 16:04
https://bugs.openfoam.org/file_download.php?file_id=2788&type=bug
reverseRamp.tar.gz (1,549 bytes) 2019-10-02 19:22
https://bugs.openfoam.org/file_download.php?file_id=2791&type=bug
Notes
(0010786)
henry   
2019-10-02 11:22   
> At the moment, it is not possible to use time information in restraint class and static force is only available.
> but, once time information is available later, this class can be modified and find more flexible usages.

Would it make sense for this to wait until you have completed the updates to provide time to the restraint classes?
(0010789)
handrake0724   
2019-10-02 16:04   
I have updated externalFunction1Force class after updating restraint class.
Also, I have created inverseLinearRamp Function1<scalar> class in order to implement initial excitation force.
Please review if it is useful.
(0010790)
henry   
2019-10-02 16:43   
It makes more sense to name inverseLinearRamp reverseLinearRamp as inverse implies reciprocal for a scalar. Also if reverse ramps are needed I assume that any form might need to be reversed and rather than implement reverse versions of all of them it would make more sense to implement a wrapper class which instantiates a ramp and evaluates and returns the corresponding reverse. The alternative would be to implement a generic linear function in which the start and end values are specified so that it can either ramp up or down.
(0010791)
handrake0724   
2019-10-02 17:12   
Thanks for the comments.
about the reverse ramp idea, in my opinion, it would be simpler if reverse switch is provided in ramp class such that linearRamp would return either
  max(min( (t - start_)/duration, 1), 0)
or
  max(min( 1- (t - start_)/duration, 1), 0)

Then, all the subclasses of ramp can remain without changes while providing reverse ramp functionality.
What do you make of it?
(0010792)
henry   
2019-10-02 17:43   
It is more flexible, less code and easier to maintain to add a wrapper class rather than add complexity to each of the current and all future ramp classes.
(0010794)
handrake0724   
2019-10-02 19:22   
henry, I wrote a wrapper class which reverses original ramp classes.
(0010797)
henry   
2019-10-04 15:38   
There are a lot of issues with the reverseRamp implementation and it does not work properly as provided, at least it needs a copy constructor so that the ramp it stores is duplicated as necessary and a writeData function otherwise it is not written out post-processing and restart is not possible. I am updating the code now and will push after completing the tests.
(0010798)
henry   
2019-10-04 16:09   
The updated reverseRamp is now in OpenFOAM-dev: commit 8756e82afdb0a0eba32383a999f907bfc572dfcc
(0010799)
henry   
2019-10-04 16:55   
I had some problems with IO inconsistency in the externalFunction1Force class and resolved it by removing the ramp which is not necessary as the force is already time-varying.
I have pushed the updated class into OpenFOAM-dev: commit 278ba86d7d663e7eaf84eccf2d06f03ccdc1b1d2
(0010807)
henry   
2019-10-08 15:05   
Resolved by commit 278ba86d7d663e7eaf84eccf2d06f03ccdc1b1d2


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2890 [OpenFOAM] Bug minor always 2018-03-27 01:13 2019-10-03 17:41
Reporter: SamMallinson Platform: Unix  
Assigned To: henry OS: Debian  
Priority: normal OS Version: Buster  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: tutorial damBreakPorousBaffle crashes early
Description: Tried to run the interFoam/damBreakPorousBaffle tutorial; run crashes early, after third output time (0.15). CFL number climbs rapidly, followed by floating point exception in MULES step.

Error message as below.

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 void Foam::MULES::limiterCorr<double, Foam::geometricOneField, Foam::zeroField, Foam::zeroField>(Foam::Field<double>&, double const&, Foam::geometricOneField const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::zeroField const&, Foam::zeroField const&, double, double) in "/usr/local/src/sources/OpenFOAM/OpenFOAM-5.x/platforms/linux64GccDPInt32Opt/bin/interFoam"
#4 void Foam::MULES::limitCorr<double, Foam::geometricOneField, Foam::zeroField, Foam::zeroField>(double const&, Foam::geometricOneField const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>&, Foam::zeroField const&, Foam::zeroField const&, double, double) in "/usr/local/src/sources/OpenFOAM/OpenFOAM-5.x/platforms/linux64GccDPInt32Opt/bin/interFoam"
#5 ? in "/usr/local/src/sources/OpenFOAM/OpenFOAM-5.x/platforms/linux64GccDPInt32Opt/bin/interFoam"
#6 ? in "/usr/local/src/sources/OpenFOAM/OpenFOAM-5.x/platforms/linux64GccDPInt32Opt/bin/interFoam"
#7 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#8 ? in "/usr/local/src/sources/OpenFOAM/OpenFOAM-5.x/platforms/linux64GccDPInt32Opt/bin/interFoam"
Floating point exception
Tags: damBreakPorousBaffle, interFoam, Tutorial
Steps To Reproduce: 1. copy tutorial case to working directory
2. issue foam-bash command: >$ . ${WM_PROJECT_DIR}/etc/bashrc
3. >$ ./Allclean
4. >$ ./Allrun
Additional Information: attached log.interFoam
System Description
Attached Files: log.interFoam (1,132,805 bytes) 2018-03-27 01:13
https://bugs.openfoam.org/file_download.php?file_id=2388&type=bug
Notes
(0009448)
henry   
2018-03-27 11:33   
Resolved in OpenFOAM-5.x by commit 6e14d1b5ebdac4b2efb5a453886a1e9f70dd8c7c

Resolved in OpenFOAM-dev by commit 5a4d25429df2dd07ecf48d880ace0c776990e7ce


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3345 [OpenFOAM] Bug minor have not tried 2019-09-10 10:24 2019-10-02 15:06
Reporter: handrake0724 Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: suggestion of including time information in restraint class in sixDoFRigidBodyMotion and rigidBodyDynamics
Description: In simulating 6 DoF motion, sometimes it comes in handy when time varying external forces to the body are available.
for example, step function-like external force will be useful in towing simulation.

external forces acting on a body can be implemented with restraint class in sixDoFRigidBodyMotion and rigidBodyDynamics.
but in current implementation of restraint class, it is not possible to have a reference to time object.

It might be easy to add time support by passing objectRegistry object to restraint class constructor.

please check this feature implementation.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch.diff (9,869 bytes) 2019-10-02 14:31
https://bugs.openfoam.org/file_download.php?file_id=2787&type=bug
Notes
(0010715)
henry   
2019-09-10 10:33   
The rigidBodyDynamics classes are designed without the need for an objectRegistry so that they can be used in other contexts, e.g. robotics for which an OpenFOAM objectRegistry would not be required. If the current time is needed in the forces and restraint classes it would be better to pass that specifically rather than the high-level objectRegistry which may not exist for all applications of rigidBodyDynamics.
(0010717)
handrake0724   
2019-09-10 12:27   
tracing from rigidBodyMeshMotion class, time information is passed into RBD::rigidBodyMotion::solve.
in RBD::rigidBodyMotion::solve, time info is stored in motionState and only internal joint force and external force are passed into rigidBodySolver::solve member function.
in the rigidBodySolver::solve, those forces are passed into rigidBodyModel's member function applyRestraints.
and in the applyRestraints, restraints associated to a body are calculated by restrain member function.
So, time parameter will be added in rigidBodySolver::solve, rigidBodyModel::applyRestraints and restraints::restrain in order to pass current time information to restrain class.
(0010718)
henry   
2019-09-10 13:44   
Do you mean that the time parameter would need to be added to the rigidBodySolver::solve call or that rigidBodySolver::solve would pass it to rigidBodyModel::applyRestraints?
Given that rigidBodySolver::solve already has access to the current time from the rigidBodyModelState() protected member function I would suggest the latter.
(0010720)
will   
2019-09-10 15:11   
A little while ago we added a reference to the rigidBodyModelState to the jcalc method of the joints for a
 very similar reason (we needed more state information that we previously had). We could do the same for the restraints. This would allow the restraints to access the time, but also potentially any other aspect of the rigid body state.

Foam::RBD::restraint::restrain would need the new argument, as would all of it's derivations. Foam::RBD::rigidBodyModel::applyRestraints would also need it. The Foam::RBD::rigidBodySolvers then call applyRestraints with the same set of arguments as they use to call forwardDynamics.

Does that make sense? I don't know if the same is possible for sixDoF.
(0010724)
handrake0724   
2019-09-10 23:21   
yes, I think that make sense. for the sixDoF, I will study further.
(0010725)
handrake0724   
2019-09-11 05:45   
studying sixDoFRigidBodyMotion, sixDoFRigidBodyMotionState has not any information time.
access to restraints::restrain member function is maded in sixDoFRigidBodyMotion::applyRestraints() which is called in sixDoFRigidBodyMotion::updateAcceleration(fGlobal, tauGlobal).
sixDoFRigidBodyMotion::updateAcceleration is called in sixDoFSolver::updateAcceleration(fGlobal, tauGlobal)
sixDoFSolver::updateAcceleration is called in sixDoFSolver::solve(firstIter, fGlobal, tauGlobal, deltaT, deltaT0)

so sixDoF is using only time step and it doesn't look like an easy work to hand over time information up to restraint class unless chaning design of sixDoF classes or sixDoFRigidbodyMotionState. maybe best bet is to add time information to sixDoFRigidBodyMotioState and make it accessable.
(0010729)
henry   
2019-09-11 08:05   
The longer term plan is to replace sixDoF with the more general and extensible rigidBody system, the only reason why this has not yet been done is that sixDoF supports implicit handling of restraints whereas they are currently handled explicitly in rigidBody and it is non-trivial to change this to an implicit implementation but this will get done eventually, particularly if we can secure funding for it. If your cases are not critically dependent on the implicit treatment of restraints I would recommend using the rigidBody system and update that to provide the time information to the restraints.
(0010730)
handrake0724   
2019-09-11 08:49   
I got the feeling rigidBody would replace sixDoF before. in that sense, I agree with Henry. Thank you for letting me know the plan.
(0010787)
handrake0724   
2019-10-02 14:31   
I have misunderstood the previous discussion with henry so that I waited until changes were made.
I have updated restraint and its subclasses and rigidBodyModel::aplyRestraints and rigidBodySolvers to support time information.
(0010788)
henry   
2019-10-02 15:06   
Thanks for the contribution.
Resolved by commit d32795f0eda78b856846de56759bd02847676ee5


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3352 [OpenFOAM] Contribution minor have not tried 2019-09-19 12:17 2019-09-30 14:32
Reporter: handrake0724 Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: support slacked spring of linearSpring restraint
Description: when simulating floating structures with soft mooring system with linear spring,
spring is slacked instead of making restoring force.

I think this feature might be useful to someone like me in offshore field.
I made a patch to linearSpring class
please review if it is useful.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch.diff (2,159 bytes) 2019-09-19 12:17
https://bugs.openfoam.org/file_download.php?file_id=2780&type=bug
Notes
(0010782)
henry   
2019-09-30 14:32   
Thanks for the contribution.

Resolved in OpenFOAM-dev by commit f1b975bbb13b545115b5ed0b74caba5b0ae4e743


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3356 [OpenFOAM] Bug trivial always 2019-09-27 07:05 2019-09-27 11:41
Reporter: HTauber Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: libcloudFunctionObjects.so not available
Description: The information regarding the lib "libcloudFunctionObjects.so" in the files below should be "liblagrangianFunctionObjects.so"

src/functionObjects/lagrangian/cloudInfo/cloudInfo.H
src/functionObjects/lagrangian/cloudInfo/postProcessingDict
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0010778)
henry   
2019-09-27 11:41   
Resolved by commit 6f1c3362a6379ec225f9b2412a6cfd1ca35672a5


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3342 [OpenFOAM] Contribution trivial always 2019-09-03 16:31 2019-09-25 13:34
Reporter: projectionist Platform:  
Assigned To: henry OS:  
Priority: none OS Version:  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: A moderately annotated mirrorMeshDict for $FOAM_ETC/caseDicts/annotated
Description: The existing mirrorMeshDict in $FOAM_ETC/caseDicts/annotated only demonstrates one out of three methods to specify the mirror plane.

While it was trivial to find the other means by virtue of OpenFOAM's banana-test, users may probably expect to find all available options in the annotated dictionaries.

The attached mirrorMeshDict is extended by the two other means of defining the mirror-plane.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: mirrorMeshDict (1,012 bytes) 2019-09-03 16:31
https://bugs.openfoam.org/file_download.php?file_id=2754&type=bug
Notes
(0010740)
henry   
2019-09-12 22:30   
Pending signing of the contributor agreement
(0010773)
henry   
2019-09-25 13:34   
Resolved by commit 46e8d2244502de60c192a0157c192aa8a1cdd843


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3349 [OpenFOAM] Bug minor always 2019-09-17 09:39 2019-09-18 14:16
Reporter: hk318i Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: block face orientation checks don't consider the curved edges
Description: Hello,

The extra checks added in OpenFOAM-dev:87c78ca1ef8752758311177061617c18ace5f622 don't consider the topology of the block.
In case of curved faces, it gives a false error about the orientation of the faces. The issue of such cases is that some face centres and the block centre are outside the block.
Please check the attached figure. Also, attached here ``blockMeshDict`` as an example for such case (sorry it is extreme). Although the angle of this block is relatively high, such block can be meshed without problem in OpenFOAM versions earlier to version-5. I think this is because the ``blockShape_ `` is basically considered as ``cellShape`` type which is not very accurate because cells are limited to flat face unlike blocks.
 
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: centres.png (19,502 bytes) 2019-09-17 09:39
https://bugs.openfoam.org/file_download.php?file_id=2770&type=bug
blockMeshDict (40,046 bytes) 2019-09-17 09:39
https://bugs.openfoam.org/file_download.php?file_id=2771&type=bug
Notes
(0010742)
henry   
2019-09-17 09:53   
Do you have a proposal to improve the check? If not it could either be put on a switch or the error could be made a warning.
(0010744)
hk318i   
2019-09-17 10:26   
Thanks for the prompt response. I think this check itself is important but it is only fatal in case of blocks without curved edges. But in case of ``nCurvedFaces_ >0``, a warning would be enough. Then even if the face orientations are wrong for such case, post meshing checks will catch that definitely without giving the user a false error.
(0010746)
henry   
2019-09-17 11:20   
The face orientation check is performed on the block before the curves are applied so the test should be correct irrespective of the curvature of the faces.
If you run blockMesh on your blockMeshDict without the edges defined you will see the same message:

--> FOAM FATAL IO ERROR:
Block hex (1 3 2 0 5 7 6 4) (127 1 1) simpleGrading (1(641295) 1(1) 1(1)) has inward-pointing faces
    4(1 5 4 0)
(0010747)
hk318i   
2019-09-17 14:31   
I see, this check is too early and doing such check will not be reliable at this point. Maybe it could be wrapped under a debug switch. There is warring anyway by ``cellModel`` because this block isn't valid geometrically as cell.
(0010748)
henry   
2019-09-17 15:48   
I believe the check is correct and that there is an error in your blockMeshDict. If I change it to remove the duplicate vertices it works fine and does not fail at the check. Alternatively you could correct the block definition with the duplicate vertices if you want to keep them.
(0010749)
hk318i   
2019-09-17 16:14   
Sorry, I didn't get what you mean by duplicate vertices. Despite the extreme curvature, this block could be meshed as it is in OpenFOAM-4.0 and check mesh does not report any negative volumes nor faces.
(0010750)
henry   
2019-09-17 16:19   
Duplicate vertices are vertices at the same location, there are 2 duplicate pairs in your blockMeshDict. Your blockMeshDict is incorrect but because of the duplicate vertices the resulting incorrect face is removed because it is collapsed and hence the resulting mesh does not contain an error.
(0010751)
hk318i   
2019-09-17 17:06   
I double-checked and printed out the vertices

vertices
8((1 -0.003132483 0) (0.999289412 -0.00300336924 0) (24.8887426 -2.35594792 0) (24.826088 -2.94369738 0)
   (1 -0.003132483 1) (0.999289412 -0.00300336924 1) (24.8887426 -2.35594792 1) (24.826088 -2.94369738 1))

which matches ``blockMeshDict``. The vertices have same x and y but they are shifted in z. Also, I printed out centre of face0 and the checks

face[0] ##########
faceCentre: (0.999644706 -0.00306792612 0.5)
blockCentre: (16.905245230892 -1.7676191710444 0.5)
faceArea: (0.00012911376 0.00071058800000001 3.3087224502121e-24)
(faceCentre - blockCentre): (-15.905600524892 1.7645512449244 -1.1102230246252e-16)
((faceCentre - blockCentre) & faceArea): -0.00079976294879844

For me it seems that the ``faceArea`` for this face is correct and the ``faceCentre`` as well (face0 is small flat surface) but because of the ``blockCentre``, the projection has a negative sign.
(0010752)
henry   
2019-09-17 17:36   
You are right it is a geometric orientation problem rather than a topological problem, points 0 and 1 and 4 and 5 are very close and the orientation of the face they define is not good, the non-orthogonality is >90deg causing the error. Can you avoid the extreme non-orthogonality of the block? If not you will need to remove this check.
(0010754)
hk318i   
2019-09-18 07:59   
We are trying to reduce the non-orthogonality but I don't think it will pass this check. Such block is common for geometrically structured meshes around airfoils. The is example block connects the trailing edge of the lower surface of an airfoil to the far field patch (O-mesh). The mesh is generated by this open source tool
https://gitlab.cc-asp.fraunhofer.de/iwes-cfsd-public/wtrb-aerodynamics/c2d-ext

Removing the check is fine for me but I think this check at this point limits ``blockMesh``. Also, I couldn't find a clean way to disable this check without changing ``blockDescriptor`` class. There is no much room for clean extension from my side.
(0010755)
henry   
2019-09-18 08:25   
Most users find this block check very useful and would rather it were not removed permanently, also we have not received any other reports of problems with it.
The block in your example case is rather extreme and I cannot think of a change to the check which would allow such a block to pass the check so it would have to be disabled for these extreme cases.
This could be done via the debug switches in controlDict or a local switch in blockMeshDict.
(0010756)
henry   
2019-09-18 08:38   
It may be possible to make the check more robust by using the face centres of the other faces rather than the block centre, I will have a go later today.
(0010759)
henry   
2019-09-18 11:19   
Try this:

commit 471810313636980d142a995369815aa9d5db5dd8 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://openfoam.org>
Date: Wed Sep 18 11:16:41 2019 +0100

    blockMesh: Improved block face orientation check and added an optional switch
    
            //- Switch checking block face orientation
            // to ensure that all faces are outward-pointing.
            // This check may fail if the block is intentionally very twisted
            // for curved edges to be applied and can be switched off.
            static Switch checkBlockFaceOrientation;
    
    To switch this check off set
    
    checkBlockFaceOrientation false;
    
    in blockMeshDict.
(0010760)
hk318i   
2019-09-18 12:33   
Thank you very much. I tested it on the complete mesh as well, it works fine with the switch. I tried also without the switch but it didn't work. It is extreme case anyway, however having the option to procure is definitely very helpful.
(0010763)
henry   
2019-09-18 14:16   
Resolved by commit 471810313636980d142a995369815aa9d5db5dd8


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3310 [OpenFOAM] Bug major always 2019-07-19 11:43 2019-09-18 12:48
Reporter: user136 Platform: HPC-Cluster  
Assigned To: OS: CentOS  
Priority: normal OS Version: unknown  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Variable density not correctly treated in turbulence models?
Description: Hi!

We're doing large scale simulations with interFoam (water-air, flow around hydraulic structures like weirs). In these I observed an inplausible exchange of the variables of the turbulence models (k, omega, ...) from air to water and vice versa. For real life problems, this leads to huge errors in the turbulent viscosity.

I prepared a small testcase (interFoam, k-OmegaSST) to show the problem:

- Closed box
- Lower half filled with water, low value of k
- Upper half filled with air, high value of k
- No flow

Expected behaviour:

The high values of k in the air should slowly vanish. A certain amount of k should be transferred into the water (diffusion of k), but this is expected to produce only a very small rise of k in the water, due to the large density difference (NOT talking about interface effects, stratification etc.!)


Observed behaviour:

The high values of k in the air diffuse into the water with no visible impact of the different densities. From a physical point of view this is impossible, because it means that the total energy in the system grows significantly. Calculating the volume integral of "(rho*k)" for the whole domain gives the "real" turbulent kinetic energy in the system: It should drop over time, but instead it rises by more than two orders of magnitude. The attached pictures illustrate this.

Explanation:

k (turbulent kinetic energy) is not really an energy, but energy per mass unit. This it is not a quantity which follows a global conservation law. Instead, conservation must be guaranted for "(rho*k)" for advection and diffusion. Looking in the source code, we see that in the k-OmegaSST-model this seems to be done correctly by multiplying rho and k in the PDE:

     fvm::ddt(alpha, rho, k_)
      + ...
     ==
          ...

But I have the impression, that rho is _not_ the variable rho field as it should be, but a constant (geometricOneField) and thus conservation of energy is not fulfilled. The same problem is observed for other variables of the turbulence models (epsilon, omega) and for several turbulence models when using interFoam.

Best regards,

Carsten Thorenz (user136)
Tags:
Steps To Reproduce: Extract and run the attached test case in OpenFoam-7:

unzip bugreport.zip
cd _bugreport
blockMesh; setFields; interFoam





Additional Information:
System Description
Attached Files: bugreport.zip (456,395 bytes) 2019-07-19 11:43
https://bugs.openfoam.org/file_download.php?file_id=2721&type=bug
results.0000.jpg (56,131 bytes) 2019-07-19 11:43
https://bugs.openfoam.org/file_download.php?file_id=2722&type=bug
results.0002.jpg (76,441 bytes) 2019-07-19 11:43
https://bugs.openfoam.org/file_download.php?file_id=2723&type=bug
results.0006.jpg (65,170 bytes) 2019-07-19 11:43
https://bugs.openfoam.org/file_download.php?file_id=2724&type=bug
_bugreport_compressible.avi (138,558 bytes) 2019-07-19 13:03
https://bugs.openfoam.org/file_download.php?file_id=2725&type=bug
bugreport_compressible.zip (1,083,703 bytes) 2019-07-19 13:03
https://bugs.openfoam.org/file_download.php?file_id=2726&type=bug
kOmegaAlpha.tgz (4,269 bytes) 2019-09-11 12:14
https://bugs.openfoam.org/file_download.php?file_id=2756&type=bug
Notes
(0010616)
henry   
2019-07-19 11:54   
(Last edited: 2019-07-19 12:01)
Currently in interFoam the turbulence model is formulated based on the divergence free volumetric flux for incompressible flow. There is no mass-flux through the interface so k and epsilon are not transferred between the phases by a convective flux (but diffusion across the interface is permitted). Given that the density ratio is generally VERY large solving for rho*k and rho*epsilon is quite stiff and the values in the low density phase are likely to accumulate numerical error.

Have you tried setting-up interFoam with the compressible form turbulence models?

(0010617)
henry   
2019-07-19 12:16   
compressibleInterFoam is setup for either a mixture or individual phase turbulence models, all in fully conservative compressible form. You could run your case with this solver and incompressible equation of state for each phase and compare with the interFoam results. If the fully conservative approach turbulence proves reliable interFoam can be changed to be consistent with compressibleInterFoam.
(0010618)
user136   
2019-07-19 12:22   
About stiffness: Yes, is is numerically hard to take the density jump into account. But from a physical point of view it is necessary to solve for rho*k etc., Furthermore, "d(rho'k)/dt" is what is written in many publications, so the code should reproduce it.

About compressible turbulence models: I'm not sure how to do that. I just now added "libs ("libcompressibleTurbulenceModels.so");" kinto controlDict. Is that enough? If yes: It doesn't change the behaviour.
(0010619)
user136   
2019-07-19 12:23   
... sorry, didn't read your response in time. I'll try.
(0010620)
henry   
2019-07-19 12:29   
> About compressible turbulence models: I'm not sure how to do that. I just now added "libs ("libcompressibleTurbulenceModels.so");" kinto controlDict. Is that enough?

No, you would need to make some changes to interFoam (see how the turbulence models are instantiated in compressibleInterFoam) but it could be done.
(0010621)
user136   
2019-07-19 13:03   
I changed the testcase to be run with compressibleInterFoam instead. Sorry, I'm no expert for "compressible", so maybe the setup is not perfect (setup is attached).

The results are MUCH better: k no longer diffuses horribly into the water (see attached .avi-file) . Still the total energy in the system rises, though much less than with interFoam. This might be a numerical issue, as increasing the grid resolution reduced this issue (though not completely)?

I'll try over the weekend, how one of our "real world" cases reacts on running with compressibleInterFoam.
(0010624)
michele   
2019-07-19 16:09   
Hello, in my opinion this is not a bug, but just an expected behaviour of turbulence models at the interface.
I would suggest implementing the interface turbulence damping on k-w (or, if you prefer, k-wSST) model, as described here:

https://www.sharcnet.ca/Software/Ansys/16.2.3/en-us/help/flu_th/flu_th_komega_turb_damp.html

I made many simulations of hydraulic structures (and often we make also experimental validations of the numerical results): in my experience the workhorse for these simulations is the standard k-w with the turbulence damping.
Just my two cents.
(0010628)
wwzhao   
2019-07-21 13:41   
Hi, the current implementation of k-omega SST model will generate over-predicted turbulent viscosity (eddy viscosity) near the interface of two-phase flow.

One workaround is introducing buoyancy effect into k-omega SST model, which requires solving for 'd(rho*k)/dt' etc and add a buoyancy generation term for k-equation, rather than the current implementation of solving for 'dk/dt' etc.

Further information can be referred to the following two papers:

[1] Devolder, B., Troch, P., & Rauwoens, P. (2018). Performance of a buoyancy-modified k-ω and k-ω SST turbulence model for simulating wave breaking under regular waves using OpenFOAM®. Coastal Engineering, 138, 49–65. https://doi.org/10.1016/j.coastaleng.2018.04.011

[2] Larsen, B. E., & Fuhrman, D. R. (2018). On the over-production of turbulence beneath surface waves in Reynolds-averaged Navier–Stokes models. Journal of Fluid Mechanics, 853, 419–460. https://doi.org/10.1017/jfm.2018.577
(0010630)
user136   
2019-07-22 07:59   
I completely agree with michele and wwzhao, that the results of k-Omega SST (and others) would be much better at the interface, if a buoyancy (or stratification) term would be introduced. But in my oppinion, this would be a second step on top of the first:

The implementation should firstly reproduce what was written down by Menter (https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19930013620.pdf). And that includes taking the density into account in the PDE as a variable.

Experience from a users point of view: Over the weekend I computed one of our "real world" cases both with compressibleInterFoam and with interFoam with the modified turbulence model by Devolder (but without the buoyancy term): The results are better than with the standard implementation, but not perfect. As michele and wwzhao said this is due to the buoyancy/stratification effects. I can even assume systems where the results would be worse: If you are interested in the air in an air-water-system, the density might be detrimental. But again: I think the model should reproduce what was written by Menter.
(0010631)
henry   
2019-07-22 08:35   
It is not clear to me that using the physical buoyancy correction is appropriate in this case as the density distribution is a consequence of the numerical approximation and not a representation of a true distribution as it is for example in driftFluxFoam. However it is clear that when using a mixture turbulence model in VoF some correction term is needed to compensate for the unphysical generation of turbulence in the interface region. If this term is included is then it is not clear if formulating the mixture equations in energy conservative form is necessary or a good idea and some research is needed. The alternative would be to use a full two-phase formulation for the turbulence in which separate incompressible form equations are solved for the two phase which is now an option in compressibleInterFoam. The problem with this approach is interface coupling and far-field stabilisation terms will be required so that the turbulence fields are defined in the limit of the phase fraction -> 0. Again this is a research topic.
(0010632)
user136   
2019-07-22 11:52   
I think we must take care not to mix up several aspects.

- Buoyancy corrections for k-Omega-SST are necessary (but dirty) tricks to compensate for several problems
- Buoyancy correction is not only needed for the unphysical generation of turbulence, but mainly due to the fact that turbulence is "destroyed" due to stabilization effects at the water surface
- Buoyancy correction is only a dirty helper, because at the water surface the turbulence loses its isotropic properties and becomes partially anisotropic. So, strictly spoken k-Omega-SST is just not able to reproduce that.
- Apart from those considerations I think, that the implementation should reflect the original paper by Menter
(0010634)
henry   
2019-07-22 12:18   
(Last edited: 2019-07-22 12:19)
- Buoyancy corrections for k-Omega-SST are necessary (but dirty) tricks to compensate for several problems

I agree that some kind of compensation term is need at the interface but it is not clear that this as a "buoyancy" correction; some people use a physical buoyancy model to correct the numerical error but others use a specially formulated numerical correction.

- Buoyancy correction is not only needed for the unphysical generation of turbulence, but mainly due to the fact that turbulence is "destroyed" due to stabilization effects at the water surface

It is not clear to me that a standard buoyancy model is suitable or applicable for this.

- Buoyancy correction is only a dirty helper, because at the water surface the turbulence loses its isotropic properties and becomes partially anisotropic. So, strictly spoken k-Omega-SST is just not able to reproduce that.

It is likely that a two-phase formulation in which separate models are used for each phase would be more appropriate if suitable interface coupling terms can be formulated.

- Apart from those considerations I think, that the implementation should reflect the original paper by Menter

The original paper by Menter is for a low density variation single phase compressible fluid, there is no discussion of the applicability of the model to an two-phase incompressible VoF system in which the density variation is very large and numerical in origin.

Given that in interFoam the fluids are incompressible an incompressible formulation can be used. However in this there is a non-conservative transfer of the energy error at the surface rather than a conservative transfer of the energy error. If interface correction terms are added such that the turbulence goes to 0 at the interface there would be no transfer of energy across the interface and either the compressible or incompressible formulations would produce the same result but the incompressible is preferable for numerical reasons. If interface correction terms are added which do not reduce the turbulence to 0 at the interface then we would also need a explicit model for the potential transfer of this energy across the interface rather than relying on the diffusion terms in the turbulence models doing the right thing. So while I do not have a problem in principle with the turbulence model being changed to conservative form this change cannot be undertaken on the basis of the results of 1 case and without any interface correction term. interFoam has been used by thousands of people for thousands of cases over the many years since I wrote it in the late 90's and we cannot make this kind of fundamental change with knowing for what range of cases is brings benefit. Also more research is needed into the interface correction terms in both the compressible and incompressible formulations so that the best combination for a wide range of cases can be selected. It may be that for some cases having two turbulence models is better and support for this can be added if suitable coupling models are available or can be created.

(0010635)
user136   
2019-07-22 12:38   
I see the point in your considerations. And I agree that taking the density into account doesn't heal every aspect and would result in an inconsistency to the old behaviour. What about introducing a density-aware variant of k-OmegaSST as a starter for further enhancements (damping etc.)?
(0010636)
henry   
2019-07-22 12:46   
Changing interFoam to support both incompressible and compressible forms of turbulence models in a general way would be a substantial task and add a lot to the complexity and maintenance overhead; surely we should first find out if this brings sufficient benefit?
 
Have you tried the interface correction proposed by @michele? It makes sense to me and has the character of a wall-function for the interface.
(0010638)
user136   
2019-07-22 14:58   
I tried the implementaion by Devolder (https://www.researchgate.net/publication/324798236_Performance_of_a_buoyancy-modified_k-o_and_k-o_SST_turbulence_model_for_simulating_wave_breaking_under_regular_waves_using_OpenFOAMR). That one incorporates density plus a sink term for k. Works much better than the original model, but I can not judge if the sink term produces the "right" quantities. Didn't try the formulation proposed by michele.

The implementation by Devolder is available here:

OF222 - OF6: https://github.com/BrechtDevolder/buoyancyModifiedTurbulenceModels
OF1906: https://gitlab.com/brecht.devolder/buoyancyModifiedTurbulenceModels
(0010639)
henry   
2019-07-22 15:31   
That is a very odd hacked implementation, the lookup of rho should not be necessary as it is an argument to the model, the mass flux is not correct and non-conservative. It would also make sense that the buoyancy term were implemented as an fvOption rather than hard-coded into the model. My feeling is that it is inappropriate to use a buoyancy model for this correction given that there is nothing physical about the density distribution, it is purely a consequence of the numerics of interface capturing.
(0010733)
michele   
2019-09-11 12:14   
For those interested in testing the turbulence damping on k-w (Egorov 2004), i.e. the approach suggested in https://bugs.openfoam.org/view.php?id=3310#c10624 here attached a derivation of the kOmega with that implementations. The model is tested on OpenFoam 5.x.
(0010762)
user136   
2019-09-18 12:48   
Please check this thread for a follow-up discussion:

https://bugs.openfoam.org/view.php?id=3344


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3350 [OpenFOAM] Bug text always 2019-09-17 17:24 2019-09-17 17:40
Reporter: tteichmann Platform: all  
Assigned To: henry OS: all  
Priority: low OS Version: all  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Typo in src/lagrangian/solidParticle/solidParticle.C
Description: Minor typo in src/lagrangian/solidParticle/solidParticle.C
Tags:
Steps To Reproduce:
Additional Information: Pull request open at https://github.com/OpenFOAM/OpenFOAM-dev/pull/22
System Description
Attached Files:
Notes
(0010753)
henry   
2019-09-17 17:40   
Resolved by commit c1b52700c3d8d2513589cad777c0e8df1931c8f2


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3343 [OpenFOAM] Bug minor always 2019-09-04 12:14 2019-09-05 09:35
Reporter: handrake0724 Platform: x86_64  
Assigned To: will OS: Arch  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: oldCellCentre calling error when using sets functionObject
Description: In order to monitoring surface elevation in DTBHullMoving case, I have set functionObject in controlDict as follows:

functions
{
    surfaceElevation
    {
        type sets;
        libs ("libsampling.so");
        writeControl timeStep;
        writeInterval 1;

        interpolationScheme cellPointFace;
        setFormat gnuplot;
        fields (alpha.water);
        sets
        (
            gauge0
            {
                type lineUniform; // uniform;
                axis z;
                start (0 -10 -1);
                end (0 -10 1);
                nPoints 100;
            }

        );
    }
}

when the DTCHull case run with interFoam, I met the following error

--> FOAM FATAL ERROR:
Old cell centres have not been stored

    From function virtual const pointField& Foam::polyMesh::oldCellCentres() const
    in file meshes/polyMesh/polyMesh.C at line 1210.


I found that oldCellCentres() member function and oldCellCentresPtr_ memeber variable was introduced since OpenFOAM 7
Also, I found that it looks working if the dynamicFvMesh type is staticFvMesh but it make the above error if dynamicMotionSolverFvMesh.

I could not go further to study the issue but it looks like
   oldCellCentresPtr_ is assigned in movePoints when storeOldCellCentres_ is true.
   but storeOldCellCentres_ is set to true but make error since oldCellCentresPtr_ is empty in oldCellCentres() member function as follows:

const Foam::pointField& Foam::polyMesh::oldCellCentres() const
{
    storeOldCellCentres_ = true;

    if (!moving_)
    {
        return cellCentres();
    }

    if (oldCellCentresPtr_.empty())
    {
        FatalErrorInFunction
            << "Old cell centres have not been stored"
            << exit(FatalError);
    }

    return oldCellCentresPtr_();
}

Please check this issue.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0010707)
will   
2019-09-05 09:35   
Thanks for the report. Fixed in version 7 and in dev by the following commits:

https://github.com/OpenFOAM/OpenFOAM-7/commit/49b2b3b8b08220c76cf338903b1f21089fa17c56
https://github.com/OpenFOAM/OpenFOAM-dev/commit/0f5fbb7ab16cfa447c54cd65b54cf7979049b257


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3339 [OpenFOAM] Patch trivial have not tried 2019-08-24 19:25 2019-08-26 17:41
Reporter: davvalok Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Bug in Ergun drag model - Multiphase
Description: In Ergun.C, following path:
OpenFOAM-dev/applications/solvers/multiphase/reactingEulerFoam/interfacialModels/dragModels/Ergun/Ergun.C
Line 69-72:
Max(scalar(1) - pair_.continuous(), pair_.continuous().residualAlpha())
pair_.continuous().residualAlpha() should be pair_.dispersed().residualAlpha() since (scalar(1) - pair_.continuous()) refers
to the dispersed pair in reality.
Tags:
Steps To Reproduce:
Additional Information: This bug will also affect the GidaspowErgunWenYu drag model, if not being fixed.
Attached Files:
Notes
(0010697)
henry   
2019-08-25 15:47   
scalar(1) - pair_.continuous() relates to the dispersed phase fraction in a two-phase system but not in a multiphase system. Given that pair_.continuous() is used in the expression it makes sense that pair_.continuous().residualAlpha() is used. Can you provide a case which demonstrates the need to change the expression to use pair_.dispersed().residualAlpha() instead?
(0010699)
davvalok   
2019-08-26 08:17   
Hi Henry,
Thank you for your reply. I am afraid I do not have a case for it, from the mathematical point of view it seems not very accurate. If you look at the WenYu.C you can see:
volScalarField alpha2
    (
        max(scalar(1) - pair_.dispersed(), pair_.continuous().residualAlpha())
    );
Which in the content of two phase system make sense. It might be better to use max(pair_.continuous(), pair_.continuous().residualAlpha()) for the content of multiphase?

For Ergun I would suggest to use:
scalar(1) - max(pair_.continuous(), pair_.continuous().residualAlpha()) instead of max(scalar(1) - pair_.continuous(), pair_.continuous().residualAlpha()) in Ergun.C.

In either cases I guess the effect should be negligible if residualAlpha for phases are set correctly by user.
(0010700)
henry   
2019-08-26 17:36   
It is not clear how this change would affect accuracy. If you really think this change is necessary I can make it as I do not see how it will either improve or reduce accuracy or stability.
(0010701)
henry   
2019-08-26 17:41   
commit 7d6b7a78d758540fec56cd960a5a9f6aa11e7a91


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3338 [OpenFOAM] Bug minor always 2019-08-24 17:34 2019-08-25 19:55
Reporter: wyldckat Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: porosityModel::adjustNegativeResistance doesn't properly check for when all values are negative
Description: This is a somewhat peculiar issue, in method 'porosityModel::adjustNegativeResistance':

    scalar maxCmpt = max(0, cmptMax(resist.value()));

    if (maxCmpt < 0)
    {
        FatalErrorInFunction
            << "Cannot have all resistances set to negative, resistance = "
            << resist
            << exit(FatalError);
    }

Which means that 'maxCmpt' is always '>= 0', due to how the 'max' operation is being done. Therefore, someone could have used negative resistance values, gotten no resistance out of it and no fatal error accordingly...

This affects all versions of OpenFOAM, as far as I could search back into the past (seems to have been added somewhere between 1.4 and 1.5).

Attached at the following files as a proposal to fix this issue:

 - proposal_v1.patch - this provides the proposed changes, to properly both check if all values are not negative and then use the above 0 values only when needed.

 - porosityModel.C - modified file from OpenFOAM-dev to update 'src/finiteVolume/cfdTools/general/porosityModel/porosityModel/porosityModel.C', which works on both OpenFOAM-dev, 7 and 6.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: porosityModel.C (5,700 bytes) 2019-08-24 17:34
https://bugs.openfoam.org/file_download.php?file_id=2752&type=bug
proposal_v1.patch (1,486 bytes) 2019-08-24 17:34
https://bugs.openfoam.org/file_download.php?file_id=2753&type=bug
Notes
(0010698)
henry   
2019-08-25 19:55   
Thanks Bruno
Resolved in OpenFOAM-7 by commit ce67ac7f21d1edab96957a01a0b9cb5fbaff76a3
Resolved in OpenFOAM-dev by commit 9847140a8f021957a9471168e52b123136ee51e6


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3333 [OpenFOAM] Bug minor always 2019-08-22 09:58 2019-08-22 22:32
Reporter: shildenbrand Platform: HP Workstation Z640  
Assigned To: henry OS: Debian  
Priority: normal OS Version: 9.5  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Output of particleTracks in parallel and collated is not correct
Description: When using

mpirun -np #procs particleTracks -parallel

on a collated dataset, the tool works as expected.

Only the output is such that uncollated-style processor-directories are created and the result is placed in processor0/VTK.

This is a bit of a hassle as I have to place the VTK directory somewhere else and then delete all (old) processor-directories.
Tags:
Steps To Reproduce: Have a simulation with particles run in parallel (collated).

mpirun -np #procs particleTracks -parallel
Additional Information:
System Description
Attached Files:
Notes
(0010689)
henry   
2019-08-22 22:32   
Resolved by commit 43566c7f40988c548d10619640978216b53f5a2f


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3334 [OpenFOAM] Bug minor always 2019-08-22 11:15 2019-08-22 19:14
Reporter: joegi Platform: linux  
Assigned To: henry OS: OpenSuSE  
Priority: normal OS Version: 15.1  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: renumberMesh behavior in OF7 is not consistent with the behavior in OF6.
Description: If you use a non-uniform initialization (setFields, mapFields or potentialFoam) before running renumberMesh, the mesh connectivity seems to be broken.

In the attached figures you can see the results in OF7 (of7.png) and in OF6 (of6.png).

In seems that in version OF7 you need to do the non-uniform initialization after renumberMesh.

I dont know if this is the desired behavior but it wasn't like this in version 6.
Tags:
Steps To Reproduce: In the attached case follow these steps:

blockMesh
rm -rf 0
cp -r 0_2D 0
setFields
renumberMesh

This will give you the wrong results.

To get the right results:

blockMesh
rm -rf 0
cp -r 0_2D 0
renumberMesh
setFields
Additional Information:
System Description
Attached Files: cyl_renumberMesh.tar.gz (8,628 bytes) 2019-08-22 11:20
https://bugs.openfoam.org/file_download.php?file_id=2748&type=bug
of6.png (12,156 bytes) 2019-08-22 11:20
https://bugs.openfoam.org/file_download.php?file_id=2749&type=bug
of7.png (33,028 bytes) 2019-08-22 11:20
https://bugs.openfoam.org/file_download.php?file_id=2750&type=bug
Notes
(0010682)
joegi   
2019-08-22 11:20   
Forgot the files
(0010683)
henry   
2019-08-22 17:02   
While I would recommend that you run renumberMesh -noFields before setFields, which is more efficient, renumberMesh should renumber the fields correctly. I have traced the problem and applied a fix which I am now testing. I will push to OpenFOAM-7 and -dev if there are no problems or side-effects.
(0010684)
joegi   
2019-08-22 17:14   
The -noFields option has the same problem.

At least on my installation.
(0010685)
henry   
2019-08-22 17:25   
If I use

renumberMesh -noFields
setFields

it works fine
(0010686)
henry   
2019-08-22 18:58   
Resolved in OpenFOAM-dev by commit 37204c1559e4007f874c91b3f725d65af8f53c72
Resolved in OpenFOAM-7 by commit 3121f5329b52dc676a179c6a5684fcf945864912


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3332 [OpenFOAM] Bug trivial always 2019-08-21 10:21 2019-08-22 10:15
Reporter: jherb Platform: GNU/Linux  
Assigned To: will OS: OpenSuSE  
Priority: normal OS Version: 13.2  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: tutorials/multiphase/reactingTwoPhaseEulerFoam/RAS/bubbleColumnEvaporatingReacting contains uncessary files
Description: In tutorials/multiphase/reactingTwoPhaseEulerFoam/RAS/bubbleColumnEvaporatingReacting there are the files 0/AIR.liquid and 0/H2O.liquid, which are not used, because the liquid phase is specified as mixture pureMixture in constant/thermophysicalProperties.liquid

Besides this, the dictionaries for AIR, H2O and the list for species in constant/thermophysicalProperties.liquid are also not used.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0010681)
will   
2019-08-22 10:15   
Thanks for pointing this out. This will just be historic; the case shares some history with the bubbleColumnEvaporatingDissolving case.

Resolved in dev by https://github.com/OpenFOAM/OpenFOAM-dev/commit/f103a18d6e0bf599a9db2fb79fa85284aad2079a


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3330 [OpenFOAM] Bug minor always 2019-08-19 06:53 2019-08-19 11:08
Reporter: joegi Platform: linux  
Assigned To: henry OS: OpenSuSE  
Priority: normal OS Version: 15.1  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: fluent3DMeshToFoam -> Do not understand characters: ;
Description: When converting 3D meshes generated using Ansys workbench or Fluent mesher, it gives the following error:

> FOAM FATAL ERROR:
Do not understand characters: ;
    on line 6101

    From function virtual int yyFlexLexer::yylex()
    in file fluent3DMeshToFoam.L at line 748.

FOAM exiting



The error is related to a semi-colon. I think I started to see this problem after Ansys version 17 (I guess they changed something in the format). This error happens with any kind of cell type, and input file (.case or .msh).

To fix this issue, I just use sed to erase the offending semi-colon (just two):

sed -i 's/;/ /g' input_file.cas


Tags:
Steps To Reproduce: In the attached case, try to convert the mesh poly1.cas,

         fluent3DMeshToFoam poly1.cas



and you will get the error:

--> FOAM FATAL ERROR:
Do not understand characters: ;
    on line 6101

    From function virtual int yyFlexLexer::yylex()
    in file fluent3DMeshToFoam.L at line 748.

FOAM exiting



To fix the problem use sed as follows (be sure to backup the mesh first):

sed -i 's/;/ /g' polu1.cas


So far the workaround using sed seems to work fine (I have use it with meshes upto 200 million cells).
Additional Information:
System Description
Attached Files: dummy.tar.gz (164,550 bytes) 2019-08-19 07:13
https://bugs.openfoam.org/file_download.php?file_id=2746&type=bug
Notes
(0010677)
joegi   
2019-08-19 07:13   
case
(0010679)
henry   
2019-08-19 11:08   
Resolved by commit c61a66fc0021a11fe4f71178c737b7e5bb352b38


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3329 [OpenFOAM] Bug minor always 2019-08-19 06:22 2019-08-19 09:47
Reporter: joegi Platform: Linux  
Assigned To: henry OS: OpenSUSE  
Priority: normal OS Version: 15.1  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: The option minIter does not work with the linear solver PBiCGStab
Description: The option minIter does not work with the linear solver PBiCGStab.

I tested this option (minIter) with the linear solvers PBiCG, PCG, GAMG, smoothSolver (and all of them with different combinations of preconditioners), and the option minIter worked fine. I also tested this option with different physics (compressible, incompressible, multiphase), and the option worked fine.

The only linear solver that does not take the option minIter is the PBiCGStab.

Despite this, the results seem to be correct (at least for the cases where I checked this).

Tags:
Steps To Reproduce: Run any case using the the linear solver PBiCGStab and set the minIter keywork to 10 (or a larger number).
The linear solver will not iterate to the minimum number of iterations (in this case 10).

I am attaching a fast case that you can use to reproduce the issue. Just run the script run_solver.sh:

sh run_solver.sh


Check first that the PBiCGStab solver is set.
Additional Information: I didn't check if the option maxIter was having the same problem.
System Description
Attached Files: cavity2D.tar.gz (4,147 bytes) 2019-08-19 06:22
https://bugs.openfoam.org/file_download.php?file_id=2745&type=bug
Notes
(0010678)
henry   
2019-08-19 09:47   
Resolved by commit 6736543e3a61fd2c3cbc3ce64525ae63f2b1aad2


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3328 [OpenFOAM] Patch minor N/A 2019-08-14 11:53 2019-08-16 11:44
Reporter: tniemi Platform:  
Assigned To: will OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Patch: improvements to general distributionModel in the lagrangian library
Description: I have attached a patch which adds optional keyword to general distributionModel which allows to specify the function as cumulative distribution instead of density function. Quite often data is more readily available in cumulative form, for example from measurements made by sieving particles, and it would be more convenient to be able to directly use that as input.

The patch also fixes a bug in the calculation of the mean value of the general distribution. Previously, the mean was calculated as the average (unscaled) probability density which is not correct. Also, some additional sanity checks and documentation are added. The sanity checks enforce that a valid distribution must be specified.

I would also propose that the distributionModels could write the min, max and mean values to the log file during construction. The reason for this is that it is quite easy to make a mistake when specifying the distributions (especially general) and output to log would make it easier to double check that everything is in order. The patch adds an info-function and corresponding calls to support this. Additionally, there is a test application which checks the functionality provided by this patch.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch.diff (22,654 bytes) 2019-08-14 11:53
https://bugs.openfoam.org/file_download.php?file_id=2744&type=bug
Notes
(0010676)
will   
2019-08-16 11:44   
Thanks for the patch, Timo. Pushed as commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/1a54b2ecfc6b1503d10690244bb23a3f5ed985bc


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3327 [OpenFOAM] Bug trivial always 2019-08-12 08:31 2019-08-12 11:32
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Unnecessary thermo-file
Description: The file tutorials/combustion/chemFoam/gri/constant/thermo is not needed and could be deleted. It probably got added by mistake.

The Allrun-script creates "speciesThermo"-file which is used instead.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010675)
henry   
2019-08-12 11:32   
Resolved by commit 67c5e370022876f730f605117e79a31742bdf093


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3325 [OpenFOAM] Patch text always 2019-08-10 15:15 2019-08-10 16:30
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Patch for some misc. typos and inconsistencies
Description: I have attached a patch which fixes a couple of typos in several files. In distributionModel.H, the description contains a typo "unifrom", but the message itself is quite misleading, because only the uniform distribution uses tabulation and it doesn't need to be equidistant.

In ReactingParcel.C, the hmm scalarField appears to be completely unused.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch.diff (4,143 bytes) 2019-08-10 15:15
https://bugs.openfoam.org/file_download.php?file_id=2743&type=bug
Notes
(0010668)
henry   
2019-08-10 16:30   
Resolved by commit 3dfbbdbfe90da23a400d72939d50bda530474fde


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3316 [OpenFOAM] Bug minor always 2019-07-24 21:26 2019-08-05 11:33
Reporter: jheylmun Platform: GNU/Linux  
Assigned To: henry OS: Ubunutu  
Priority: normal OS Version: 19.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: dynamicRefineFvMesh fails on unrefine
Description: When the unrefine function is called an index goes out of bounds
Tags:
Steps To Reproduce: ./Allrun with tutorials/multiphase/interFoam/laminar/damBreakWithObsticle
Additional Information: Selected 51 cells for refinement out of 110733.
Refined from 110733 to 111090 cells.
Selected 5 split points out of a possible 9710.
Unrefined from 111090 to 111055 cells.


--> FOAM FATAL ERROR:
index 111055 out of range 0 ... 111054

    From function void Foam::UList<T>::checkIndex(Foam::label) const [with T = double; Foam::label = int]
    in file /home/jheylmun/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/UListI.H at line 106.

FOAM aborting

#0 Foam::error::printStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-dev/src/OSspecific/POSIX/printStack.C:218
#1 Foam::error::abort() at ~/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/error.C:249
#2 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) in "/home/jheylmun/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Debug/bin/interFoam"
#3 Foam::UList<double>::checkIndex(int) const in "/home/jheylmun/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Debug/bin/interFoam"
#4 Foam::UList<double>::operator[](int) const in "/home/jheylmun/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Debug/bin/interFoam"
#5 Foam::Field<double>::doMap(Foam::UList<double> const&, Foam::List<Foam::List<int> > const&, Foam::List<Foam::List<double> > const&) at ~/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/Field.C:327 (discriminator 2)
#6 Foam::Field<double>::map(Foam::UList<double> const&, Foam::List<Foam::List<int> > const&, Foam::List<Foam::List<double> > const&) at ~/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/Field.C:355
#7 void Foam::generalFieldMapper::map<double>(Foam::Field<double>&, Foam::Field<double> const&) const at ~/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/fields/Fields/fieldMappers/generalFieldMapper/generalFieldMapperTemplates.C:59
#8 Foam::generalFieldMapper::operator()(Foam::Field<double>&, Foam::Field<double> const&) const at ~/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/fields/Fields/fieldMappers/generalFieldMapper/generalFieldMapper.C:69
#9 Foam::MapInternalField<double, Foam::fvMeshMapper, Foam::volMesh>::operator()(Foam::Field<double>&, Foam::fvMeshMapper const&) const at ~/OpenFOAM/OpenFOAM-dev/src/finiteVolume/lnInclude/MapFvVolField.H:73
#10 void Foam::MapGeometricFields<double, Foam::fvPatchField, Foam::fvMeshMapper, Foam::volMesh>(Foam::fvMeshMapper const&) at ~/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/MapGeometricFields.H:135 (discriminator 4)
#11 Foam::fvMesh::mapFields(Foam::mapPolyMesh const&) at ~/OpenFOAM/OpenFOAM-dev/src/finiteVolume/fvMesh/fvMesh.C:595
#12 Foam::fvMesh::updateMesh(Foam::mapPolyMesh const&) at ~/OpenFOAM/OpenFOAM-dev/src/finiteVolume/fvMesh/fvMesh.C:844
#13 Foam::dynamicRefineFvMesh::unrefine(Foam::List<int> const&) at ~/OpenFOAM/OpenFOAM-dev/src/dynamicFvMesh/dynamicRefineFvMesh/dynamicRefineFvMesh.C:524
#14 Foam::dynamicRefineFvMesh::update() at ~/OpenFOAM/OpenFOAM-dev/src/dynamicFvMesh/dynamicRefineFvMesh/dynamicRefineFvMesh.C:1345 (discriminator 1)
#15 ? in "/home/jheylmun/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Debug/bin/interFoam"
#16 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#17 ? in "/home/jheylmun/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Debug/bin/interFoam"
Aborted (core dumped)
System Description
Attached Files:
Notes
(0010650)
henry   
2019-07-26 11:41   
Thanks for reporting.

Resolved in OpenFOAM-7 by commit 8235d2d20c010a4810d059a1a7c8ab414918bae5
Resolved in OpenFOAM-dev by commit 22bba48722738e54f215909839aa536f69e8b1eb


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3320 [OpenFOAM] Bug major always 2019-07-27 00:36 2019-07-30 02:49
Reporter: alpha754293 Platform: Linux  
Assigned To: OS: CentOS  
Priority: normal OS Version: 7.6.1810  
Status: new Product Version: 6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Distributed parallel processing doesn't work properly
Description: I have a fresh install of CentOS 7.6.1810 and executed the steps to install OpenFOAM on CentOS 7 here (https://openfoamwiki.net/index.php/Installation/Linux/OpenFOAM-6/CentOS_SL_RHEL#CentOS_7.5_.281804.29).

I also have Infiniband (Mellanox ConnectX-4 dual port VPI 100 Gbps NIC) and also a Mellanox MSB-7890 externally managed 36 port 100 Gbps Infiniband switch.

I've installed the Infiniband modules and opensm is running and the Infiniband devices have an IPv4 address assigned to them (ib0) along with passwordless ssh set up on both nodes.

There were no errors in the log files as a result of executing the copy-and-paste steps for the installation of OpenFOAM per the link above.

I have a NFS share set up between the two nodes so that I can try and execute the Motorbike OpenFOAM benchmark across the two nodes.

Each node has dual Intel gigabit network interfaces (eno1 and eno2).

When I try to run snappyHexMesh over the two nodes, using this command:

[ewen@aes003 run_32]$ time -p /home/ewen/OpenFOAM/ThirdParty-6/platforms/linux64Gcc/openmpi-2.1.1/bin/mpirun -x LD_LIBRARY_PATH -x PATH -x WM_PROJECT_DIR -x WM_PROJECT_INST_DIR -x WM_OPTIONS -x FOAM_LIBBIN -x FOAM_APPBIN -x MPI_BUFFER_SIZE --hostfile ../../machines.txt -np 32 snappyHexMesh -overwrite -parallel 2>&1 | tee mesh.log

this is the error I get:

[aes004][[17070,1],16][btl_tcp_endpoint.c:649:mca_btl_tcp_endpoint_recv_connect_ack] received unexpected process identifier [[17070,1],23]

machines.txt looks like this:

[ewen@aes003 run_32]$ cat ../../machines.txt
aes003 cpu=16
aes004 cpu=16

When I run it on a single node, it only takes about 3.5 minutes for snappyHexMesh to complete its task.

And I can run it on a single, but remote node, but not distributed acrossed the two nodes.

And this is the best-case scenario. Other attempts won't even start at all (e.g. if I don't export all of those environment variables out to the slave nodes).

Thank you.
Tags:
Steps To Reproduce: See above.
Additional Information: See above.
System Description
Attached Files:
Notes
(0010653)
wyldckat   
2019-07-28 20:17   
The instructions at openfoamwiki.net are provided by the community that uses OpenFOAM. Those specific instructions (were actually written by me) even state where questions about those instructions should be asked at...
Either way, the problem is that those instructions were designed for getting things up and running, leaving further tweaking to the person taking care of the installation.

There are two possible solutions to your problem:

Solution 1- You can edit the file "ThirdParty-6/Allwmake" and look for the line "Infiniband support" then remove the # from the start of the lines after that one, so that it will also build support for Infiniband. You will then need to delete the folder that is defined in "$MPI_ARCH_PATH" and run Allwmake once again.

Solution 2- The other alternative is to use the system's own Open-MPI installation. Look for the "WM_MPLIB=OPENMPI" entry on the installation instructions and remove from your own calls to the 'bashrc' file.
(0010654)
alpha754293   
2019-07-29 01:43   
Yes, unfortunately, I no longer have access to cfd-online.com due to an unrelated issue.

I suppose that I can try that.

Thank you.

I'm only raising these points up because when I install OpenFOAM in Ubuntu (same system, hardware, etc.), that one works very nicely. But I was hoping to be able to consolidate everything to CentOS rather than having mutli-boot into different Linux distros based on the application that I am trying to run.

Thank you.
(0010655)
wyldckat   
2019-07-29 11:24   
My apologies, I forgot to mention that there is indeed a limitation on 'Allwmake' script on how compiling Open-MPI is being handled... I'm planning on moving out the script code that builds Open-MPI and MPICH to their own scripts, so that users can have a better control over the build options.

Please let us know if building Open-MPI with Infiniband support works for you, or if you go with using the system's Open-MPI.
(0010656)
alpha754293   
2019-07-29 14:20   
I can try it both ways and report back on the results of each.

I think that it might help the community out if I do that as I suspect that I can't possibly be the first person to have encountered this problem with OpenFOAM v6 on CentOS 7.6.1810 and OpenMPI and Infiniband, so I'll actually run it both ways and report back on the results of each.

(I have four nodes in total so I can split up my micro compute cluster in two smaller clusters with two nodes each so that I can test both methods simultaneously -- so that the previous build of one isn't going to affect the build of the next, which represents more of a bare metal deployment.)

Thank you.

I might need more of your support/assistance as I run through this because I am not an expert in regards to building and compiling OpenFOAM with OpenMPI with Infiniband by any stretch of the imagination, so please do forgive my forthcoming dumb questions as I try this.

Thank you.
(0010657)
wyldckat   
2019-07-29 15:58   
If you can test both methods, then it can be very useful for the community.

If you edit the file "$HOME/.bashrc", you should find at the end the 'alias' command for 'of6'. If you copy-paste the line and give a new name, e.g.:

    alias of6sysompi='source $HOME/OpenFOAM/OpenFOAM-6/etc/bashrc FOAMY_HEX_MESH=yes'

Save and close the file. Then you can start a new terminal and use on the new terminal the new command 'of6sysompi' to start the environment that relies on the system's Open-MPI. Keep in mind that you might need to use a 'module load' command to load the system's Open-MPI.

This to day that you can use the same installation and be able to use each Open-MPI in function of the respective alias you activate on each terminal.
(0010658)
alpha754293   
2019-07-29 17:12   
I'll definitely test both methods.

I think that this could be a symbiotic relationship where if you help me or point me specifically to the parts where I need to edit and how I might need to edit it (again, I'm not really an "IT" person, but just an end user who is forced to have to deal with the "IT" stuff just by virtue of it, and not necessarily by choice), so any help that you will be able to provide (a la copy-paste), I will be able to execute that on my micro cluster and feedback the results to this community.

You help me help you, so to speak.

"Then you can start a new terminal and use on the new terminal the new command 'of6sysompi' to start the environment that relies on the system's Open-MPI."

But this would mean that the alias for of6 and of6sysompi would be identical, wouldn't it?

And wouldn't this also mean that the only difference would be whether I execute the 'module load' command or not, wouldn't it?

I just want to make sure that I am understanding this sufficiently in regards to how I need to set this up to test it so that when I report the results back, it would be what's expected.

If you don't mind, please treat me like an extreme novice, so that the more explicit the instructions you are able to provide, the better chance it would be that I won't screw it up. :)

Solution 1 - is to enable Infiniband support. I'm not in a position (at work now) to be able to get access to my system -- once I delete the definition for the variable $MPI_ARCH_PATH, I should be able to just run through the installation instructions from beginning to end again, correct? (I am going to do everything all over again, from a clean install so that I can be sure that there isn't problems with old stuff lingering around and interfering with the new install.)

Solution 2 - "Look for the "WM_MPLIB=OPENMPI" entry on the installation instructions and remove from your own calls to the 'bashrc' file."

Can you expand a little further, for novices such as myself, what you mean by "...from your own calls to the 'bashrc' file"?

Is that related to what you wrote above and how I might have to use 'module load' to load the system's openmpi installation?

My apologies for my dumb questions, which might seem repetative, but I want to make sure that I will be executing what you want/need me to execute so that when I report the results back, it will make sense to you.

I lack the requisite knowledge and understanding, so your help is greatly appreciated.

Thank you.
(0010659)
alpha754293   
2019-07-30 02:49   
Darn it - I just lost my post/comment. :(

1) The system provided:

# yum groupinstall 'Infiniband Support' doesn't have an ofed directory.

So I'm not sure what files/libraries the build is point to/looking for, but if you can help identify some of those files, I can either:

a) try and find those files elsewhere in a fresh, baremetals CentOS 7.6.1810 installation or

b) install the Mellanox OFED drivers.

2) re: installing with the system provided OpenMPI 1.10.7

Is there a way to set it up so that I won't have to run ThirdParty-6/Allwmake again and just point it to the system OpenMPI installation right from the get go?

The other part where I am confused is that you mentioned to delete the folder that is defined for $MPI_ARCH_PATH, and also WM_MPLIB, so how would it know to use the default OpenMPI or does that only mean that it won't build OpenMPI 2.2.1?

I can have one of my pairs of nodes run it with building OpenMPI 2.2.1 (after enabling Infiniband support) whilst I can have the other pair of nodes do it with the system OpenMPI 1.10.7.

My apologies, but I got confused at this step and didn't know what to do.

Your help in clarifying that is greatly appreciated because I don't know/understand enough of this to be able to solve this on my own.

Thank you.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3314 [OpenFOAM] Feature minor have not tried 2019-07-23 22:23 2019-07-24 16:17
Reporter: sjohn2 Platform: Unix  
Assigned To: henry OS: Other  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: 6  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: CavitatingFoam solver: barotropicCompressibilityModel
Description: On selecting the barotropicCompressibilityModel: Wallis
The variable rhovSat is not re - read from the thermodynamicProperties dictionary. Instead the it takes the same value from
the readThermodynamicProperties.H defined as: dimensionedScalar rhovSat("rhovSat", psiv*pSat);
Thereby not taking a user defined value of saturation vapour density rhovSat.


Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0010647)
henry   
2019-07-24 14:14   
Resolved by commit 9ca4cb8b992033ad2bcaa2831056b95dcbcfb150


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3303 [OpenFOAM] Bug minor always 2019-07-08 23:42 2019-07-24 14:32
Reporter: jherb Platform: SUSE Linux Enterprise 11 SP4  
Assigned To: henry OS: Other  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Compilation of (Intel) MPI fails
Description: Building OpenFOAM using the Allwmake script in $WM_PROJECT_DIR results in the following error:


Compiling enabled on 20 cores
Allwmake /home/hej/OpenFOAM/OpenFOAM-7
make: Nothing to be done for `all'.

========================================
Start ThirdParty Allwmake
========================================

========================================
Build MPI libraries if required

========================================
Build Scotch decomposition library scotch_6.0.6
    /home/hej/OpenFOAM/ThirdParty-7/platforms/linux64IccDPInt32/scotch_6.0.6
    scotch header in /home/hej/OpenFOAM/ThirdParty-7/platforms/linux64IccDPInt32/scotch_6.0.6/include
    scotch libs in /home/hej/OpenFOAM/ThirdParty-7/platforms/linux64IccDPInt32/lib

========================================
Build PTScotch decomposition library scotch_6.0.6 (uses MPI)
    /home/hej/OpenFOAM/ThirdParty-7/platforms/linux64IccDPInt32/scotch_6.0.6

    ptscotch header in /home/hej/OpenFOAM/ThirdParty-7/platforms/linux64IccDPInt32/scotch_6.0.6/include/intel64
    ptscotch libs in /home/hej/OpenFOAM/ThirdParty-7/platforms/linux64IccDPInt32/lib/intel64

========================================
Build Metis decomposition
    optional component Metis was not found
========================================
Build CGAL
    skipped because foamyHexMesh is not selected

========================================
Done ThirdParty Allwmake
========================================

Allwmake src
version changed from previous build
removing .o files corresponding to OpenFOAM/global/global.o ...
Allwmake src/Pstream
wmake dummy
wclean mpi
wmake mpi
wmakeLnInclude: linking include files to ./lnInclude
find: WARNING: Hard link count is wrong for `..' (saw only st_nlink=3 but we already saw 1 subdirectories): this may be a bug in your file system driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should
have been searched.
touch: cannot touch `/home/hej/OpenFOAM/OpenFOAM-7/platforms/linux64IccDPInt32OptINTELMPI/src/Pstream/mpi/using:intel64': No such file or directory

The offending line with the touch command is located in src/Pstream/Allrun

This are the changes of the source tree compared with the git repository of OpenFOAM-7:
diff --git a/etc/bashrc b/etc/bashrc
index 19061dc..a37af07 100644
--- a/etc/bashrc
+++ b/etc/bashrc
@@ -62,7 +62,7 @@ export WM_COMPILER_TYPE=system

 #- Compiler:
 # WM_COMPILER = Gcc | Gcc48 ... Gcc62 | Clang | Icc
-export WM_COMPILER=Gcc
+export WM_COMPILER=Icc
 unset WM_COMPILER_ARCH WM_COMPILER_LIB_ARCH

 #- Memory addressing:
@@ -86,7 +86,7 @@ export WM_COMPILE_OPTION=Opt
 #- MPI implementation:
 # WM_MPLIB = SYSTEMOPENMPI | OPENMPI | SYSTEMMPI | MPICH | MPICH-GM | HPMPI
 # | MPI | FJMPI | QSMPI | SGIMPI | INTELMPI
-export WM_MPLIB=SYSTEMOPENMPI
+export WM_MPLIB=INTELMPI

 #- Operating System:
 # WM_OSTYPE = POSIX | ???
diff --git a/src/Pstream/Allwmake b/src/Pstream/Allwmake
index 9fdd37b..11a7f90 100755
--- a/src/Pstream/Allwmake
+++ b/src/Pstream/Allwmake
@@ -17,7 +17,7 @@ wmakeMpiLib()
         whichmpi="$WM_PROJECT_DIR/platforms/$WM_OPTIONS/src/Pstream/$libName/using:$FOAM_MPI"
         [ -e "$whichmpi" ] || wclean $libName
         wmake $targetType $libName
- touch "$whichmpi"
+ #touch "$whichmpi"
     )
     done
 }
diff --git a/wmake/rules/General/mplibINTELMPI64 b/wmake/rules/General/mplibINTELMPI64
index 278e0b0..dbcc758 100644
--- a/wmake/rules/General/mplibINTELMPI64
+++ b/wmake/rules/General/mplibINTELMPI64
@@ -1,3 +1,3 @@
 PFLAGS = -DMPICH_SKIP_MPICXX
-PINC = -isystem $(MPI_ARCH_PATH)/include64
-PLIBS = -L$(MPI_ARCH_PATH)/lib64 -lmpi
+PINC = -isystem /home/software/intel/Intel-2018/compilers_and_libraries_2018.0.128/linux/mpi/intel64/include
+PLIBS = -L/home/software/intel/Intel-2018/compilers_and_libraries_2018.0.128/linux/mpi/intel64/lib -lmpi

(removing the touch command allows to compile the source)

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: bashrc_proposal_v3 (7,432 bytes) 2019-07-17 00:48
https://bugs.openfoam.org/file_download.php?file_id=2714&type=bug
proposal_v3.patch (1,031 bytes) 2019-07-17 00:48
https://bugs.openfoam.org/file_download.php?file_id=2715&type=bug
bashrc_proposal_v4 (7,566 bytes) 2019-07-17 23:37
https://bugs.openfoam.org/file_download.php?file_id=2716&type=bug
proposal_v4.patch (1,622 bytes) 2019-07-17 23:37
https://bugs.openfoam.org/file_download.php?file_id=2717&type=bug
proposal_v5.patch (2,639 bytes) 2019-07-18 23:23
https://bugs.openfoam.org/file_download.php?file_id=2719&type=bug
wclean_proposal_v5 (8,946 bytes) 2019-07-18 23:23
https://bugs.openfoam.org/file_download.php?file_id=2720&type=bug
proposal_v6.patch (3,670 bytes) 2019-07-22 01:46
https://bugs.openfoam.org/file_download.php?file_id=2727&type=bug
proposal_v6.tar.gz (6,231 bytes) 2019-07-22 01:46
https://bugs.openfoam.org/file_download.php?file_id=2728&type=bug
Notes
(0010561)
henry   
2019-07-15 09:59   
The patches you have provided hard-code paths which means that with them OpenFOAM would only compile on your machine with Intel MPI.
(0010565)
jherb   
2019-07-15 22:10   
Yes, I am aware, that in my "patch" I hard-coded paths.

The main problem is, that the Allwmake script/wmake want to touch this file:
touch: cannot touch `/home/hej/OpenFOAM/OpenFOAM-7/platforms/linux64IccDPInt32OptINTELMPI/src/Pstream/mpi/using:intel64': No such file or directory

And I cannot understand, how this file name is build. Perhaps, the problem is, that my OpenFOAM installation is using (symbolic) links. Building OpenFOAM-6 works.

A more generic patch would be to add the paths to include and include64 and lib and lib64:

diff --git a/wmake/rules/General/mplibINTELMPI64 b/wmake/rules/General/mplibINTELMPI64
index 278e0b0..dbcc758 100644
--- a/wmake/rules/General/mplibINTELMPI64
+++ b/wmake/rules/General/mplibINTELMPI64
@@ -1,3 +1,3 @@
 PFLAGS = -DMPICH_SKIP_MPICXX
-PINC = -isystem $(MPI_ARCH_PATH)/include64
-PLIBS = -L$(MPI_ARCH_PATH)/lib64 -lmpi
+PINC = -isystem $(MPI_ARCH_PATH)/include64 -isystem $(MPI_ARCH_PATH)/include
+PLIBS = -L$(MPI_ARCH_PATH)/lib64 -L$(MPI_ARCH_PATH)/lib -lmpi

But this still does not solve my problem with the broken build.
(0010566)
henry   
2019-07-15 22:25   
I am not able to reproduce the problem, for me the "touch" creates the empty file as intended.
(0010567)
henry   
2019-07-15 22:33   
I compared OpenFOAM-6/src/Pstream/Allwmake with OpenFOAM-7/src/Pstream/Allwmake, they are identical so the file touch occurs for both version 6 and version 7.
(0010570)
jherb   
2019-07-16 09:29   
Reverting this commit fixes the problem:
9980357df166e81b5d67fe6de33f9fff7869e373
(0010571)
henry   
2019-07-16 10:02   
I can revert that commit but it was needed to resolve

https://bugs.openfoam.org/view.php?id=3301
(0010573)
paulmedwards   
2019-07-16 11:52   
What is the filesystem being used here? And, what is the output from `pwd` and `pwd -P` in the top level OpenFOAM directory? This seems to be the issue:

find: WARNING: Hard link count is wrong for `..' (saw only st_nlink=3 but we already saw 1 subdirectories): this may be a bug in your file system driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should
have been searched.

(which I am guessing is coming from the `pwd -P`)
(0010574)
jherb   
2019-07-16 13:45   
My setup is:

OpenFOAM is located in /manni/data/hej/OpenFOAM/OpenFOAM-7
HOME is /home/hej
there are two symbolic links:
/home/hej/data -> /manni/data/hej
/home/hej/OpenFOAM/OpenFOAM-7 -> /home/hej/data/OpenFOAM/OpenFOAM-7

In the old version the IF clause in https://github.com/OpenFOAM/OpenFOAM-dev/commit/9980357df166e81b5d67fe6de33f9fff7869e373#diff-2a9ede44ae79c09f1b202e1e5db7e69eL398 evaluates to true, in the new version it is false, because:
exPath: /manni/data/hej/OpenFOAM/OpenFOAM-7/src/Pstream/mpi
and
WM_PROJECT_DIR: /home/hej/OpenFOAM/OpenFOAM-7
(0010575)
jherb   
2019-07-16 14:10   
This is the output of pwd -P in the OpenFOAM-7 folder:

hej@manni:~/OpenFOAM/OpenFOAM-7> pwd -P
/manni/data/hej/OpenFOAM/OpenFOAM-7
(0010576)
paulmedwards   
2019-07-16 14:26   
Do you edit the FOAM_INST_DIR inside `OpenFOAM-7/etc/bashrc`? If you haven't changed this, I am confused why you would have the shortened version of `$HOME/$WM_PROJECT`.

@Henry
- When would this export ever return a false value to execute the second part - https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/etc/bashrc#L46)
- A potential fix would be to set WM_PROJECT_INST_DIR to be the expanded path of $FOAM_INST_DIR here - https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/etc/bashrc#L113
(0010577)
henry   
2019-07-16 14:42   
(Last edited: 2019-07-16 14:54)
I was not involved in the changes to https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/etc/bashrc#L46 to handle links,
I never use links in the installation of OpenFOAM. This line has been changed several times over the last few years by people wanting to handle links in different and more complex ways, the last time it was

commit 047460b0532160794a5cdfa54ba75766485b3a4f

in response to patch request https://bugs.openfoam.org/view.php?id=2490

prior to that it was changed by Bruno Santos:

commit 423ac54eabed1a9df7cd906686a8499f4cf69719

etc/bashrc: Added support for sourcing etc/bashrc with relative path
    
    Patch contributed by Bruno Santos
    Resolves bug-report http://bugs.openfoam.org/view.php?id=2310

and prior to that

commit a874d8fae19a04b2f562655d4e9ead127c5c2540

    OpenFOAM-dev/etc/bashrc: Use 'pwd -P' to handle relative paths and links
    Resolves bug-report http://bugs.openfoam.org/view.php?id=2223

the changes go on before this but it gets harder to trace. Most of the changes are patches provided by Bruno Santos.

(0010578)
wyldckat   
2019-07-16 15:15   
The logic was that 'pwd -P' will point to the correct/real path where OpenFOAM is really installed. So far, I haven't managed to trip over a situation where this was not wanted/expected, given that it's not strictly necessary to install OpenFOAM at '~/OpenFOAM/OpenFOAM-*'.

Having the symbolic link might be useful to get around in the filesystem and this issue with the symbolic paths breaking when building MPI dependent libraries has also been reported here: https://bugs.openfoam.org/view.php?id=2204

So in order to keep things consistent, there are two things that are needed:

1. We need a clear answer (and a clear test scenario) as to why the symbolic path should be respected and why not always respect the real path?

2. The 'wmakeMpiLib' function is a hack in the 'Allwmake' scripts that shouldn't be necessary and should instead be managed by 'wmake' automatically, given that there 2 or 3 places where the hack is needed.
(0010579)
wyldckat   
2019-07-16 15:22   
@jherb: What is the specific filesystem used in '/manni/data'? Is it FAT32, NTFS, BTRFS, XFS, EXT4 or some other type?
(0010580)
jherb   
2019-07-16 16:22   
The filesystem of /manni is beegfs

(https://www.beegfs.io/content/)

But I think pwd -P is giving the correct answer. So I think the file system type is not the problem here, is it?
(0010581)
wyldckat   
2019-07-16 16:36   
@jherb: Wow, I didn't expect that... interesting file system... although it's not entirely clear if the long paths did fully resolve or not.

Please test the following commands:

    cd /home/hej/OpenFOAM/OpenFOAM-7/platforms/linux64IccDPInt32OptINTELMPI/src/Pstream/mpi/
    pwd -P

What does the last command give you? Does it point to the '/manni/data/hej' path?


The other test is to run these commands:

    touch dummy:test1
    cd /manni/data/hej/OpenFOAM/OpenFOAM-7/platforms/linux64IccDPInt32OptINTELMPI/src/Pstream/mpi/
    touch dummy:test2

Does it create the two files "dummy:test1" and "dummy:test2" or just one or none of them?


Because my two doubts are:

1- If the filesystem really supports the colon symbol ':' or not.

2- If the only problem is that the 'wmakeMpiLib' needs to properly handle paths the same way as does 'wmake'.
(0010582)
paulmedwards   
2019-07-16 16:43   
@jherb Do you edit the FOAM_INST_DIR inside `OpenFOAM-7/etc/bashrc`?
(0010583)
jherb   
2019-07-16 16:55   
No, I did not change FOAM_INST_DIR in etc/bashrc. It is: /home/hej/OpenFOAM

The path /home/hej/OpenFOAM/OpenFOAM-7/platforms/linux64IccDPInt32OptINTELMPI/src/Pstream/mpi/ does not exist. What exists is:
/home/hej/OpenFOAM/OpenFOAM-7/platforms/linux64IccDPInt32OptINTELMPI/src/Pstream/
pwd -P inside it results in:
/manni/data/hej/OpenFOAM/OpenFOAM-7/platforms/linux64IccDPInt32OptINTELMPI/src/Pstream

If I create the mpi subfolder and cd into it I get:
> mkdir mpi
> cd /home/hej/OpenFOAM/OpenFOAM-7/platforms/linux64IccDPInt32OptINTELMPI/src/Pstream/mpi/
> pwd -P
/manni/data/hej/OpenFOAM/OpenFOAM-7/platforms/linux64IccDPInt32OptINTELMPI/src/Pstream/mpi

The touch commands created both files:
> ls
dummy:test1 dummy:test2
(0010584)
paulmedwards   
2019-07-16 17:42   
I don't understand why $HOME/$WM_PROJECT is used rather than $(cd $(dirname ${BASH_SOURCE:-$0})/../.. && pwd -P). Does anyone else understand this?
(0010585)
wyldckat   
2019-07-16 18:11   
@jherb: Many thanks, now I have a much clearer picture of what's going on. Although I'm wondering if you really need the two-step symbolic link (1st data, 2nd through local link)... why not only use one-step direct symbolic link?

@paulmedwards: That's only used if the first line fails. Notice the "||" near the end of the first line that handles finding the current real installation path. So if it fails, it goes for the default that OpenFOAM assumes for the past several years, if not since its inception.
(0010586)
paulmedwards   
2019-07-16 19:43   
@wyldckat: I understand the bash syntax but I don't see how it can be triggered as you need the export to return non-null, wouldn't you? E.g.

    export FOO=$(exit 1) || export FOO=bar

That still means than FOO is empty. Or, am I misunderstanding here?
(0010587)
wyldckat   
2019-07-16 22:30   
@paulmedwards: You're right, the '||' doesn't work in this case... Let me check, the original commit when that was started was this: https://github.com/OpenFOAM/OpenFOAM-dev/commit/4114a1e2bf85ec33024f51b230bb1cd7a97f6f32

Oh, right, I didn't look at the line before that, so for the current code in OpenFOAM-dev it's:

    [ "$BASH" -o "$ZSH_NAME" ] && \
    export FOAM_INST_DIR=$(cd $(dirname ${BASH_SOURCE:-$0})/../.. && pwd -P) || \
    export FOAM_INST_DIR=$HOME/$WM_PROJECT


The '||' is actually as a match for the '&&', namely that if it's not bash not zsh, then it uses the default path. If the 'pwd -P' fails for whatever reason, there is no proper fallback.

OK, I'm going to work on this right now and try to figure this out once and for all.
(0010588)
wyldckat   
2019-07-17 00:48   
Now I understand paulmedwards' comments on the default being "$HOME/$WM_PROJECT"... the symbolic path structure defined in jherb's installation has a real path "$HOME/OpenFOAM", but the rest is symbolic, therefore making 'pwd -P' a bit misleading, since it only checks how real is the '$FOAM_INST_DIR'.


Attached is a proof of concept of what technically the end result needs to be, although it's not the most elegant implementation and likely not the most popular solution.
The attached proposal files:

  - proposal_v3.patch - shows the changes made to the file 'etc/bashrc'.

  - bashrc_proposal_v3 - has the complete 'etc/bashrc', indexed to the commit mentioned in the patch file.

The proposal here is to always enforce the real paths, where the simplest approach was to change this directly at the initial sourcing of 'etc/bashrc', instead of hiding it within 'wmake', namely also enforcing the real paths for '$WM_PROJECT_DIR' and '$WM_THIRD_PARTY_DIR'.

The reasoning for this is as follows:

1- The critical issue with symbolic links is that we can easily end up on the real path, instead of the symbolic path. For example, I reproduced jherb's path as follows, at '/home/ofuser' in a virtual machine with Ubuntu 18.04:

     data -> /mnt/data/ofuser/
     OpenFOAM/OpenFOAM-dev -> /home/ofuser/data/OpenFOAM/OpenFOAM-dev/

2- Then one way we can easily end up on the real path is by running:

     cd ~/OpenFOAM/OpenFOAM-dev/
     source etc/bashrc

   And then open a new tab in the Gnome terminal. This will open the new tab into the folder '/mnt/data/ofuser/OpenFOAM/OpenFOAM-dev/'

3- If we then run automatically or manually:

     source ~/OpenFOAM/OpenFOAM-dev/etc/bashrc

4- ... the nightmare can begin as follows:

    1- Run a few build commands on the symbolic path.
    2- Run a few build commands on the real path.
    3- What we end up is with a messy build, if one at all, because the commands were executed in the wrong places.

This is vaguely how remember the 'pwd -P' requirement starting to appear.


Therefore, the only consistent way to ensure the build is done properly in either symbolic paths, or the real paths the symbolic ones point to, is to always reference the real paths.
AFAIK this doesn't hurt OpenFOAM's libraries and applications, because the binaries do not have a hard bind to the path into which they were linking into, given that they are dynamic.
The only issues I remember seeing popup in the past in this regard was with ParaView, Qt and Open-MPI, namely their custom builds, although some circumvention measures for this have been implemented into OpenFOAM's 'ThirdParty' folder, by re-basing after the build is complete for the respective build script.


@paulmedwards and @jherb: I don't know if you agree with this change to the 'etc/bashrc' file, but my main concern is whether the final build is then usable the way you want it to work, namely in a way that the installation is fully portable. I'll only be able to test this during the weekend, so if either one of you could test this sooner, it would speed up fixing this issue.

If this works properly, then a more elegant and consistent fix can be implemented.
(0010590)
jherb   
2019-07-17 08:55   
I tried it with only one link in /home/hej/OpenFOAM:
OpenFOAM-7 -> /manni/data/hej/OpenFOAM/OpenFOAM-7

(so no intermediate link)

The behavior is the same (broken) as before.
(0010591)
jherb   
2019-07-17 10:04   
I tried the above bashrc (after changing the OpenFOAM version from dev to 7)

It breaks the build, if started from within the OpenFOAM directory:
(my_root37) hej@manni:/manni/data/hej/OpenFOAM/OpenFOAM-7> ./Allwmake 2>&1 | tee ~/build-OpenFOAM-7-190717-02
Allwmake /manni/data/hej/OpenFOAM/OpenFOAM-7
make: Nothing to be done for `all'.
Allwmake /manni/data/hej/OpenFOAM/OpenFOAM-7
make: Nothing to be done for `all'.

If started from a subfolder (e.g. src or src/Pstream) it works
(0010592)
paulmedwards   
2019-07-17 10:08   
@wyldckat: ah - I missed that line before too! So, it uses $HOME/$WM_PROJECT because "$BASH" or "$ZSH_NAME" are not set? I am wondering why we have that check (and, why they aren't set) - especially since we ask to source *bashrc*.
@jherb: which shell are you using?
(0010593)
jherb   
2019-07-17 10:26   
GNU bash, version 3.2.57(2)-release (x86_64-suse-linux-gnu)
(0010594)
wyldckat   
2019-07-17 11:08   
@paulmedwards: Dash is the default shell in Ubuntu, hence one of the reasons as to why 'etc/bashrc' is working on this as safely as possible and since it's a minimal effort to support it. Furthermore, since in Ubuntu '/bin/sh' is Dash, a job scripts might use it and have to source 'etc/bashrc'.

@jherb: Many thanks and my apologies, I completely forgot to test it from the main folder. I'll try to re-check what's going on with it later today.
(0010595)
paulmedwards   
2019-07-17 11:10   
@jherb Is $BASH set? I'm guessing not...

What happens if you do the following:

export BASH=$(which bash)
source ~/OpenFOAM/OpenFOAM-7/etc/bashrc
echo $FOAM_INST_DIR

(and try building....)
(0010596)
paulmedwards   
2019-07-17 11:23   
@wyldckat Why not just check for dash as well and have the other condition as "echo 'Please source with bash/dash/zsh shell'"? Rather than just picking $HOME/OpenFOAM/. At the moment it won't work for dash if OpenFOAM is in a different location.
(0010598)
jherb   
2019-07-17 12:38   
BASH is set:
echo $BASH
/bin/bash
(0010599)
jherb   
2019-07-17 12:42   
I haven't tested it yet, but also the folders which contain user code which is build/linked against the installation of OpenFOAM might contain links
(0010600)
paulmedwards   
2019-07-17 12:43   
I still don't understand why "FOAM_INST_DIR=$HOME/$WM_PROJECT". As "$BASH" is not empty then it should not be set here:

    [ "$BASH" -o "$ZSH_NAME" ] && \
    export FOAM_INST_DIR=$(cd $(dirname ${BASH_SOURCE:-$0})/../.. && pwd -P) || \
    export FOAM_INST_DIR=$HOME/$WM_PROJECT

Does anyone understand this?
(0010601)
jherb   
2019-07-17 12:49   
This is the output of test:
> [ "$BASH" -o "$ZSH_NAME" ] && echo test
test
(0010602)
paulmedwards   
2019-07-17 12:51   
What is FOAM_INST_DIR set to?

@wyldkcat Can this be set anywhere else?
(0010603)
wyldckat   
2019-07-17 12:51   
@paulmedwards: The path in jherb's installation is a real path, namely:

    FOAM_INST_DIR=/home/hej/OpenFOAM

The problem is that it's '/home/hej/OpenFOAM/OpenFOAM-7' that is a symbolic link and 'etc/bashrc' doesn't check for that.
Namely:

     cd $(dirname ${BASH_SOURCE:-$0})/../..

equates to:

    /home/hej/OpenFOAM/OpenFOAM-7/etc/../..
    /home/hej/OpenFOAM
 
Therefore FOAM_INST_DIR will be the same path in this specific installation, regardless of the symbolic path or not for the subfolders, since '/home/hej/OpenFOAM' is a real path.

@jherb: You mentioned:

> folders which contain user code which is build/linked against the installation of OpenFOAM might contain links

Since there is a lot of information floating in this report, please provide a few more details (step-by-step if possible?), so that we can reproduce this. No hurry on my side, since I will only be able to look into this later tonight.
(0010604)
wyldckat   
2019-07-17 12:52   
@paulmedwards: There used to be a way for the use to pre-emptively set FOAM_INST_DIR or similar in the past... but that was replaced by the current mechanism, if I'm seeing things correctly.
(0010605)
paulmedwards   
2019-07-17 13:02   
thanks @wyldckat - I see now. That is confusing with symlinks in the OpenFOAM directory.
(0010606)
wyldckat   
2019-07-17 23:37   
OK, now I've revised and tested the changes into 'etc/bashrc' and it seemed to work as intended. I had made a critical mistake with a copy-paste and not correcting the 'cd' command for the 3rd party, which resulted in it going into '$WM_PROJECT_DIR' instead.
But that also revealed that if the 'ThirdParty-$WM_PROJECT_VERSION' folder doesn't exist, we should not try to 'cd' into it, since it will fail and risk landing it in the wrong place and breaking everything.

Anyway, please find in attached the following proposal files, also still experimental:

  - proposal_v4.patch - shows the changes made to the file 'etc/bashrc'.

  - bashrc_proposal_v4 - has the complete 'etc/bashrc', indexed to the commit mentioned in the patch file.

Even if the user runs the 'Allwmake' command from within the symbolic path, this mechanism will ensure that the real paths are always used.

I'm going to leave the build running overnight and tomorrow (Thursday) at night I'll test carrying the installation elsewhere, to see if it still works as intended or not, to test if there are problems with hard-coded paths.
(0010607)
wyldckat   
2019-07-17 23:39   
*this mechanism

I meant that with this environment definition, associated with the existing mechanism in 'wmake', will ensure things work as intended, namely to always respect the real path.
(0010608)
jherb   
2019-07-18 11:49   
@wyldckat: It looks like the latest bashrc (_v4) is working as expected.
(0010609)
wyldckat   
2019-07-18 12:08   
@jherb: Many thanks!

OK, then later tonight I'll try to test carrying the installation elsewhere, to see if it works as intended and if there are any problems if other users try to compile custom code and link to this transported build.
(0010611)
jherb   
2019-07-18 14:47   
Perhaps, I have found a new problem: If I build the whole of OpenFOAM, then go into src/Pstream and call ./Allwclean or execute wclean in the subfolders, then ./Allbuild (or wmake in the subfolders) does nothing. I have to remove the content of folder platforms/linux64IccDPInt32OptINTELMPI/src/Pstream/mpi/ to get those files rebuild

I also tried it in a different folder: src/TurbulenceModels/incompressible>
First wclean, then wmake and nothing is build
(0010612)
jherb   
2019-07-18 14:49   
This works as expected:
touch incompressibleTurbulenceModel.C
wmake
(it rebuilds those file and then links the corresponding library)
(0010613)
wyldckat   
2019-07-18 23:23   
@jherb: Good catch! The missing detail was that 'wclean' needed the same changes that were done in 'wmake', namely the real patch check. Attached are the following files:

 - wclean_proposal_v5 - the updated 'wclean' file
 - proposal_v5.patch - the updated proposal patch, including both 'bashrc' and 'wclean'

I'll have to postpone to tomorrow night the test regarding moving the installation to another VM.
(0010614)
jherb   
2019-07-19 10:03   
@wyldckat: If I search for similar lines in the wmake folder, I find another file (wrmdep):

updateMode)

    if [ "$PWD" != "$WM_PROJECT_DIR" ]
    then
        echo "Cannot 'update', not in the project top-level directory"
        exit 1
    fi

I am not sure, what this file is for at all, but this if clause might also be a problem if $PWD includes the link and $WM_PROJECT_DIR now is set to the "real" path. Perhaps it would help if the error message contains the values of the two shell variables.

And another question back to my original problem with compiling/linking against the Intel MPI libraries:
It now works with this change (and setting the environment variable MPI_ARCH_PATH):
diff --git a/wmake/rules/General/mplibINTELMPI64 b/wmake/rules/General/mplibINTELMPI64
index 278e0b0..9023547 100644
--- a/wmake/rules/General/mplibINTELMPI64
+++ b/wmake/rules/General/mplibINTELMPI64
@@ -1,3 +1,3 @@
 PFLAGS = -DMPICH_SKIP_MPICXX
-PINC = -isystem $(MPI_ARCH_PATH)/include64
-PLIBS = -L$(MPI_ARCH_PATH)/lib64 -lmpi
+PINC = -isystem $(MPI_ARCH_PATH)/include -isystem $(MPI_ARCH_PATH)/include64
+PLIBS = -L$(MPI_ARCH_PATH)/lib64 -L$(MPI_ARCH_PATH)/lib -lmpi

I searched for any information, if the Intel compiler accepts two -isystem arguments (it looks like it does) but I haven't found any.
(0010622)
henry   
2019-07-19 15:50   
@jherb why do you need -isystem $(MPI_ARCH_PATH)/include and -isystem $(MPI_ARCH_PATH)/include64 what files are in these two directories?

I have just installed icpc-19 to test and have the Intel MPI libraries but the header files are nowhere to be found so I can't test it or check the include directories.
(0010623)
henry   
2019-07-19 16:01   
Note that the location of the Intel mpi.h file has changed between versions 17 and 19: https://bugs.openfoam.org/view.php?id=3043
I am not sure where it is in version 18 but it is likely that you need either -isystem $(MPI_ARCH_PATH)/include or -isystem $(MPI_ARCH_PATH)/include64 but not both and having both might cause problems if you have both a 32bit 64bit installation if that is an option.
(0010625)
jherb   
2019-07-19 20:00   
@henry: Yes, of course, you are right: Only one of the include (and one of the lib) folders is need. I just thought, that this might the fix the problem for everybody. But of course, I can always patch my installation, if you do not want to change this.
(0010626)
henry   
2019-07-19 20:30   
(Last edited: 2019-07-19 20:36)
@jherb I think it would be best to set the default paths to correspond to the latest release from Intel, could you confirm what those paths are? I only have the libraries and not the headers so I don't know where they will be in this release.

I think

PINC = -isystem $(MPI_ARCH_PATH)/include
PLIBS = -L$(MPI_ARCH_PATH)/lib -lmpi

should work for 17, 18 and 19

(0010627)
jherb   
2019-07-19 21:57   
Intel MPI including the SDK is free for some time now:
https://software.intel.com/en-us/mpi-library/choose-download
https://software.intel.com/en-us/mpi-library/choose-download/linux

I just installed them:
The folders are named
~/intel/compilers_and_libraries/linux/mpi/intel64$ ls
bin etc include lib libfabric modulefiles
(0010629)
wyldckat   
2019-07-22 01:46   
@jherb: Many thanks for picking up on the change needed for 'wrmdep'. This script is used for removing the dependency files '.dep', which in turn provide a list of files on which each '.C' file depends on, so that 'make' can more easily figure out if a '.C' file needs to be rebuilt after something is changed in those dependencies. The relevant section that uses '$PWD' is for cleaning up '.dep' files and symbolic links for files that were removed, usually after a 'git pull' in OpenFOAM-dev.


I've tested moving the installation to another folder and compiling custom code at either locations. All tests ran just fine (running the tutorials 'incompressible/simpleFoam/pipeCyclic' and 'mesh/refineMesh/refineFieldDirs' that test two types of custom code) and OpenFOAM was pretty much portable.
Although I haven't tested if ParaView would be portable enough... but I'm guessing that isn't as important either way for cluster deployments, but if it's not working then it's a topic of its own report.


@henry: Please find in attachment the following files:

 - proposal_v6.patch - shows the changes made in the files in the tarball
 - proposal_v6.tar.gz - provides the modified files on OpenFOAM-dev, namely:

    - etc/bashrc
    - wmake/wclean
    - wmake/wrmdep

I don't like having the 2 big chunks of new code in 'etc/bashrc', but the only way to clean it up requires using a local shell function, which I'll only be able to look into this Monday or Tuesday night.
Having the local shell function will remove the duplicate code, but it won't reduce the line count all that much, so I'll leave it up to you on whether if it's worth to wait for the local shell function or not.
(0010637)
henry   
2019-07-22 14:41   
@bruno thanks for the patch, I have just applied it:

commit 94642ba4d9a216c0d25ca9c65b8a0a946f0879db

I agree that avoiding the code duplication by introducing a shell function does not provide sufficient benefit for the additional complexity given the poor handling of function arguments in bash.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3312 [OpenFOAM] Bug block always 2019-07-22 18:04 2019-07-23 22:48
Reporter: cjc96 Platform: Linux  
Assigned To: chris OS: Fedora  
Priority: normal OS Version: 30  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Cannot Launch 'openfoam7-linux' in Docker
Description: Similar to Issue 0002646 (https://bugs.openfoam.org/view.php?id=2646)

- OpenFOAM 7 installed as per the official guide (https://openfoam.org/download/7-linux/)

- Unable to launch openfoam7-linux
- - Receive the following error: /bin/sh: 1: /entry.sh: Permission denied
Tags:
Steps To Reproduce: - Follow official installation guide up to Step 5
- issue 'openfoam7-linux' command
Additional Information: - Deletion of container/image had no impact
- Re-installation of Docker had no impact
- Command successful when issued as su (leads to issues downstream however)
System Description
Attached Files:
Notes
(0010640)
wyldckat   
2019-07-23 12:57   
Pinging @chris and @will: I don't know for certain which one of you took care of the latest 'openfoam7-linux' docker container?
(0010641)
chris   
2019-07-23 16:00   
I think this is fixed now.
@cjc96 please can you test it is OK.
You need to delete the original container as described in the report when this happened previously:
https://bugs.openfoam.org/view.php?id=2646
(0010644)
cjc96   
2019-07-23 22:21   
Sorry for the delay in getting back to you,

Everything seems to be working as intended now,

Thanks guys


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3308 [OpenFOAM] Patch minor always 2019-07-18 12:01 2019-07-23 16:48
Reporter: handrake0724 Platform: x86_64  
Assigned To: henry OS: Arch  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: generalize sixDoFRigidBodyState functionObject
Description: I found that sixDoFRigidBodyState is coupled with sixDoFRigidBodyMotionSolver.
If I want to use only sixDoFRigidBodyMotion class and develop a new motionsolver class like solid body motion,
I have to rewrite another sixDoFRigidBodyState functionObject with almost same code.
It just work with modifying the following statement in sixDoFRigidBodyState::motion()

     const sixDoFRigidBodyMotionSolver& motionSolver_ =
         refCast<const sixDoFRigidBodyMotionSolver>(mesh.motion());

 into
     const sixDoFRigidBodyMotionSolver& motionSolver_