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:12https://bugs.openfoam.org/file_download.php?file_id=3078&type=bug
 There are no notes attached to this issue.

 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: "" (ID , group ID ) 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:57https://bugs.openfoam.org/file_download.php?file_id=3067&type=bugpatch-2.diff (561 bytes) 2020-10-13 07:59https://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 Description: When using DimensionedField, there is compiling error: no matching function for call to ‘T(const Foam::Field >&, const Foam::Field >&)’ 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 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 void T(Field& res, const UList& f); However, the member function T() of the class dimensionedField is defined as: template tmp> DimensionedField::T() const { tmp> result ( DimensionedField::New ( name() + ".T()", mesh_, dimensions_ ) ); Foam::T(result(), *this); return result; } where the operator() of the tmp 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:37https://bugs.openfoam.org/file_download.php?file_id=3062&type=bugcontrolDict (3,615 bytes) 2020-09-27 19:27https://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 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 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:29https://bugs.openfoam.org/file_download.php?file_id=3060&type=bugsemiPermeableBaffleMassFractionFvPatchScalarField.H (6,727 bytes) 2020-09-23 10:29https://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:24https://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 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::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::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 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:29https://bugs.openfoam.org/file_download.php?file_id=3058&type=bugcorrecting_options_v1.tar.gz (503 bytes) 2020-09-22 16:29https://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:12https://bugs.openfoam.org/file_download.php?file_id=3054&type=bugchannel_structured_curved_inlet_stepsine_flow_into_domain.7z (427,218 bytes) 2020-09-20 04:13https://bugs.openfoam.org/file_download.php?file_id=3055&type=bugchannel_structured_step_sine.7z (122,507 bytes) 2020-09-20 04:13https://bugs.openfoam.org/file_download.php?file_id=3056&type=bugchannel_unstructured_stepsine.7z (1,768,103 bytes) 2020-09-20 04:13https://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:29https://bugs.openfoam.org/file_download.php?file_id=3052&type=bugwmkdep.l (12,169 bytes) 2020-09-18 13:29https://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("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:15https://bugs.openfoam.org/file_download.php?file_id=3050&type=bugTimeIO.C (14,742 bytes) 2020-09-18 13:15https://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:13https://bugs.openfoam.org/file_download.php?file_id=3032&type=bugbug3546_valueFractionFix.diff (3,967 bytes) 2020-09-11 12:28https://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&, Foam::UList const&, Foam::UList const&) at ??:? [1] #4 Foam::tmp > Foam::operator/(Foam::tmp > const&, Foam::GeometricField const&) at ??:? [1] #5 Foam::kOmegaSST > > > >, Foam::EddyDiffusivity > > >::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:34https://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 v_std = {1, 10, 3, 5}; DynamicList 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:13https://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 a reverse iterator /// with ++ and -- operators shifting to left and right, respectively. /// template std::reverse_iterator make_reverse(InputIt i){ return std::reverse_iterator(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 reverse_iterator; //new one and implemeting the functions as: template inline typename Foam::UList::reverse_iterator Foam::UList::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_reverse_iterator; template inline typename Foam::UList::const_reverse_iterator Foam::UList::crbegin() const { return const_reverse_iterator(cend()); } template inline typename Foam::UList::const_reverse_iterator Foam::UList::crend() const { return const_reverse_iterator(cbegin()); } template inline typename Foam::UList::const_reverse_iterator Foam::UList::rbegin() const { return const_reverse_iterator(cend()); } template inline typename Foam::UList::const_reverse_iterator Foam::UList::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 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; --> compressible::thermalBaffle1D; - Cp --> Cv - bonus: add an entry for value to 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 to compressible::thermalBaffle1D 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 {""} {offset } {font "{,}"} {{textcolor | tc} {lt | default}} {{no}enhanced} value should be used with offset keyword but in the code, 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.

 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 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 /intel/20.0/impi/yyyy.xx.xxx It now should point to: /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: 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:59https://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= 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:34https://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:05https://bugs.openfoam.org/file_download.php?file_id=2751&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.

 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:11https://bugs.openfoam.org/file_download.php?file_id=2982&type=bugdev-20200508.png (105,001 bytes) 2020-06-02 23:11https://bugs.openfoam.org/file_download.php?file_id=2983&type=bugdev-20200531.png (130,449 bytes) 2020-06-02 23:11https://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:28https://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.

 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:32https://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());         reduce(sumLengthAlpha, sumOp()); 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:42https://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:56https://bugs.openfoam.org/file_download.php?file_id=2956&type=bugwedgeExtrude.tar-2.gz (3,415 bytes) 2020-04-21 22:10https://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 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:47https://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 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::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:53https://bugs.openfoam.org/file_download.php?file_id=2951&type=bugtypos.diff (6,545 bytes) 2020-04-09 05:52https://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

 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:31https://bugs.openfoam.org/file_download.php?file_id=2917&type=bugmeshToMesh0_updateCurCell.patch (1,083 bytes) 2020-02-20 10:31https://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.

 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

 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:25https://bugs.openfoam.org/file_download.php?file_id=2922&type=bug

 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:09https://bugs.openfoam.org/file_download.php?file_id=2916&type=bugCD_NOZ_3D_rtpef_BNL_291_lam_cse8_TP_oldcase_pWAL_dev_bc_test-2.zip (1,846,985 bytes) 2020-02-21 14:56https://bugs.openfoam.org/file_download.php?file_id=2919&type=bugCD_NOZ_3D_rtpef_BNL_291_lam_cse8_TP_oldcase_pWAL_dev_bc_test-3.zip (1,808,929 bytes) 2020-02-21 16:25https://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 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:09https://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 · 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:00https://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:09https://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 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:17https://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 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:

 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> 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:27https://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:25https://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 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:17https://bugs.openfoam.org/file_download.php?file_id=2884&type=buglog.setFields (1,306 bytes) 2020-01-24 14:17https://bugs.openfoam.org/file_download.php?file_id=2885&type=bugT (2,678 bytes) 2020-01-24 14:17https://bugs.openfoam.org/file_download.php?file_id=2886&type=buglog.make (13,000 bytes) 2020-01-24 18:10https://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:53https://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 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&) ... /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, | ~~~~~~~~~~~~~^~~~~~~~~ /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:41https://bugs.openfoam.org/file_download.php?file_id=2879&type=bug
 Notes (0011068) henry    2020-01-15 12:08 commit 2771c1f85c267e9925c2796b52b3ae010fae6179 Author: Henry Weller 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: 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:17https://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:01https://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 $PWDis 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:43https://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 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:58https://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:39https://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:57https://bugs.openfoam.org/file_download.php?file_id=2832&type=bugcomparison_old_new_coeffs.png (56,168 bytes) 2019-11-18 12:57https://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:25https://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&, Foam::UList const&) at ??:? #6 Foam::sinh(Foam::tmp > const&) at ??:? #7 Foam::waveModels::Airy::vi(int, double, Foam::Field > const&) const at ??:? #8 Foam::waveModels::Airy::velocity(double, Foam::Field > const&) const at ??:? #9 Foam::waveSuperposition::velocity(double, Foam::Field > const&) const at ??:? #10 Foam::waveSuperposition::UGas(double, Foam::Field > 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&, Foam::UList const&) at ??:? #6 Foam::exp(Foam::UList const&) at ??:? #7 Foam::waveModels::Airy::vi(int, double, Foam::Field > const&) const at ??:? #8 Foam::waveModels::Airy::velocity(double, Foam::Field > const&) const at ??:? #9 Foam::waveSuperposition::velocity(double, Foam::Field > const&) const at ??:? #10 Foam::waveSuperposition::UGas(double, Foam::Field > 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:13https://bugs.openfoam.org/file_download.php?file_id=2836&type=bugISAT_statistics_new.png (1,682,601 bytes) 2019-11-21 12:46https://bugs.openfoam.org/file_download.php?file_id=2837&type=bugISAT_statistics_old.png (1,726,831 bytes) 2019-11-21 12:46https://bugs.openfoam.org/file_download.php?file_id=2838&type=bugISAT.patch (2,501 bytes) 2019-11-21 12:46https://bugs.openfoam.org/file_download.php?file_id=2839&type=bugprintCPUT.py (10,721 bytes) 2019-11-21 12:46https://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:27https://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 void Foam::combustionModels::laminar::correct() { if (this->active()) { if (integrateReactionRate_) { //some codes } else { this->chemistryPtr_->calculate(); } } } //openfoam7 template void Foam::combustionModels::laminar::correct() { if (integrateReactionRate_) { //some codes } } //suggested template void Foam::combustionModels::laminar::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:12https://bugs.openfoam.org/file_download.php?file_id=2794&type=bugsnappyBugReportRoom.tgz (4,846 bytes) 2019-10-07 11:12https://bugs.openfoam.org/file_download.php?file_id=2795&type=bugsnappyHexMeshM.C (46,072 bytes) 2019-10-08 09:08https://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 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(Foam::Field const&, Foam::Field > const&, Foam::Field const&) const at ??:? #4 double Foam::functionObjects::fieldValues::surfaceFieldValue::processValues(Foam::Field const&, Foam::Field > const&, Foam::Field const&) const at ??:? #5 bool Foam::functionObjects::fieldValues::surfaceFieldValue::writeValues(Foam::word const&, Foam::Field 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 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:01https://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 >&) const at ??:? #4 Foam::blockDescriptor::correctFacePoints(Foam::FixedList >, 6u>&) const at ??:? #5 Foam::block::createPoints() at ??:? #6 Foam::block::block(Foam::dictionary const&, int, Foam::Field > const&, Foam::PtrList const&, Foam::PtrList const&, Foam::Istream&) at ??:? #7 Foam::block::New(Foam::dictionary const&, int, Foam::Field > const&, Foam::PtrList const&, Foam::PtrList const&, Foam::Istream&) at ??:? #8 void Foam::PtrList::read(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:27https://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 . # # 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 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

 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

 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:00https://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:45https://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:14https://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:07https://bugs.openfoam.org/file_download.php?file_id=2803&type=bugfreeDecayingCylinder.tar.gz (3,661 bytes) 2019-10-09 14:07https://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:19https://bugs.openfoam.org/file_download.php?file_id=2712&type=bugupdated_Age_functionObject.tgz (3,308 bytes) 2019-07-14 21:49https://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:09https://bugs.openfoam.org/file_download.php?file_id=2786&type=bugpatch.diff (17,781 bytes) 2019-10-02 16:04https://bugs.openfoam.org/file_download.php?file_id=2788&type=bugreverseRamp.tar.gz (1,549 bytes) 2019-10-02 19:22https://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 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(Foam::Field&, double const&, Foam::geometricOneField const&, Foam::GeometricField const&, Foam::GeometricField const&, Foam::GeometricField 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 const&, Foam::geometricOneField const&, Foam::GeometricField const&, Foam::GeometricField const&, Foam::GeometricField&, 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:13https://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:31https://bugs.openfoam.org/file_download.php?file_id=2787&type=bug

 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:17https://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:31https://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:39https://bugs.openfoam.org/file_download.php?file_id=2770&type=bugblockMeshDict (40,046 bytes) 2019-09-17 09:39https://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 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: 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:34https://bugs.openfoam.org/file_download.php?file_id=2752&type=bugproposal_v1.patch (1,486 bytes) 2019-08-24 17:34https://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:20https://bugs.openfoam.org/file_download.php?file_id=2748&type=bugof6.png (12,156 bytes) 2019-08-22 11:20https://bugs.openfoam.org/file_download.php?file_id=2749&type=bugof7.png (33,028 bytes) 2019-08-22 11:20https://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:13https://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:22https://bugs.openfoam.org/file_download.php?file_id=2745&type=bug
 Notes (0010678) henry    2019-08-19 09:47 Resolved by commit 6736543e3a61fd2c3cbc3ce64525ae63f2b1aad2

 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:15https://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::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::Ostream&, Foam::errorManip) in "/home/jheylmun/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Debug/bin/interFoam" #3 Foam::UList::checkIndex(int) const in "/home/jheylmun/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Debug/bin/interFoam" #4 Foam::UList::operator[](int) const in "/home/jheylmun/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Debug/bin/interFoam" #5 Foam::Field::doMap(Foam::UList const&, Foam::List > const&, Foam::List > const&) at ~/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/Field.C:327 (discriminator 2) #6 Foam::Field::map(Foam::UList const&, Foam::List > const&, Foam::List > const&) at ~/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/Field.C:355 #7 void Foam::generalFieldMapper::map(Foam::Field&, Foam::Field const&) const at ~/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/fields/Fields/fieldMappers/generalFieldMapper/generalFieldMapperTemplates.C:59 #8 Foam::generalFieldMapper::operator()(Foam::Field&, Foam::Field const&) const at ~/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/fields/Fields/fieldMappers/generalFieldMapper/generalFieldMapper.C:69 #9 Foam::MapInternalField::operator()(Foam::Field&, Foam::fvMeshMapper const&) const at ~/OpenFOAM/OpenFOAM-dev/src/finiteVolume/lnInclude/MapFvVolField.H:73 #10 void Foam::MapGeometricFields(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 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:48https://bugs.openfoam.org/file_download.php?file_id=2714&type=bugproposal_v3.patch (1,031 bytes) 2019-07-17 00:48https://bugs.openfoam.org/file_download.php?file_id=2715&type=bugbashrc_proposal_v4 (7,566 bytes) 2019-07-17 23:37https://bugs.openfoam.org/file_download.php?file_id=2716&type=bugproposal_v4.patch (1,622 bytes) 2019-07-17 23:37https://bugs.openfoam.org/file_download.php?file_id=2717&type=bugproposal_v5.patch (2,639 bytes) 2019-07-18 23:23https://bugs.openfoam.org/file_download.php?file_id=2719&type=bugwclean_proposal_v5 (8,946 bytes) 2019-07-18 23:23https://bugs.openfoam.org/file_download.php?file_id=2720&type=bugproposal_v6.patch (3,670 bytes) 2019-07-22 01:46https://bugs.openfoam.org/file_download.php?file_id=2727&type=bugproposal_v6.tar.gz (6,231 bytes) 2019-07-22 01:46https://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' do