View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4071	[OpenFOAM] Bug	major	always	2024-04-12 09:35	2024-04-14 13:58
Reporter:	nguyenhung97	Platform:	GNU/Linux
Assigned To:		OS:	Ubuntu
Priority:	high	OS Version:	22.04.3 LTS
Status:	new	Product Version:	dev
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	number of injected parcels is wrong in patchInjection
Description:	In the tutorial TJunction ($FOAM_TUTORIALS/incompressibleFluid/TJunction), when I changed the duration to 1s and SOI to 0.5, I expected the number of parcels injected is 1000 (since parcelsPerSecond is set to 1000) but the actual result is 500. However, it works normally when the SOI is set to 0 so I think the codes is not dealing with time relative to SOI.
Tags:
Steps To Reproduce:	In the tutorial TJunction ($FOAM_TUTORIALS/incompressibleFluid/TJunction), 1. Changed the duration to 1s and SOI to 0.5. 2. Run Allrun.sh
Additional Information:
Attached Files:

Notes
(0013227) nguyenhung97    2024-04-12 09:41	And also it does not inject anything if I set deltaT to small value (1e-5)
(0013228) will    2024-04-12 21:51	I can't reproduce the SOI issue. What commit of dev do you have? The output should have something that looks like "Build : dev-e7ca51c06555" in it. Or just upload a log. The small time-step issue I can see. PatchInjection has a strange randomised implementation of nParcelsToInject which, as you rightly point out, seems to generate zeros if the time interval is too small. Other injectors (e.g., cone injection) do not seem to have this problem, so the problem can probably be fixed by copying the code across. I'll try next week. I need to figure out whether the patch injection's nParcelsToInject process has any merit or whether I can just replace it with the cone injector's version.
(0013229) nguyenhung97    2024-04-14 13:58	I tested with the latest dev version and it worked fine with SOI issue. FYI, I tested with OpenFOAM v10 and it worked for small time-step.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4067	[OpenFOAM] Bug	minor	always	2024-03-26 02:04	2024-03-27 19:55
Reporter:	blackk100	Platform:	GNU/Linux WSL2
Assigned To:		OS:	Ubuntu
Priority:	normal	OS Version:	22.04
Status:	new	Product Version:	11
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Cleaned PATH eats up valid paths
Description:	foamCleanPath considers whitespaces and colons as valid field separators, although Linux only specifies colons for splitting the actual paths (at least according to this https://www.linfo.org/path_env_var.html). This is especially an issue on WSL 2 as Windows appends its own PATH when installing the OS (in the form of /mnt/c/Program Files/...). This results in the user being unable to call Windows executables from the WSL OS (such as VS Code or explorer.exe).
Tags:
Steps To Reproduce:	Source etc/bashrc
Additional Information:	This can be fixed easily if a copy of the PATH variable is made before souring etc/bashrc: win_path=$(sed "s|^$(sed "s|:/mnt.*$||g" <<< $PATH)||g" <<< $PATH) . /opt/openfoam11/etc/bashrc export PATH=$(sed "s|:/mnt.*$|$win_path|g" <<< $PATH) unset win_path
System Description	Running on WSL2 (Windows 11 23H2)
Attached Files:

Notes
(0013219) blackk100    2024-03-27 19:55	This is an update to the workaround to deal with regex metacharacters in the PATH. This also assumes that the first mount point in the PATH is located after any OpenFOAM paths, and is run in bash. path_wsl=$(sed 's|:/mnt.*||' <<< $PATH) path_wsl=$(sed -e 's|\^|\\\^|g' -e 's|\$|\\\$|g' -e 's|\*|\\\*|g' -e 's|\+|\\\+|g' -e 's|\?|\\\?|g' -e 's|\.|\\\.|g' <<< $path_wsl) path_win=$(sed "s|^$path_wsl||" <<< $PATH) . /opt/openfoam11/etc/bashrc path_wsl=$(sed 's|:/mnt.*||' <<< $PATH) export PATH="$path_wsl$path_win" unset path_wsl path_win

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4066	[OpenFOAM] Bug	crash	always	2024-03-25 08:51	2024-03-26 12:21
Reporter:	saklep	Platform:	GNU/Linux
Assigned To:	will	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:	compressibleVoF freezes when using fvModel massSource in parallel
Description:	Solver compressibleVoF freezes on first timestep when using fvModel massSource. Crash happens in parallel running with apparently any decomposition method. Works normally when not running in parallel.
Tags:
Steps To Reproduce:	Run tutorial case compressibleVoF/damBreakInjection in parallel. Alternatively set up some other parallel compressibleVoF case with fvModel massSource.
Additional Information:	Tested on Ubuntu 20.04 and RHEL CentOS 7, kernel 3.10.0-1062.
System Description
Attached Files:

Notes
(0013218) will    2024-03-26 12:21	Thanks for the report. Fixed here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/49b0069df0fb98e61571df4a761c57e874064fab

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4057	[OpenFOAM] Bug	crash	always	2024-02-23 14:14	2024-03-26 01:34
Reporter:	Ulrich	Platform:	Linux
Assigned To:		OS:	Ubuntu
Priority:	normal	OS Version:	22.04 LTS
Status:	new	Product Version:	11
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	ParaFoam does not start
Description:	The Ubuntu Linux is installed on WSL 2, Windows 10 OpenFOAM 11 is installed according to the following instruction: https://openfoam.org/download/windows/ When launching paraFoam in OpenFOAM 11 environment in the pitzDailySteady test case no window opens but the following message appears: qt.qpa.xcb: could not connect to display 172.24.192.1:0 qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb. I tried to change DISPLAY to "export DISPLAY=:0" but then a segmentation fault with the attached error message occours.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	paraFoam.zip (7,920 bytes) 2024-02-23 14:14 https://bugs.openfoam.org/file_download.php?file_id=3488&type=bug

Notes
(0013201) Ulrich    2024-02-24 14:37	Today I installed the standard paraview with:     sudo apt-get update     sudo apt-get -y install paraview With DISPLAY=:0 it opens without problems. But with DISPLAY=172.24.192.1:0 as set by echo "export DISPLAY=$(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null):0" >> ${HOME}/.bashrc it again gives the following message:     qt.qpa.xcb: could not connect to display 172.24.192.1:0     qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.     This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.     Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.     Aborted Setting display back to DISPLAY=:0 and loading openfoam environment with source /opt/openfoam11/etc/bashrc then starting paraview again gives the segmentation fault documented in the attached paraFoam.zip. I've got the impression that something with the openfoam environment does not fit in my system.
(0013217) blackk100    2024-03-26 01:34	Setting ParaView_GL=system or ParaView_GL="" fixes this on my install (OpenFOAM-11 in Ubuntu 22.04 on WSL2 Windows 11 23H2). Seems to be due to an older fix due to a rendering bug in ParaView. The variable itself is defined in etc/config.sh/paraview (https://github.com/OpenFOAM/OpenFOAM-11/blob/71b07bb46985607e3b78e9404e8b5129989de411/etc/config.sh/paraview#L69). Installing Mesa drivers (mesa-va-drivers) did not help.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4064	[OpenFOAM] Bug	minor	always	2024-03-15 12:50	2024-03-15 15:05
Reporter:	Apanasevich	Platform:	amd64
Assigned To:	will	OS:	Rocky Linux
Priority:	normal	OS Version:	8.6
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Module functions: typo in key "subSolver" leads to an endless loop
Description:	Typo in key "subSolver" (e.g. "subsolver") in controlDict causes an endless loop at the simulation start and the simulation aborts immediately. A test case with multiphaseFlow and functions is attached: s. the log file
Tags:
Steps To Reproduce:	Run the attached test case
Additional Information:
System Description	HPC Cluster
Attached Files:	bubbleColumn_functions_bug.zip (306,511 bytes) 2024-03-15 12:50 https://bugs.openfoam.org/file_download.php?file_id=3500&type=bug

Notes
(0013213) henry    2024-03-15 13:55	This is due to the need to default to reading the "solver" name in the post-processing context:     // Read the solverName from the subSolver or solver entry in controlDict     const word solverName     (         runTime.controlDict().found("subSolver")       ? runTime.controlDict().lookup("subSolver")       : runTime.controlDict().lookup("solver")     ); The only way around this would be to check for all the different ways that "subSolver" might be incorrectly spelled by the user.
(0013215) wyldckat    2024-03-15 14:38	The following is not ideal, but at least it follows most of OpenFOAM's convention of exiting when something essential isn't found:     if (!runTime.controlDict().found("subSolver") && !runTime.controlDict().found("solver"))     {         FatalError...     }     // Read the solverName from the subSolver or solver entry in controlDict     const word solverName     (         runTime.controlDict().found("subSolver")       ? runTime.controlDict().lookup("subSolver")       : runTime.controlDict().lookup("solver")     );
(0013216) will    2024-03-15 15:05	Fixed in dev by https://github.com/OpenFOAM/OpenFOAM-dev/commit/d8df5789203b9e0320bc298879afc35e1a679d26

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4065	[OpenFOAM] Bug	major	always	2024-03-15 13:26	2024-03-15 14:33
Reporter:	LOLO2000	Platform:	Unix
Assigned To:		OS:	Other
Priority:	immediate	OS Version:	13.4.1
Status:	new	Product Version:	11
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Followed the installation but something is missing
Description:	I have followed this web page: https://openfoam.org/download/11-macos/ up to step 6. The shell script 'openfoam11-macos' is on my machine and executable; but when I try to launch a docker container, the shell script runs and, with any option but '-h' I simply get the message 'No directory exists:' It's as if there is something that should have happened or that there is something I should have not done which is not clear from the web-page. I have Openfoam10 running, installed the same way, and that launches a docker container each time. My machine is an M1 Mac
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0013214) wyldckat    2024-03-15 14:33	Please try using the script "openfoam10-macos_modified" that is provided in issue 4062: https://bugs.openfoam.org/view.php?id=4062 Given that MacOS is a closed operating system available only for specific (closed) hardware, this script can only be maintained by people who have access to it.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4062	[OpenFOAM] Bug	minor	always	2024-03-06 16:20	2024-03-15 14:33
Reporter:	Ulrich	Platform:	Macintosh
Assigned To:		OS:	macOS Sonoma
Priority:	normal	OS Version:	14.2.1
Status:	new	Product Version:	10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	openfoam10-macos needs modification to run
Description:	Lines 92, 143, 144 and 202 need to be modified to run openfoam 10 on my system. Please see attached files. The same applies for openfoam 11. The files system of my computer is not case sensitive. I created a case sensitive openfoam folder.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	openfoam10-macos_modified (6,846 bytes) 2024-03-06 16:20 https://bugs.openfoam.org/file_download.php?file_id=3496&type=bug openfoam10-macos_original (6,844 bytes) 2024-03-06 16:20 https://bugs.openfoam.org/file_download.php?file_id=3497&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4063	[OpenFOAM] Bug	minor	always	2024-03-08 19:32	2024-03-12 12:26
Reporter:	joaquin	Platform:	GNU/Linux
Assigned To:	will	OS:	Ubuntu
Priority:	normal	OS Version:	15.04
Status:	resolved	Product Version:	11
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Sign error in Pilch-Erdman breakup model
Description:	There is a typo in the original paper, as pointed out in: Guildenbecher et al. Secondary atomization. Exp Fluids (2009) 46:371–402, pp. 389 In PilchErdman.C, line 118: taubBar = 14.1*pow(We - 12.0, 0.25); the correct equation is: taubBar = 14.1*pow(We - 12.0, -0.25);
Tags:
Steps To Reproduce:	not applicable
Additional Information:	not applicable
System Description
Attached Files:	Guildenbecher_bug4063.pdf (177,280 bytes) 2024-03-12 08:54 https://bugs.openfoam.org/file_download.php?file_id=3498&type=bug Pilch-Erdman_bug4063.pdf (44,306 bytes) 2024-03-12 08:54 https://bugs.openfoam.org/file_download.php?file_id=3499&type=bug

Notes
(0013209) will    2024-03-12 08:54    (Last edited: 2024-03-12 08:55)	There is a difference in the published equations, yes. Snippets of the references are attached. It is not clear to me, which of Pilch-Erdman eq10 and Guildenbecher eq33 are correct. Can you elaborate on why you consider Guildenbecher to be correct? Guildenbecher's does state a correction to Pilch-Erdman, but this relates to a different equation; i.e., Pilch-Erdman eq13 and Guildenbecher eq34 (also in attched). This equation does not appear in the implementation, however, so there is no issue with this difference.
(0013210) cgoessni    2024-03-12 11:04	If one uses OP's correction, the function for taubBar becomes continuous in We: original Pilch-Erdman: T(45-) = 5.87 T(45+) = 33.79 T(351-) = 60.50 T(351+) = 3.29 new Guildenbecher: T_tot(45-) = 5.87 T_tot(45+) = 5.88 T_tot(351-) = 3.29 T_tot(351+) = 3.29
(0013211) will    2024-03-12 12:23	OK, yes. I see. Good point. And only the changed function matches the graphs in the original reference. Thanks. Fixed in dev: https://github.com/OpenFOAM/OpenFOAM-dev/commit/d9cb93897ac2c829a319378374e0ac523be5ce9c
(0013212) will    2024-03-12 12:26	And v11. https://github.com/OpenFOAM/OpenFOAM-11/commit/71b07bb46985607e3b78e9404e8b5129989de411

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4061	[OpenFOAM] Bug	minor	always	2024-03-05 13:31	2024-03-06 11:16
Reporter:	Luca Cornolti	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:	11
		Target Version:
Summary:	Error in implementation of Langmuir-Hinshelwood reaction rate derivative with respect to molar concentration
Description:	Line 155 in file LangmuirHinshelwoodReactionRateI.H (last operation in function Foam::LangmuirHinshelwoodReactionRate::ddc): ddc[r_[1]] = - k*m_[1]/b*dbdc2; should be replaced with: ddc[r_[1]] = - k*m_[0]/b*dbdc2; See analytic derivation for this kind of reaction rate (equation 9 in attached pdf file) where I tried to use the same nomenclature used in the code.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	LangmuirHinshelwood_reactionRate.pdf (35,726 bytes) 2024-03-05 13:31 https://bugs.openfoam.org/file_download.php?file_id=3495&type=bug

Notes
(0013208) will    2024-03-06 11:16	Agreed. Thanks for the report. Fixed in dev and in v11. https://github.com/OpenFOAM/OpenFOAM-11/commit/bf2b19e50a437442ed18c346e22ae6e865af11ab https://github.com/OpenFOAM/OpenFOAM-dev/commit/734df1c370e090c9fd0ba423d5a8dc301453c70a

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4060	[OpenFOAM] Bug	minor	always	2024-02-29 21:41	2024-02-29 21:41
Reporter:	mcrock	Platform:	GNU/Linux
Assigned To:		OS:	OpenSuSE
Priority:	normal	OS Version:	12.3
Status:	new	Product Version:	10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	assertion failed [rem_idx != -1]: Unable to find existing allocation for shared memory segment to unmap (VMAllocationTracker.cpp
Description:	My computer has recently updated to macOS Sonoma 14.3.1, and since then I have not been able to visualize my openFoam trials by using the command “paraFoam”. I began with using docker version 4.27.0 and thought that it might be an issue with that version, as per discussed here: Docker for Macos Sonoma 14.3.1 · Issue #7183 · docker/for-mac · GitHub 14 . In an attempt to resolve the issue, I reverted back to docker version 4.26.1. I am still having the same issue, which will be pasted below: 5edb65479128: gFHRcore_simplifiedMeshv4>> paraFoam Created temporary ‘gFHRcore_simplifiedMeshv4.OpenFOAM’ QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to ‘/tmp/runtime-openfoam’ assertion failed [rem_idx != -1]: Unable to find existing allocation for shared memory segment to unmap (VMAllocationTracker.cpp:745 remove_shared_mem) Trace/breakpoint trap I have not been able to find that many resources online to help with this issue and really need some guidance in solving it.
Tags:
Steps To Reproduce:	type "paraFoam" into any directory that has a mesh
Additional Information:
System Description
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4058	[OpenFOAM] Bug	minor	always	2024-02-27 15:04	2024-02-28 10:58
Reporter:	Johan Spang	Platform:	GNU/Linux
Assigned To:	will	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	11
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	11
		Target Version:
Summary:	cylindricalFunctionObject rendering incorrect results
Description:	I am using the cylindricalFunctionObject to study the radial, tangential and axial components of U in a rotodynamic case (looking at the components of the generated 'cylindrical(U)' vector field in paraview). I noticed that something is wrong with the radial and tangential components. I traced the problem down to a dependence on the axial distance of each cell centre from the origin. My case uses the incompressibleFluid solver and contains an MRF zone.
Tags:
Steps To Reproduce:	To replicate with a simple 2D-case: * Copy tutorials/incompressibleFluid/mixerVessel2DMRF to a temporary directory * Run the Allrun script in the copied mixerVessel2DMRF folder * Optionally, run the command 'touch test.foam' inside the mixerVessel2DMRF folder (for opening in paraview later) * Make two new copies of the local mixerVessel2DMRF folder (including the generated solution data), name them with -1 and -2 extension. Now the temporary folder contains the following:    mixerVessel2DMRF    mixerVessel2DMRF-1    mixerVessel2DMRF-2 * Navigate to the mixerVessel2DMRF-1 directory * run transformPoints "translate=(0 0 0.1)" * Navigate to the mixerVessel2DMRF-2 directory * run transformPoints "translate=(0 0 0.2)" * save the attached postProcessDict to the temporary folder * inside each of the 3 cases run 'foamPostProcess -dict ../postProcessDict' (this will run the cylindricalFunctionObject and output the cylindrical(U) vector field for all time steps) * Visualize the 3 different cases and compare mag(U) with mag(cylindrical(U)) - see attached image for an example that shows the problem. The results are only as expected for the base case where z = 0 for all cells.
Additional Information:	In src/functionObjects/field/cylindrical/cylindricalFunctionObject.C: Foam::tensor Foam::functionObjects::cylindrical::R(const vector& p) const {     vector dir = p - origin_;     dir /= mag(dir) + vSmall;     const vector axis = axis_/mag(axis_);     const vector r = dir - (dir & axis)*axis;     return tensor(r, axis^r, axis); } Should not r be normalized? replacing:     const vector r = dir - (dir & axis)*axis; with:      vector r_ = dir - (dir & axis)*axis;      const vector r = r_ / (mag(r_) + vSmall); Gives the expected results, as shown in the right column in the attached image. It also produces the expected results in my real world 3D case. A side note: src/meshTools/coordinateSystems/coordinateRotation/cylindrical.C seems to be implemented in a similar way, but I have not tested if it has any issues.
System Description
Attached Files:	postProcessDict (961 bytes) 2024-02-27 15:04 https://bugs.openfoam.org/file_download.php?file_id=3489&type=bug visualization.png (171,280 bytes) 2024-02-27 15:04 https://bugs.openfoam.org/file_download.php?file_id=3490&type=bug

Notes
(0013202) will    2024-02-28 10:58	Thanks for the report. Fixed in v11 and in dev. https://github.com/OpenFOAM/OpenFOAM-11/commit/bc5adc26e6fac70447370342d4a48fc3481eb993 https://github.com/OpenFOAM/OpenFOAM-dev/commit/66835ba9a9d6a2631b52b51bf9b84353016076ef

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4056	[ThirdParty] Bug	minor	always	2024-02-23 03:11	2024-02-23 03:11
Reporter:	kakila	Platform:	GNU/Linux
Assigned To:		OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	new	Product Version:	11
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	paraview crashes after mesa update
Description:	After a resent update of ubuntu $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.4 LTS Release: 22.04 Codename: jammy $ cat /var/log/apt/history.log ... Start-Date: 2024-02-20 18:50:20 Commandline: aptdaemon role='role-commit-packages' sender=':1.236' Upgrade: libglx-mesa0:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2) , libglx-mesa0:i386 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), mesa-c ommon-dev:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libosmesa6 -dev:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libgbm1:amd64 ( 23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libgbm1:i386 (23.0.4-0ubunt u1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libgbm-dev:amd64 (23.0.4-0ubuntu1~22.04. 1, 23.2.1-1ubuntu3.1~22.04.2), node-ip:amd64 (1.1.5+~1.1.0-1, 1.1.5+~1.1.0-1ubuntu0.1~esm1), language-pack-gnome-en-base:amd64 (1:22.04+20230801, 1:22.04+20240212), libxatracker2:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), mesa-va-drivers:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), mesa-va-drivers:i386 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libgl1-mesa-dev:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libgl1-mesa-dri:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libgl1-mesa-dri:i386 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libosmesa6:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libosmesa6:i386 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libegl1-mesa-dev:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), mesa-vulkan-drivers:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), mesa-vulkan-drivers:i386 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libglapi-mesa:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libglapi-mesa:i386 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), language-pack-gnome-en:amd64 (1:22.04+20230801, 1:22.04+20240212), unzip:amd64 (6.0-26ubuntu3.1, 6.0-26ubuntu3.2), libegl-mesa0:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), libegl-mesa0:i386 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2), mesa-vdpau-drivers:amd64 (23.0.4-0ubuntu1~22.04.1, 23.2.1-1ubuntu3.1~22.04.2) End-Date: 2024-02-20 18:50:27 paraview (shiped with OpenFoam.org) is not booting anymore, giving the following segmentation fault Mesa warning: failed to remap glCompressedTexImage1D Mesa warning: failed to remap glCompressedTexImage2D Mesa warning: failed to remap glCompressedTexImage3D ... Mesa warning: failed to remap glSecondaryColor3hNV Mesa warning: failed to remap glSecondaryColor3hvNV Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) Loguru caught a signal: SIGSEGV Stack trace: 32 0x55c50bc1e33e paraview(+0x933e) [0x55c50bc1e33e] 31 0x7f80171f8e40 __libc_start_main + 128 30 0x7f80171f8d90 /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f80171f8d90] 29 0x55c50bc1e005 paraview(+0x9005) [0x55c50bc1e005] 28 0x55c50bc23b0d paraview(+0xeb0d) [0x55c50bc23b0d] 27 0x55c50bc1f1ed paraview(+0xa1ed) [0x55c50bc1f1ed] 26 0x7f801705dda0 pqParaViewBehaviors::pqParaViewBehaviors(QMainWindow*, QObject*) + 2448 25 0x7f8016fad082 pqAlwaysConnectedBehavior::pqAlwaysConnectedBehavior(QObject*) + 322 24 0x7f8016facf14 pqAlwaysConnectedBehavior::serverCheck() + 196 23 0x7f80162c2dca pqObjectBuilder::createServer(pqServerResource const&, int) + 474 22 0x7f801525b7b6 vtkSMSession::ConnectToSelf(int) + 38 21 0x7f80144901fd vtkProcessModule::RegisterSession(vtkSession*) + 141 20 0x7f8012178862 /opt/paraviewopenfoam510/lib/libvtkCommonCore-pv5.10.so.1(+0x4fc862) [0x7f8012178862] 19 0x7f801205c84d vtkCallbackCommand::Execute(vtkObject*, unsigned long, void*) + 29 18 0x7f80153d3bd8 /opt/paraviewopenfoam510/lib/libvtkGUISupportQt-pv5.10.so.1(+0x3dbd8) [0x7f80153d3bd8] 17 0x7f80153c0871 /opt/paraviewopenfoam510/lib/libvtkGUISupportQt-pv5.10.so.1(+0x2a871) [0x7f80153c0871] 16 0x7f801576e7c8 /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2f17c8) [0x7f801576e7c8] 15 0x7f801622b637 /opt/paraviewopenfoam510/lib/libpqCore-pv5.10.so.1(+0x98637) [0x7f801622b637] 14 0x7f8016225e26 pqServerManagerObserver::connectionCreated(long long) + 70 13 0x7f801576e7c8 /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2f17c8) [0x7f801576e7c8] 12 0x7f8016316366 pqServerManagerModel::onConnectionCreated(long long) + 742 11 0x7f80162244b6 pqServerManagerModel::serverAdded(pqServer*) + 70 10 0x7f801576e7c8 /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2f17c8) [0x7f801576e7c8] 9 0x7f801701b3b6 pqDefaultViewBehavior::onServerCreation(pqServer*) + 86 8 0x7f8015162e99 vtkPVSessionCore::GatherInformation(unsigned int, vtkPVInformation*, unsigned int) + 377 7 0x7f8015162b7a vtkPVSessionCore::GatherInformationInternal(vtkPVInformation*, unsigned int) + 58 6 0x7f800b83821d vtkPVRenderingCapabilitiesInformation::CopyFromObject(vtkObject*) + 13 5 0x7f800b8381e3 vtkPVRenderingCapabilitiesInformation::GetLocalCapabilities() + 339 4 0x7f80148feb55 vtkOpenGLRenderWindow::SupportsOpenGL() + 1013 3 0x7f80149035c5 vtkOpenGLRenderWindow::OpenGLInit() + 133 2 0x7f8014612a1b vtkglew_glewInit + 619 1 0x7f8014603338 /opt/paraviewopenfoam510/lib/libvtkglew-pv5.10.so.1(+0x5c338) [0x7f8014603338] 0 0x7f8017211520 /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7f8017211520] ( 1.504s) [paraview ] :0 FATL| Signal: SIGSEGV Segmentation fault (core dumped)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4055	[OpenFOAM] Bug	crash	always	2024-02-21 15:04	2024-02-21 16:24
Reporter:	agustinvo	Platform:	Any
Assigned To:	henry	OS:	Any
Priority:	normal	OS Version:	Any
Status:	resolved	Product Version:	11
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	11
		Target Version:
Summary:	turbulenceFields function object does not access to fluidThermophysicalTransportModel
Description:	It is not possible to retrieve the kappaEff field, included in the functionObject turbulenceFields, because the if-condition of line 161 https://github.com/OpenFOAM/OpenFOAM-11/blob/642b6a1f5c7bc501ca9ebc78d4e54051ba32cb2d/src/functionObjects/field/turbulenceFields/turbulenceFields.C#L161C4-L161C73 is never true. The postProcess application enters into another else-condition block and it crashes because no kappaEff field is found.
Tags:
Steps To Reproduce:	1. Run a simulation with a fluid solver 2. Run foamPostprocess with the turbulenceFields function and the field kappaEff 3. Get the error: --> FOAM FATAL ERROR: Invalid field selection     From function virtual bool Foam::functionObjects::turbulenceFields::execute()     in file turbulenceFields/turbulenceFields.C at line 269. FOAM exiting
Additional Information:	Substituting the line 161     if (obr_.foundObject<fluidThermophysicalTransportModel>(phaseName_)) by this one     if (obr_.foundType<fluidThermophysicalTransportModel>(phaseName_)) has worked for me.
Attached Files:

Notes
(0013198) henry    2024-02-21 15:12	I just tested the turbulenceFields functionObject in OpenFOAM-dev and kappaEff is generated without any problem. Could you please confirm that this issue does not occur for you with OpenFOAM-dev?
(0013199) agustinvo    2024-02-21 15:33	The commit in the dev branch https://github.com/OpenFOAM/OpenFOAM-dev/commit/2779442d2a1ff03694f41e6a80e95ed0a1821792 does indeed add the same line than the one I indicated, but in OF-11 the bug is there. A fix could be done into this file in OF-11 as the one in OF-dev
(0013200) henry    2024-02-21 16:24	Resolved by commit c7c47ff3f7b39ba0240b9bf5753c7e86bddaeb92

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4054	[OpenFOAM] Bug	minor	always	2024-02-17 09:55	2024-02-19 14:58
Reporter:	cgoessni	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:
		Target Version:
Summary:	multiValveEngineState: clearance incorrect at first call
Description:	When running the multiValveEngineState function object, the first entry for the piston clearance is always scalar great (~1e15) instead of the actual value.
Tags:
Steps To Reproduce:	Run e.g. kivaTest and inspect the output of postProcessing log file: the first clearance entry is always 4.5e15.
Additional Information:	One possible remedy could be to update the clearance in the constructor of the piston. However, this would require a valid distance point field.
Attached Files:

Notes
(0013197) henry    2024-02-19 14:58	Resolved by commit 5eaec31deb084fc441c2782f5934386b4c15b1fe

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4053	[OpenFOAM] Bug	minor	always	2024-02-17 09:48	2024-02-17 11:51
Reporter:	cgoessni	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:	kivaTEst would ignore setDeltaT function object
Description:	With commit 9753b67f30a9adb840048d4752c19b4ea1869104, kivaTest tutorial has a new functionObject file system/functions, which makes the system/controlDict functions/setDeltaT functionObject unused, according to the log file: /*---------------------------------------------------------------------------*\   ========= |   \\ / F ield | OpenFOAM: The Open Source CFD Toolbox    \\ / O peration | Website: https://openfoam.org     \\ / A nd | Version: dev      \\/ M anipulation | \*---------------------------------------------------------------------------*/ Build : dev-9252d0c06795 Exec : foamRun Date : Feb 17 2024 Time : 10:44:06 Host : "fvkmb176" PID : 135244 I/O : uncollated Case : /opt/OpenFOAM/OpenFOAM-dev/tutorials/XiFluid/kivaTest 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 Selecting userTime engine --> FOAM Warning :     From function Foam::functionObjectList::functionObjectList(const Foam::Time&, bool)     in file db/functionObjects/functionObjectList/functionObjectList.C at line 253     Both "system/functions" and "system/controlDict/functions" found, the latter will be ignored.
Tags:
Steps To Reproduce:
Additional Information:	Moving system/controlDict/functions into system/functions resolves the issue for me.
Attached Files:

Notes
(0013196) henry    2024-02-17 11:51	Resolved by commit 6b966504362a4069571cab9a55ea92bbb07b1534

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4047	[OpenFOAM] Bug	crash	always	2024-01-14 18:24	2024-01-17 16:06
Reporter:	Federico Municchi	Platform:	Linux
Assigned To:	will	OS:	Ubuntu
Priority:	normal	OS Version:	22.04.03
Status:	resolved	Product Version:	11
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	MPPIC "moment" averaging method causes Goldschmidt to crash
Description:	This is a common issue with the previous versions of OpenFOAM. Switching the averaging method to "moment" results in the MPPIC solver crashing at the first "evolve()", when the isotropy model is employed.
Tags:
Steps To Reproduce:	Just run the GoldschmidtMPPIC tutorial with the moment averaging method.
Additional Information:	ERROR MESSAGE: Solving 3-D cloud cloud Cloud: cloud injector: model1     Added 24750 new parcels #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigFpe::sigHandler(int) at ??:? #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" #3 ? in "/lib/x86_64-linux-gnu/libm.so.6" #4 exp in "/lib/x86_64-linux-gnu/libm.so.6" #5 Foam::exp(Foam::Field<double>&, Foam::UList<double> const&) at ??:? #6 Foam::tmp<Foam::FieldField<Foam::Field, double> > Foam::exp<Foam::Field>(Foam::tmp<Foam::FieldField<Foam::Field, double> > const&) at ??:? #7 Foam::IsotropyModels::Stochastic<Foam::MPPICCloud<Foam::MomentumCloud<Foam::ParcelCloudBase<Foam::MPPICParcel<Foam::MomentumParcel<Foam::particle> > > > > >::calculate() at ??:? #8 void Foam::MPPICCloud<Foam::MomentumCloud<Foam::ParcelCloudBase<Foam::MPPICParcel<Foam::MomentumParcel<Foam::particle> > > > >::motion<Foam::MPPICCloud<Foam::MomentumCloud<Foam::ParcelCloudBase<Foam::MPPICParcel<Foam::MomentumParcel<Foam::particle> > > > > >(Foam::MPPICCloud<Foam::MomentumCloud<Foam::ParcelCloudBase<Foam::MPPICParcel<Foam::MomentumParcel<Foam::particle> > > > >&, Foam::MPPICParcel<Foam::MomentumParcel<Foam::particle> >::trackingData&) at ??:? #9 void Foam::MomentumCloud<Foam::ParcelCloudBase<Foam::MPPICParcel<Foam::MomentumParcel<Foam::particle> > > >::solve<Foam::MPPICCloud<Foam::MomentumCloud<Foam::ParcelCloudBase<Foam::MPPICParcel<Foam::MomentumParcel<Foam::particle> > > > > >(Foam::MPPICCloud<Foam::MomentumCloud<Foam::ParcelCloudBase<Foam::MPPICParcel<Foam::MomentumParcel<Foam::particle> > > > >&, Foam::MPPICParcel<Foam::MomentumParcel<Foam::particle> >::trackingData&) at ??:? #10 virtual thunk to Foam::ParcelCloud<Foam::MPPICCloud<Foam::MomentumCloud<Foam::ParcelCloudBase<Foam::MPPICParcel<Foam::MomentumParcel<Foam::particle> > > > > >::evolve() at ??:? #11 Foam::parcelCloudList::evolve() at ??:? #12 Foam::solvers::incompressibleDenseParticleFluid::prePredictor() at ??:? #13 ? in "/opt/openfoam11/platforms/linux64GccDPInt32Opt/bin/foamRun" #14 ? in "/lib/x86_64-linux-gnu/libc.so.6" #15 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #16 ? in "/opt/openfoam11/platforms/linux64GccDPInt32Opt/bin/foamRun" Floating point exception (core dumped)
System Description
Attached Files:

Notes
(0013184) will    2024-01-17 16:05    (Last edited: 2024-01-17 16:06)	The moment method is not reliable. It was a nice idea, but ultimately it did not solve the problem of how to construct lagrangian-to-lagrangian averages in such a way as to create a uniform distribution of parcels within the cells. If someone had a need, and was able to fund development and maintenance work on this topic, then this issue could be revisited. For the time being, to avoid confusion regarding the applicability of this functionality, I have removed the moment method. https://github.com/OpenFOAM/OpenFOAM-dev/commit/a671b738c91280df42952e64a2b374b879062bc0

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4045	[OpenFOAM] Bug	minor	sometimes	2024-01-09 06:49	2024-01-09 10:10
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:	Uninitialised finalIter_ in solutionControl.C
Description:	Following this commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/836ce9a30253ba93efa899b08c6e0af4b630b0ea it seems that cases with Poisson walldist or hydrostaticInitialisation (and transient ddt) no longer work unless Final-solver setting is specified. The following tutorials don't work due to lacking yPsiFinal or ph_rghFinal solver settings: tutorials/multiRegion/film/rivuletBox tutorials/multiphaseEuler/bubblePipe tutorials/multicomponentFluid/smallPoolFire2D tutorials/multicomponentFluid/smallPoolFire3D It seems that the finalIter_-member is not initialised in the constructor of solutionControl.C so it might have a random non-zero value defaulting to true and hence requiring "Final". This affects any equation that is solved before the main loop starts. The pimple-loop will reset the finalIter_ and work correctly afterwards. The issue can be fixed by simply adding finalIter_(false) to the initializer list of solutionControl.C to restore the earlier behaviour.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0013181) henry    2024-01-09 10:10	Resolved by commit 53ddbda670cdbeeae3607615d12922d961ef495d

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4042	[OpenFOAM] Bug	crash	always	2023-12-19 13:58	2023-12-21 16:36
Reporter:	maHein	Platform:	Unix
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:	topoSet + searchableSurfaceToFaceZone = crashes
Description:	Hello, the following combination always throws an error: Use topoSet to create a faceZoneSet with the searchableSurfaceToFaceZone source with a specific STL geometry. OpenFOAM always complains that it cannot find the corresponding STL geometry, although everything is at its correct place. The error message reads as follow: --> FOAM FATAL ERROR: Cannot find triSurfaceMesh starting from "/disk7102/home/heinrich/Desktop/concrete-rheometer/mesh/annulus/constant/geometry/annulus" But the STL geometry is located exactly there.
Tags:
Steps To Reproduce:	An example case is provided. Just execute the Allmesh script: First, blockMesh creates the mesh, then topoSet should create a faceZoneSet, but this crashes.
Additional Information:
System Description
Attached Files:	annulus.zip (4,569 bytes) 2023-12-19 13:58 https://bugs.openfoam.org/file_download.php?file_id=3479&type=bug

Notes
(0013171) henry    2023-12-19 14:04	Can you provide maintenance funding to cover this work or a patch to resolve the issue?
(0013172) maHein    2023-12-20 07:54	The issue is partly due to (1) a mistake in the documentation and (2) partly due to poor coding. (1) In ./etc/caseDicts/annotated/topoSetDict, the documentation reads that one should provide the name of the geometry file with the keyword "name". In the source code and other tutorials, the required keyword is "file". This should be corrected (2) If the keyword "file" is not found (as in my case), searchableSurfaceToFaceZone automatically looks for a default file, which is located in the folder "constant/geometry" and called like the name of the case, in my example "annulus" (without any file extension!). Now the issue is as follows: On the one hand, OpenFOAM looks for a geometry file without file extension, on the other hand OpenFOAM cannot handle geometry files without extension as it throws an error when such a file is found: unknown file extension . Supported extensions are '.ftr', '.stl', '.stlb', '.gts', '.obj', '.ac', '.off', '.nas', '.tri' and '.vtk' So in essence, the default behaviour, if the keyword 'file' is not found, always results in an error. Even worse, the error message does not give any indication on how to resolve this as a user. Interestingly, exactly the same issue is found with the 'createBaffles' utility, when a triSurfaceMesh is used for creating the baffles but the 'file' keyword is not found. Solution: Either get rid of looking for a default file or, if this is continued to be included, add a file extension in the lookupOrDefault entry. The relevant code lines for searchableSurfaceToFaceZone are in file src/meshTools/sets/faceZoneSources/searchableSurfaceToFaceZone.C, lines 212 - 216.
(0013174) henry    2023-12-20 11:06	If we remove the default file the file entry would have to be specified for all forms of searchableSurface, not just triSurfaceMesh for which it is needed.
(0013175) henry    2023-12-20 11:09	I have corrected the documentation in etc/caseDicts/annotated/topoSetDict: commit a5939b0f0aa84678ebd5fa1dacad3fe497d2f5a3 (HEAD -> master, origin/master, origin/HEAD) Author: Henry Weller <http://cfd.direct> Date: Wed Dec 20 11:08:00 2023 +0000     etc/caseDicts/annotated/topoSetDict: Updated documentation for triSurfaceMesh
(0013176) henry    2023-12-20 11:40	Try this: commit b94ade6e61b4dc9a4235ef308f7a3540c78704a3 (HEAD -> master, origin/master, origin/HEAD) Author: Henry Weller <http://cfd.direct> Date: Wed Dec 20 11:38:55 2023 +0000     triSurfaceMesh: Rationalised the handling of the now required "file" entry

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4040	[OpenFOAM] Bug	crash	always	2023-12-14 17:55	2023-12-20 14:02
Reporter:	efirvida	Platform:	Linux x86-64
Assigned To:	will	OS:	Debian, Manjaro
Priority:	normal	OS Version:	12
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	11
		Target Version:
Summary:	createNonConformalCouples crash after SHM
Description:	Here I put a sample case to reproduce this isee, the thing is that I want to create a rotatory domain inside a box similar to the propeller example, But every time I run the `createNonConformalCouples -overwrite nonCouple1 nonCouple2` the case crash, after the `fvMeshStitcher: Connecting`. I put two running script and I added the logs on my system running in OF 11, but it also happen in OF 10. Seems that when this run in parallel the error appears when writing the mesh, and the mesh breaks, it can be checked or reconstructed. Running in parallel the mesh didn't break the non conformal patches are not created.
Tags:
Steps To Reproduce:	./mesh.sh or ./mesh-parallel.sh
Additional Information:
System Description
Attached Files:	ncc.zip (32,885 bytes) 2023-12-14 17:55 https://bugs.openfoam.org/file_download.php?file_id=3478&type=bug

Notes
(0013177) will    2023-12-20 14:02	Thanks for the report. This is resolved by the following commits in v11 and in dev: https://github.com/OpenFOAM/OpenFOAM-11/commit/c46b322d5bf43cdd6a9dd99737a8798df290c537 https://github.com/OpenFOAM/OpenFOAM-dev/commit/2057174b552e3ce5caff6bfa93eda380195ed09e

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4043	[OpenFOAM] Bug	major	always	2023-12-19 14:43	2023-12-20 10:24
Reporter:	jonas_buenning	Platform:
Assigned To:	henry	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	11
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	11
		Target Version:
Summary:	wrong results for the solver module "solid" for nNonOrthogonalCorrectors > 0 due to not updating the temperature field
Description:	The current implementation of the thermophysicalPredictor of the solid solver looks like this: void Foam::solvers::solid::thermophysicalPredictor() {     volScalarField& e = thermo_.he();     const volScalarField& rho = thermo_.rho();     while (pimple.correctNonOrthogonal())     {         fvScalarMatrix eEqn         (             fvm::ddt(rho, e)           + thermophysicalTransport->divq(e)           ==             fvModels().source(rho, e)         );         eEqn.relax();         fvConstraints().constrain(eEqn);         eEqn.solve();         fvConstraints().constrain(e);     }     thermo_.correct(); } The line thermo_.correct(); is outside of the nonorthogonality corrector loop. This is however a problem: thermo_.correct() will correct the temperature field using the internal energy/enthalphy field (in the esiest case just as T = e/Cv). The temperature field will however also be used in assembling the system for the energy equation, specifically inside of thermophysicalTransport->divq(e). For example for the isotropic model divq(e) returns -fvc::laplacian(kappa(), thermo.T()) - fvm::laplacianCorrection(kappa()/thermo.Cv(), e). In short, the temperature field is used for assembling the system, but not updated every loop iteration. This causes wrong results. Solution: thermo_.correct(); needs to be moved inside of the while loop. I've already tested this and the results look correct
Tags:
Steps To Reproduce:	Example case attached. Change nNonOrthogonalCorrectors to 0 to see the difference. Change nOuterCorrectors to value > 1 to see that the problem is specifically caused by the nonorthogonality corrector loop.
Additional Information:
Attached Files:	wrongSolidHeatTranport.tar.xz (3,960 bytes) 2023-12-19 14:43 https://bugs.openfoam.org/file_download.php?file_id=3480&type=bug

Notes
(0013173) henry    2023-12-20 10:24	Resolved in OpenFOAM-11 by commit c46acc5d125510d78f9f7d17d46d3a6dd1c1bd7a Resolved in OpenFOAM-dev by commit 3c347ca566f16112fb8c756aec0423b907338d2d

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4041	[OpenFOAM] Feature	feature	always	2023-12-15 09:08	2023-12-15 11:31
Reporter:	blttkgl	Platform:	Unix
Assigned To:	will	OS:	Other
Priority:	low	OS Version:	(please specify)
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Histogram function object headers are duplicate names
Description:	The histogram function object writes the column headers of both bin ranges and the histogram values as the name of the field that is being used in the histogram function object. While there is nothing wrong with the function object itself, this may create issues if the user is using e.g. python for data post-processing, which causes duplicate header issue. I propose changing the header of the log from: # <fieldName> <fieldName> to # bin_value <fieldName> for easier post-processing and clearer description of the histogram data
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0013170) will    2023-12-15 11:31	The first column are actually values of the field in question. It's the second column that is the proportion of the volume of the mesh occupied by that value. So, I think the most accurate header would be "# <fieldName> v/vTotal", or similar. I have made this change here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/5cf2109eff5da10150fe3416a281ef389c060f54

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4039	[OpenFOAM] Bug	crash	always	2023-12-07 11:04	2023-12-07 14:43
Reporter:	tmaffei	Platform:	GNU/Linux
Assigned To:	will	OS:	Linux
Priority:	normal	OS Version:	22.04
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	11
		Target Version:
Summary:	Error running circuitBoardCooling case in tutorial folder in parallel
Description:	I have run the case circuitBoardCooling in the tutorial folder with solver buoyantFoam in serial and parallel. In serial everything works properly When I have tried to decompose the case, I got the following error: Processor 0: field transfer --> FOAM FATAL ERROR: Patch named not found.     From function const Foam::fvPatch& Foam::fvBoundaryMesh::operator[](const Foam::word&) const     in file fvMesh/fvBoundaryMesh/fvBoundaryMesh.C at line 165. FOAM aborting #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::error::abort() at ??:? #2 Foam::fvBoundaryMesh::operator[](Foam::word const&) const at ??:? #3 Foam::compressible::thermalBaffleFvPatchScalarField::owner() const at ??:? #4 Foam::compressible::thermalBaffleFvPatchScalarField::write(Foam::Ostream&) const at ??:? #5 Foam::GeometricBoundaryField<double, Foam::fvPatchField, Foam::volMesh>::writeEntry(Foam::word const&, Foam::Ostream&) const in "/opt/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt64Opt/bin/decomposePar" #6 Foam::Ostream& Foam::operator<< <double, Foam::fvPatchField, Foam::volMesh>(Foam::Ostream&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/opt/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt64Opt/bin/decomposePar" #7 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::writeData(Foam::Ostream&) const in "/opt/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt64Opt/bin/decomposePar" #8 Foam::fileOperation::writeObject(Foam::regIOobject const&, Foam::IOstream::streamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType, bool) const at ??:? #9 Foam::regIOobject::writeObject(Foam::IOstream::streamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType, bool) const at ??:? #10 ? in "/opt/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt64Opt/bin/decomposePar" #11 ? in "/opt/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt64Opt/bin/decomposePar" #12 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #13 ? in "/opt/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt64Opt/bin/decomposePar" Aborted (core dumped) Then, I have modified the createBaffleDict to consider only baffleFacesThermoBaffle1D and not baffleFacesThermoBaffle3D. I have decomposed the case and run it in parallel, without any issues. When I have tried to reconstruct the case, I got the following error:     request for polyMesh region0 from objectRegistry circuitBoardCoolingBaffle1DParallel failed     available objects of type polyMesh are 0()     From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::polyMesh]     in file /opt/OpenFOAM/OpenFOAM-10/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 211. FOAM aborting #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::error::abort() at ??:? #2 Foam::polyMesh const& Foam::objectRegistry::lookupObject<Foam::polyMesh>(Foam::word const&) const at ??:? #3 Foam::mappedPatchBase::samplePolyPatch() const at ??:? #4 Foam::compressible::thermalBaffle1DFvPatchScalarField<Foam::constIsoSolidTransport<Foam::species::thermo<Foam::eConstThermo<Foam::rhoConst<Foam::specie> >, Foam::sensibleInternalEnergy> > >::owner() const at ??:? #5 Foam::compressible::thermalBaffle1DFvPatchScalarField<Foam::constIsoSolidTransport<Foam::species::thermo<Foam::eConstThermo<Foam::rhoConst<Foam::specie> >, Foam::sensibleInternalEnergy> > >::rmap(Foam::fvPatchField<double> const&, Foam::List<long> const&) at ??:? #6 ? in "/opt/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt64Opt/bin/reconstructPar" #7 ? in "/opt/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt64Opt/bin/reconstructPar" #8 ? in "/opt/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt64Opt/bin/reconstructPar" #9 ? in "/opt/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt64Opt/bin/reconstructPar" #10 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #11 ? in "/opt/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt64Opt/bin/reconstructPar" Aborted (core dumped)
Tags:
Steps To Reproduce:	1. Running the circuitBoardCooling case in tutorial folder in parallel 2. Modify createBaffleDict file to generate only baffleFacesThermoBaffle1D 3. Running in parallel and reconstruct the case
Additional Information:
Attached Files:

Notes
(0013168) henry    2023-12-07 11:27	Try running the multiRegion/CHT/circuitBoardCooling case in OpenFOAM-11.
(0013169) will    2023-12-07 14:43	Thanks for the report. Fixed in dev and v11 by the following commits: https://github.com/OpenFOAM/OpenFOAM-dev/commit/d9a07a44b603f5c7d4a73db09e487a767e61cd21 https://github.com/OpenFOAM/OpenFOAM-11/commit/3bc926e4bf1dd2f51e977e755cd60f26f55aac12

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4036	[OpenFOAM] Bug	minor	always	2023-11-19 15:50	2023-11-19 16:52
Reporter:	cgoessni	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:	kivaTest dynamicMeshDict wrong with most recent commit
Description:	WIth the latest commit, dynamicMeshDict of tutorials/XiFluid/kivaTest contains entries to not yet existent libraries.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0013157) henry    2023-11-19 16:52	Resolved by commit ec8e9b6e6ee743713a373eef7ff2c240d9e364c0

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4034	[OpenFOAM] Bug	block	always	2023-11-13 09:49	2023-11-16 16:23
Reporter:	georgescovici	Platform:	GNU/Linux
Assigned To:	henry	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	11
		Target Version:
Summary:	Bug for pimpleFoam, parallel, outerCorrectorResidualControl, when using moveMeshOuterCorrectors true
Description:	The bug below has been observed when using the Red Hat Enterprise Linux 8.8 operating system. I am trying to run a simulation where it is important that the mesh is deformed at each outer corrector of the PIMPLE algorithm. Since it is also a large case, I want to run it in parallel. To limit the number of outer correctors executed at each timestep, I am interested in imposing that the outer corrector loop is stopped when low-enough values of the fluid residuals have been obtained. To impose the movement of the mesh at each outer corrector, I set moveMeshOuterCorrectors to true, and for the outer corrector convergence criterion I created an entry within the outerCorrectorResidualControl subdict. Both of these options are set from the PIMPLE dict in fvSolution. When imposing both of them and running PIMPLE in parallel, the simulation crashes. When only 2 of the 3 options (movement of the mesh at each outer corrector, advancement of the timestep based on the fluid residuals, running the case in parallel) are activated, the method works just fine.
Tags:
Steps To Reproduce:	The bug was initially found in OF8, but has been found to also occur in OF10. It can be reproduced by copying from the movingCone case. Now, by running successively blockMesh, decomposePar, and mpirun -n 4 pimpleFoam -parallel, the simulation works just fine. Next, set moveMeshOuterCorrectors to true in fvSolution. This requires an extra subdict entry in the "solvers" dict in fvSolution, for cellMotionUxFinal. For simplicity, I added:     cellMotionUxFinal     {         $cellMotionUx     } I also added nOuterCorrectors 25. Now, run Allclean, then blockMesh, decomposePar, and mpirun -n 4 pimpleFoam -parallel. The method works well. Next, add a residual-based outer corrector residual criterion, by using the outerCorrectorResidualControl subdict in the fvSolution/PIMPLE dict. For example:     outerCorrectorResidualControl     {       p       {               relTol 1e-4;               tolerance 1e-5;       }     } Now, do an Allclean, then blockMesh, then decomposePar. The simulation "hangs" at the third outer corrector of the first timestep. If one cleans the case and simply runs the pimpleFoam command (which uses a single core), there is no hanging. If one comments out the moveMeshOuterCorrector entry in fvSolution and runs the case in parallel, the method again behaves normally.
Additional Information:
System Description
Attached Files:

Notes
(0013152) henry    2023-11-13 10:14	The corrector loops and residual control have been substantially rewritten for the modular solver system in OpenFOAM-11, please upgrade to 11 and re-test and report back with details if the issues remains.
(0013153) georgescovici    2023-11-15 13:34	Hello, henry! Thank you for your quick response. As suggested, I ran the movingCone case in OF 11 (debug mode), and the simulation crashed. I am getting the same error that I also observed in OF 8 (debug mode), namely: [3] [3] [3] --> FOAM FATAL ERROR: [3] index 1 out of range 0 ... 0 [3] [3] From function void Foam::UList<T>::checkIndex(Foam::label) const [with T = Foam::SolverPerformance<double>; Foam::label = int] [3] in file /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H at line 106. [3] FOAM parallel run aborting [3] [2] [2] [2] --> FOAM FATAL ERROR: [2] index 1 out of range 0 ... 0 [2] [2] From function void Foam::UList<T>::checkIndex(Foam::label) const [with T = Foam::SolverPerformance<double>; Foam::label = int] [2] in file /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H at line 106. [2] [0] [0] [0] --> FOAM FATAL ERROR: [0] index 1 out of range 0 ... 0 [0] [1] [1] [1] --> FOAM FATAL ERROR: FOAM parallel run aborting [2] [0] From function void Foam::UList<T>::checkIndex(Foam::label) const [with T = Foam::SolverPerformance<double>; Foam::label = int] [0] in file /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H at line 106. [0] FOAM parallel run aborting [0] [1] index 1 out of range 0 ... 0 [1] [1] From function void Foam::UList<T>::checkIndex(Foam::label) const [with T = Foam::SolverPerformance<double>; Foam::label = int] [1] in file /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H at line 106. [1] FOAM parallel run aborting [1] [1] #0 [0] #0 [2] #0 [3] #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at /software/OpenFOAM/OpenFOAM-11/src/OSspecific/POSIX/printStack.C:218 [0] #1 Foam::error::abort() at /software/OpenFOAM/OpenFOAM-11/src/OSspecific/POSIX/printStack.C:218 [1] #1 Foam::error::abort() at /software/OpenFOAM/OpenFOAM-11/src/OSspecific/POSIX/printStack.C:218 [2] #1 Foam::error::abort() at /software/OpenFOAM/OpenFOAM-11/src/OSspecific/POSIX/printStack.C:218 [3] #1 Foam::error::abort() at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/error.C:187 [0] #2 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/errorManip.H:85 (discriminator 4) [0] #3 Foam::UList<Foam::SolverPerformance<double> >::checkIndex(int) const at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/error.C:187 [1] #2 at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/error.C:187 [2] #2 Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>)Foam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/error.C:187 [3] #2 at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/errorManip.H:85 (discriminator 4) [1] #3 Foam::UList<Foam::SolverPerformance<double> >::checkIndex(int) constFoam::Ostream& Foam::operator<< <Foam::error>(Foam::Ostream&, Foam::errorManip<Foam::error>) at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/errorManip.H:85 (discriminator 4) [2] #3 Foam::UList<Foam::SolverPerformance<double> >::checkIndex(int) const at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/errorManip.H:85 (discriminator 4) [3] #3 Foam::UList<Foam::SolverPerformance<double> >::checkIndex(int) const at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H:108  at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H:108 [1] #4 Foam::UList<Foam::SolverPerformance<double> >::operator[](int) const[0] #4 Foam::UList<Foam::SolverPerformance<double> >::operator[](int) const at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H:108 [2] #4 Foam::UList<Foam::SolverPerformance<double> >::operator[](int) const at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H:108 [3] #4 Foam::UList<Foam::SolverPerformance<double> >::operator[](int) const at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H:201 [0] #5 void Foam::convergenceControl::getInitialTypeResiduals<double>(Foam::fvMesh const&, Foam::word const&, int, double&, double&) at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H:201 [1] #5 void Foam::convergenceControl::getInitialTypeResiduals<double>(Foam::fvMesh const&, Foam::word const&, int, double&, double&) at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H:201 [2] #5 void Foam::convergenceControl::getInitialTypeResiduals<double>(Foam::fvMesh const&, Foam::word const&, int, double&, double&) at /software/OpenFOAM/OpenFOAM-11/src/OpenFOAM/lnInclude/UListI.H:201 [3] #5 void Foam::convergenceControl::getInitialTypeResiduals<double>(Foam::fvMesh const&, Foam::word const&, int, double&, double&) at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/convergenceControl/convergenceControlTemplates.C:83  at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/convergenceControl/convergenceControlTemplates.C:83 [0] #6 Foam::convergenceControl::getInitialResiduals(Foam::fvMesh const&, Foam::word const&, int, double&, double&)[1] #6 Foam::convergenceControl::getInitialResiduals(Foam::fvMesh const&, Foam::word const&, int, double&, double&) at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/convergenceControl/convergenceControlTemplates.C:83 [3] #6 Foam::convergenceControl::getInitialResiduals(Foam::fvMesh const&, Foam::word const&, int, double&, double&) at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/convergenceControl/convergenceControlTemplates.C:83 [2] #6 Foam::convergenceControl::getInitialResiduals(Foam::fvMesh const&, Foam::word const&, int, double&, double&) at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/convergenceControl/convergenceControl.C:66 [0] #7 Foam::singleRegionCorrectorConvergenceControl::corrCriteriaSatisfied() const at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/convergenceControl/convergenceControl.C:66 [1] #7 Foam::singleRegionCorrectorConvergenceControl::corrCriteriaSatisfied() const at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/convergenceControl/convergenceControl.C:66 [3] #7 Foam::singleRegionCorrectorConvergenceControl::corrCriteriaSatisfied() const at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/convergenceControl/convergenceControl.C:66 [2] #7 Foam::singleRegionCorrectorConvergenceControl::corrCriteriaSatisfied() const at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/singleRegionCorrectorConvergenceControl/singleRegionCorrectorConvergenceControl.C:199 [0] #8 Foam::pimpleLoop::loop(Foam::correctorConvergenceControl&) at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/singleRegionCorrectorConvergenceControl/singleRegionCorrectorConvergenceControl.C:199 [1] #8 Foam::pimpleLoop::loop(Foam::correctorConvergenceControl&) at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/singleRegionCorrectorConvergenceControl/singleRegionCorrectorConvergenceControl.C:199 [3] #8 Foam::pimpleLoop::loop(Foam::correctorConvergenceControl&) at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/convergenceControl/singleRegionCorrectorConvergenceControl/singleRegionCorrectorConvergenceControl.C:199 [2] #8 Foam::pimpleLoop::loop(Foam::correctorConvergenceControl&) at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/pimpleControl/pimpleLoop/pimpleLoop.C:107 (discriminator 1) [0] #9 Foam::pimpleSingleRegionControl::loop() at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/pimpleControl/pimpleLoop/pimpleLoop.C:107 (discriminator 1) [1] #9 Foam::pimpleSingleRegionControl::loop() at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/pimpleControl/pimpleLoop/pimpleLoop.C:107 (discriminator 1) [3] #9 Foam::pimpleSingleRegionControl::loop() at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/pimpleControl/pimpleLoop/pimpleLoop.C:107 (discriminator 1) [2] #9 Foam::pimpleSingleRegionControl::loop() at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/pimpleControl/pimpleSingleRegionControl/pimpleSingleRegionControl.C:95 [0] #10 ? at /software/OpenFOAM/OpenFOAM-11/applications/solvers/foamRun/foamRun.C:136 [0] #11 __libc_start_main at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/pimpleControl/pimpleSingleRegionControl/pimpleSingleRegionControl.C:95 [1] #10 in "/lib64/libc.so.6" [0] #12 ?? at ??:? -------------------------------------------------------------------------- MPI_ABORT was invoked on rank 0 in communicator MPI COMMUNICATOR 3 SPLIT FROM 0 with errorcode 1. NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes. You may or may not see output from other processes, depending on exactly when Open MPI kills them. --------------------------------------------------------------------------  at /software/OpenFOAM/OpenFOAM-11/applications/solvers/foamRun/foamRun.C:136 [1] #11 __libc_start_main in "/lib64/libc.so.6" [1] #12 at /software/OpenFOAM/OpenFOAM-11/src/finiteVolume/cfdTools/general/solutionControl/pimpleControl/pimpleSingleRegionControl/pimpleSingleRegionControl.C:95
(0013154) henry    2023-11-16 14:32	Try this: commit 7dec67e9d7fd935bebd474b2acf19fb4f68bbee8 (HEAD -> master, origin/master, origin/HEAD) Author: Henry Weller <http://cfd.direct> Date: Thu Nov 16 14:30:47 2023 +0000     Residuals: Updated from a GeometricMeshObject to a UpdateableMeshObject          so that the stack of residuals is maintained following any kind of mesh change.          Resolves bug-report https://bugs.openfoam.org/view.php?id=4034
(0013156) henry    2023-11-16 16:23	Resolved in OpenFOAM-dev by commit 7dec67e9d7fd935bebd474b2acf19fb4f68bbee8 Resolved in OpenFOAM-11 by commit 88eee60ddee573a04ecd9bc4adf7c88cf5f2d59c

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4035	[OpenFOAM] Bug	crash	always	2023-11-16 14:30	2023-11-16 16:21
Reporter:	blocksgearing0d	Platform:	GNU/Linux
Assigned To:	henry	OS:	Ubuntu
Priority:	normal	OS Version:	20.04
Status:	resolved	Product Version:	11
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	extrudeMesh uses defaultRegion mesh when using region option
Description:	extrudeMesh uses defaultRegion mesh when using region option. The bug is both for v11 and dev.
Tags:
Steps To Reproduce:	Just run the $FOAM_ETC/templates/axisymmetricJet case using the following: runApplication blockMesh -dict system/blockMeshDict -region meshToMesh_1 runApplication extrudeMesh -dict system/extrudeMeshDict -region meshToMesh_1 , which will raise an fatal error since it will try to read the mesh from the constant/polyMesh/ instead of constant/polyMesh/meshToMesh_1.
Additional Information:	Apply the provided one-line patch. Commit comment and attribution could be: extrudeMesh: prevent loading mesh from constant when using region option Resolves bug-report https://bugs.openfoam.org/view.php?id=4035 Patch contributed by Stanislau Stasheuski, Aalto University.
System Description
Attached Files:	patch.diff (1,260 bytes) 2023-11-16 14:30 https://bugs.openfoam.org/file_download.php?file_id=3477&type=bug

Notes
(0013155) henry    2023-11-16 16:21	Resolved by commit 9966350d7ebe0a2b2b66947e068c52bffbea7758

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4000	[OpenFOAM] Bug	minor	always	2023-07-28 07:42	2023-10-19 16:12
Reporter:	Apanasevich	Platform:	amd64
Assigned To:	henry	OS:	Rocky Linux
Priority:	low	OS Version:	8.6
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	compressibleVoF: VoFTurbulenceDamping: Documentation of the usage is incorrect
Description:	In https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/applications/modules/compressibleVoF/fvModels/VoFTurbulenceDamping/VoFTurbulenceDamping.H type VoFTurbulenceDamping; It should be: type compressible::VoFTurbulenceDamping;
Tags:
Steps To Reproduce:	It can be reproduced using damBreak tutorial
Additional Information:
System Description	HPC Cluster
Attached Files:

Notes
(0013085) henry    2023-07-29 16:33	Resolved by commit 77f0e7fbdca3daf894480fc9dcc45f142a427927

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4025	[OpenFOAM] Bug	minor	have not tried	2023-10-14 18:31	2023-10-16 11:32
Reporter:	Julius_Nepos	Platform:	HP-2145 on floor
Assigned To:		OS:	Ubuntu 22.04
Priority:	normal	OS Version:	(please specify)
Status:	new	Product Version:	11
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	installed v11 after having erased 11-dev, ENV variables still point to WM_PROJECT_DIR=/opt/openfoam-dev
Description:	WM_PROJECT_DIR=/opt/openfoam-dev shouldn't they point to openfoam11
Tags:
Steps To Reproduce:	install OF-dev remove by removing the older paraview install OF11
Additional Information:
System Description
Attached Files:

Notes
(0013143) wyldckat    2023-10-16 11:32	Quoting from here: https://bugs.openfoam.org/rules.php - section "Reporting an Issue": - A clear set of instructions that reproduces the issue, including key files, if required. --- It's not clear what were the exact steps/commands you did, that resulted in the error message you are stating.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4020	[OpenFOAM] Bug	crash	always	2023-10-04 13:57	2023-10-05 12:42
Reporter:	maHein	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:	11
		Target Version:
Summary:	shockFluid crashes with NCC
Description:	Hello, running the module shockFluid with a case set up with NCC results in a crash at the beginning of the first time step in fluxPredictor(). It seems that the interpolation schemes for U/rho/T are responsible for this. Normaly, they are set to vanLeer or vanAlbada (which both lead to a crash). Setting them to linear runs fine. This did not happen with a identical case in OpenFOAM 10, but does occur both in OpenFOAM 11 and dev.
Tags:
Steps To Reproduce:	Take the annularThermalMixer tutorial case from the fluid module and supply additional settings required for the shockFluid module, such as diagonal solver for rho*, interpolation schemes for T, rho and U, (vanLeer preferebly) and update the thermo settings to sensibleInternalEnergy.
Additional Information:
System Description
Attached Files:	annularThermalMixer.zip (834,375 bytes) 2023-10-04 14:52 https://bugs.openfoam.org/file_download.php?file_id=3472&type=bug

Notes
(0013135) henry    2023-10-04 14:27	Do you have a case setup to reproduce the problem?
(0013136) maHein    2023-10-04 14:52	Sure, here it is based on annularThermalMixer. Just execute the Allrun script.
(0013138) henry    2023-10-05 12:42	Resolved in OpenFOAM-11 by commit 87a006fd533cf89773f302c8f0023bb94dcba16b Resolved in OpenFOAM-dev by commit 084bd015f13611a99084352ee94566931f547eea

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4001	[OpenFOAM] Feature	trivial	N/A	2023-07-31 09:57	2023-09-18 09:23
Reporter:	blocksgearing0d	Platform:	GNU/Linux
Assigned To:	henry	OS:	Ubuntu
Priority:	low	OS Version:	20.04
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Optionally execute systemCall once for parallel runs
Description:	In most cases parallel execution using systemCall is probably ambiguous. To address this, a `parallel` key was introduced, providing the means to select the desired behaviour. When "parallel" is set to false, the system calls will be executed once by the master process only.
Tags:
Steps To Reproduce:	Apply patch
Additional Information:
Attached Files:

Notes
(0013086) henry    2023-07-31 10:26	Please contact the OpenFOAM Foundation to sign the contributor agreement before providing patches which change the functionality of the code: See https://openfoam.org/dev/how-to-contribute/ for details.
(0013112) peksa    2023-09-02 22:52	Indeed systemCall can be ambiguous in parallel. Patch looks ok to me and I tested it to work.
(0013113) henry    2023-09-03 10:13	Pending contribution agreement
(0013120) henry    2023-09-18 09:23	Resolved by commit 3e7ebe0491f85549748f0569057c177ab79124a0

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4007	[ThirdParty] Bug	minor	always	2023-08-17 03:46	2023-09-07 06:55
Reporter:	rjones	Platform:	GNU/linux
Assigned To:		OS:	Ubuntu
Priority:	normal	OS Version:	23.04
Status:	new	Product Version:	11
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	ParaFoam Mesa warning + poor rendering
Description:	The OF11 version of paraview reports a Mesa warning and the window is poorly rendered (see attached screenshot). The window functions and the buttons are clickable, if you can guess where the icons are. The blacked out sections move when hovering over different parts of the window. Command line output is: Created temporary 'pitzDailySteady.OpenFOAM' Mesa warning: Window 27262985 has no colormap! Mesa warning: Window 27262988 has no colormap! I/O : uncollated Mesa warning: Window 27262998 has no colormap!
Tags:
Steps To Reproduce:	1. Install OpenFOAM 11 in a clean Ubuntu 23.04 environment using the package process https://openfoam.org/download/11-ubuntu/ 2. Run the pitzDailySteady tutorial 3. Open the tutorial with paraFoam
Additional Information:	Installing the default Ubuntu paraview package with `sudo apt install paraview` and opening the same openfoam case with an empty case.foam file renders fine and all native paraview functions work. I suspect this is a compilation problem where the dependencies don't match the Ubuntu 23.04 system, however I haven't had the time to recompile from source and identify a solution.
System Description
Attached Files:	image.png (38,148 bytes) 2023-08-17 03:46 https://bugs.openfoam.org/file_download.php?file_id=3462&type=bug

Notes
(0013119) kimmo    2023-09-07 06:55	Are you trying to run paraFoam with Mesa (rendering with CPU) or OpenGL provided with GPU driver? I got the same Mesa warnings and found out paraFoam used Mesa instead of OpenGL provided by the GPU driver. I fixed this by modifying $FOAM_ETC/config.sh/paraview . I changed export ParaView_GL=mesa to export ParaView_GL=system This makes the paraFoam to use OpenGL provided by the GPU driver. Hope this helps. Don't know about the bad rendering with Mesa but I wouldn't be surprised if it didn't always work that well especially if you have less powerful CPU.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4014	[OpenFOAM] Bug	minor	always	2023-09-03 22:10	2023-09-05 12:17
Reporter:	blttkgl	Platform:
Assigned To:	henry	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	11
		Target Version:
Summary:	volFieldValue min/max FO crashes with cellZone in parallel
Description:	if the volFieldValue function object is used with min or max operations, it crashes in parallel execution.
Tags:
Steps To Reproduce:	In the controlDict/cavitationVolume function object of the ballValve tutorial (tutorials/compressibleVoF/ballValve), change select all; operation volIntegrate; to select cellZone; cellZone pipes; operation max; and execute Allrun.
Additional Information:
Attached Files:

Notes
(0013114) henry    2023-09-04 11:59	Try this: commit 58f82fccbde862da486a444f9ed6dfc2af6d7bf3
(0013116) blttkgl    2023-09-05 11:53	Thanks, both the tutorial and my own case I was having problems with works fine.
(0013117) henry    2023-09-05 12:17	Resolved in OpenFoam-dev by commit 58f82fccbde862da486a444f9ed6dfc2af6d7bf3 Resolved in OpenFOAM-11 by commit d4e2edb3980bf8f2e18446d75b26f428ebef6ce7

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4010	[OpenFOAM] Patch	minor	have not tried	2023-08-19 08:35	2023-08-19 09:12
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:	suggestion to cutTriTet template class
Description:	If I am not mistaken, areaIntegrateOp can only do area moment but do not second/product moment of area. the constructor takes moment arm data in the form of triangular points and in the function call operator, it takes triangle data. the moment arm is automatically calculated with the moment arm data take from the constructor. I think in this form, it is not possible to provide x^2, yx as a moment arm for the calculation of second/product moment of area. Instead, taking triangle data in the constructor and provide moment arm data in the function call operator could provide further functionalities including the original one. if its usage in the OpenFOAM source code is using just triangle data by providing points on the triangle data, I think this change would not affect that much. if it is possible, then areaIntegrateOp, areaMagIntegrateOp, and volumeIntegrateOp will have similar changes.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	patch.diff (3,031 bytes) 2023-08-19 08:35 https://bugs.openfoam.org/file_download.php?file_id=3464&type=bug

Notes
(0013104) administrator    2023-08-19 09:12	Pending funding

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4008	[OpenFOAM] Bug	minor	always	2023-08-18 05:55	2023-08-18 08:57
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:	incorrect and unused type in primitiveFaceZone.H
Description:	I found that primitiveFaceZone type defined in primitiveFaceZone.H is not matching with the template declaration of PrimitivePatch which has 2 template parameters. I checked older OpenFOAM versions and found that the type has been there since 2.x as far version as I could get. I found that the change to the template parameter list of PrimitivePatch template class has been made in version 7 but the effect seems not propagated to primitiveFaceZone.H. primitiveFaceZone type is not used in anywhere and the header file is not included at all. So, I think the definition better change to match the current parameter list like typedef PrimitivePatch(IndirectList<face>, const pointField&> primitiveFaceZone This correction has the same form as primitivePatch introduced from version 7. I think primitiveFaceZone is an obsolete type and might be removed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0013101) will    2023-08-18 08:57	Removed it. It is never used, as you say, and the "correct" form is already provided by indirectPrimitivePatch. https://github.com/OpenFOAM/OpenFOAM-dev/commit/4e7ee7ed65d556bb132401693a6f8649c0e70bb8

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4006	[OpenFOAM] Bug	minor	sometimes	2023-08-15 12:02	2023-08-16 09:35
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:	dev
		Target Version:
Summary:	pureMixture + multicomponent no longer working in dev
Description:	I noticed that with recent dev multicomponent modules/phases (eg. multicomponentFluid or multicomponentPhaseModel) no longer work if used together with pureMixture thermo. If one tries this, there is immediate segfault. In OF-11 things work, but not anymore in dev. Unfortunately I jumped over many commits, so I don't know if this is due to thermo changes a few weeks back, or the quite recent "Construct Yslicer on demand" commit. The segfault happens inside "GeometricFieldListSlicer". This issue is not severe as one could always use single-component solvers and/or multicomponent solvers with one specie to simulate pure mixtures. With modular solvers this is quite easy nowadays. Alternatively to fixing this the pureMixture support could be removed, but a better error message would be needed.
Tags:
Steps To Reproduce:	Take eg. multicomponentFluid/filter tutorial, comment out clouds, change multicomponentMixture -> pureMixture in physicalProperties and rename N2 -> mixture.
Additional Information:
Attached Files:

Notes
(0013100) will    2023-08-16 09:35	Thanks for the report. Fixed here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/7ab2321a073d6e24a99269f5f4a60f7dedc0effd

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
4002	[OpenFOAM] Bug	minor	always	2023-08-02 13:39	2023-08-02 13:39
Reporter:	Muerio	Platform:	Docker
Assigned To:		OS:
Priority:	normal	OS Version:
Status:	new	Product Version:	11
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Error when running paraview/paraFoam
Description:	Running paraview results in following error: paraview: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
Tags:
Steps To Reproduce:	Run container according to installation information Start Paraview
Additional Information:	Following command fixes the issue: strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3999	[OpenFOAM] Bug	crash	always	2023-07-24 15:14	2023-07-25 09:30
Reporter:	jkau	Platform:	GNU/Linux
Assigned To:	will	OS:	Ubuntu
Priority:	normal	OS Version:	22.04
Status:	resolved	Product Version:	11
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	11
		Target Version:
Summary:	NCC raises fatal error when using in combination with PLIC
Description:	When using PLIC interface comperssion with NCC the solver immediately exits with: [5] --> FOAM FATAL ERROR: [5] The start face is not defined for a nonConformal patch with a non-zero number of faces [5] [5] From function virtual Foam::label Foam::nonConformalFvPatch::start() const [5] in file fvMesh/fvPatches/constraint/nonConformal/nonConformalFvPatch.C at line 98.
Tags:
Steps To Reproduce:	In tutorials/incompressibleVoF/propeller: 1. Iniialize the field with attached setFields dictionary. 2. change div(phi,alpha) scheme to Gauss PLIC interfaceCompression vanLeer 1; 3. run
Additional Information:	happens also with dev and 10
System Description
Attached Files:	setFieldsDict (1,164 bytes) 2023-07-24 15:14 https://bugs.openfoam.org/file_download.php?file_id=3458&type=bug

Notes
(0013084) will    2023-07-25 09:30	Yes, NCC and PLIC/MPLIC are not compatible. I have added an error message which makes this clear. I consider this to have "resolved" the issue. It is not a bug, it is a missing bit of functionality. https://github.com/OpenFOAM/OpenFOAM-11/commit/503f8884c2c51a4f0ea0275f2a89608e402890d1 https://github.com/OpenFOAM/OpenFOAM-dev/commit/d98d2c371adce6bf2224d9149c9ac4bf97d5ab5d Making NCC and PLIC/MPLIC compatible would require a modest development effort, which would need to be paid for. If you wish to do so, please contant CFD Direct (i.e., use https://cfd.direct/contact/ if you are not an existing customer).

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3996	[OpenFOAM] Bug	major	always	2023-07-13 12:07	2023-07-13 12:07
Reporter:	DougG	Platform:	Unix
Assigned To:		OS:	Other
Priority:	high	OS Version:	13.4.1
Status:	new	Product Version:	11
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Followed the installation but something is missing
Description:	I have followed this web page: https://openfoam.org/download/11-macos/ up to step 6. The shell script 'openfoam11-macos' is on my machine and executable; but when I try to launch a docker container, the shell script runs and, with any option but '-h' I simply get the message 'No directory exists:' It's as if there is something that should have happened or that there is something I should have not done which is not clear from the web-page. I have Openfoam10 running, installed the same way, and that launches a docker container each time. My machine is an M1 Mac
Tags:
Steps To Reproduce:	See description above
Additional Information:
System Description
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3995	[OpenFOAM] Bug	minor	sometimes	2023-07-11 20:17	2023-07-12 10:31
Reporter:	jherb	Platform:
Assigned To:	henry	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	11
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	11
		Target Version:
Summary:	wmkdep calculates replacement position wrong
Description:	This bug appeared the first time in a Ubuntu docker container where the Ubuntu/debian package openfoam11 was installed. (It does not happen with the openfoam-dev installation package openfoam-dev (20230707). If in the file "Make/file" of the user library/solver a source file of the installation is used, wmkdep crashes with the following error: Making dependency list for source file setDeltaT.C free(): invalid next size (fast) This is the Make/file: $(FOAM_SRC)/../applications/solvers/foamRun/setDeltaT.C foamRunCoupled.C EXE = $(FOAM_USER_APPBIN)/foamRunCoupled Then running wmake in the corresponding directory produces the above mention error.
Tags:
Steps To Reproduce:
Additional Information:	Debugging wmkdep show the reason for the error: At some point, the path to the dependency file Make/linux64GccDPInt32Opt//opt/openfoam11/src/../applications/solvers/foamRun/setDeltaT.C.dep should be replaced first by $(OBJECTS_DIR)//opt/openfoam11/src/../applications/solvers/foamRun/setDeltaT.C.dep and in a second step by $(OBJECTS_DIR)/$(WM_PROJECT_DIR)/src/../applications/solvers/foamRun/setDeltaT.C.dep. But in the second replacement, the string /opt/openfoam11 (len=15) is shorter than $(WM_PROJECT_DIR) (len=17). (If using the openfoam-dev version, the strings have actually the same length, and the error does not appear). Now in https://github.com/OpenFOAM/OpenFOAM-11/blob/cfbe06828419fdb6440f74bea6a190bc0abd7624/wmake/src/wmkdep.l#L433 the offset for the search string should be calculated. In this case it should be a positive positive number (not 0 as in probably all the other cases). But as searchStart points somewhere behind str, the returned value here is negative. Then the newly assigned searchStart pointer in https://github.com/OpenFOAM/OpenFOAM-11/blob/cfbe06828419fdb6440f74bea6a190bc0abd7624/wmake/src/wmkdep.l#L439 points before the actual string. So to fix this bug, the calculation in line 433 needs to be reversed: const size_t start = searchStart - str;
Attached Files:

Notes
(0013077) henry    2023-07-12 10:31	Thanks for the bug-report and proposed fix, this is a "corner" case we have never come across before, nor has anyone else I guess. Resolved in OpenFOAM-11 by commit 528c1e71cc9af83a4d91d25d7ede64e74649ca2e Resolved in OpenFOAM-dev by commit 70290b3e2db9041df3f6e23f4506534ddf24081e

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3993	[OpenFOAM] Contribution	minor	always	2023-07-04 12:39	2023-07-04 12:39
Reporter:	Chenyao Su	Platform:	GNU/Linux
Assigned To:		OS:	centos
Priority:	normal	OS Version:	7.9.2
Status:	new	Product Version:	10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	A problem was encountered while compiling with source code
Description:	I always get an error when compiling openfoam10 on my server (no network): Final link failed: nonrepresentable section on output. Until the compilation error stops, there is a statement: Final link failed: nonrepresentable section on output. I tried many methods and failed to compile successfully. Below are some screenshots of my compilation process
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	3cc638660c15d3a640b35a668790b71.png (11,898 bytes) 2023-07-04 12:39 https://bugs.openfoam.org/file_download.php?file_id=3450&type=bug 63e6aae924fc2a4e4f17e12f91084d0.png (4,482 bytes) 2023-07-04 12:39 https://bugs.openfoam.org/file_download.php?file_id=3451&type=bug 67d9cf3ba4126a371f87ce4003cd366.png (124,590 bytes) 2023-07-04 12:39 https://bugs.openfoam.org/file_download.php?file_id=3452&type=bug 2378aaad45a347b12d07ff6b9b0ab20.png (8,354 bytes) 2023-07-04 12:39 https://bugs.openfoam.org/file_download.php?file_id=3453&type=bug 8705ad4985375a8338b05be0a654752.png (80,858 bytes) 2023-07-04 12:39 https://bugs.openfoam.org/file_download.php?file_id=3454&type=bug a500e383c3412a1a1686eb80f4ca8d1.png (40,781 bytes) 2023-07-04 12:39 https://bugs.openfoam.org/file_download.php?file_id=3455&type=bug ffe678796fa946de7a7601f2941a185.png (17,283 bytes) 2023-07-04 12:39 https://bugs.openfoam.org/file_download.php?file_id=3456&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3992	[OpenFOAM] Bug	trivial	always	2023-06-28 13:13	2023-06-28 14:21
Reporter:	blttkgl	Platform:	Unix
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:	time instead of userTime in Crank Nicholson Scheme
Description:	I think in line 228 in the Crank Nicholson ddt scheme should return userTime, instead of time: https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/src/finiteVolume/finiteVolume/ddtSchemes/CrankNicolsonDdtScheme/CrankNicolsonDdtScheme.H#L228
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0013071) henry    2023-06-28 14:21	Resolved by commit a8de66f32b26b91a01b66f5b0d339b8e75bdd64f

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3989	[OpenFOAM] Bug	minor	N/A	2023-06-21 19:42	2023-06-27 08:22
Reporter:	xuegy	Platform:	GNU/Linux
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:	Brownian motion force should use cubic distribution
Description:	This previous issue changed the Brownian motion force to spherical distribution https://bugs.openfoam.org/view.php?id=2153. The reporter provided a sketchy class note to replace the equation in a peer-reviewed journal paper. I highly doubt the spherical distribution as 1D random walk is different from 3D (https://en.wikipedia.org/wiki/Random_walk#Relation_to_Wiener_process). You shouldn't use the RMS on a single axis to validate the result from a 3D FVM code. Furthermore, according to Fluent theory guide https://dl.cfdexperts.net/cfd_resources/Ansys_Documentation/Fluent/Ansys_Fluent_Theory_Guide.pdf(page 425) they're using cubic distribution.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	Screen Shot 2023-06-21 at 2.43.36 PM.png (489,586 bytes) 2023-06-21 19:45 https://bugs.openfoam.org/file_download.php?file_id=3446&type=bug

Notes
(0013054) xuegy    2023-06-21 19:45	In case the Fluent theory guide link disappears in the future, I'm attaching a screenshot of the PDF.
(0013055) henry    2023-06-21 20:59	It is not clear what you want changed to what and on what basis. Could you please provide details of the change you want made and a validation case to demonstrate the need for the change?
(0013058) xuegy    2023-06-22 17:20	If you look at the validation case in https://bugs.openfoam.org/view.php?id=2153, it says "deltaT=1e-3" in controlDict which is so wrong. To simulate Brownian motion, the time step must be much smaller than the particle relaxation time, which is rho_p*d^2/(18*mu), approximately 1e-7 seconds from 1000nm particles. Otherwise, the particle simulation is not trustworthy. In this case, if you add the Brownian motion force with an unrealistically large time step, the RMS will be larger than the theory. My suggestion is to revert the changes in BrownianMotionForce.C: https://github.com/OpenFOAM/OpenFOAM-dev/commit/46d69e1deaed6b035b96524a12670ee0602da542. If you want me to create a validation case, it may take me some time because now the Foundation OF is very different from ESI version and I need some time to figure out the new structure.
(0013059) henry    2023-06-22 17:41	If I revert the change the person who wanted it very likely ask of it to be reinstated. Please discuss with the other reporter and come back with a consensus. We will also need a verification case that you both agree upon which clearly shows which form is correct and which is not; we can't simply change the code backwards and forwards on the whim of the reporter. I am surprised that you don't already have a validation case, how can you be sure that the change you request is correct and the current form is incorrect? I don't see how the legacy ESI fork of OpenFOAM is relevant.
(0013062) xuegy    2023-06-23 22:10	Both versions have the same bug. But the source of the bug is here: https://develop.openfoam.com/Development/openfoam/-/commit/ee9e7cf0375147af1e9d57a039ad4f241bad8e4f I made my own simplified Brownian motion force in v2212 by assuming cc=1 and fixed temperature so it can run in icoUncoupledKinematicFoam and I have validated the cubic distribution. Now I'm trying to make a validation case with OpenFOAM-10. However I'm lost in this version (I haven't used the Foundation version since 4.0). I want to make a 3D box with stationary fluid inside. Should I use reactingFoam or something else? Or is there anyway to skip the iteration of the flow field and just run particles with a user-provided velocity and temperature field?
(0013063) henry    2023-06-23 22:49	ESI clearly took the code from the Foundation repository as I made the changes based on the original bug-report. What ESI do with their fork of OpenFOAM is not relevant as they do not contribute to OpenFOAM, they maintain their fork for their commercial purposes.
(0013064) henry    2023-06-23 22:53	It is not clear why you have been using ESI's version of OpenFOAM rather than the official releases from the OpenFOAM Foundation which owns the copyright of the entire OpenFOAM code and licences it open-source under the terms of the GPL. I recommend that you update your cases but as you are so far behind the excellent developments we have made since version 4.0 this will take you some time.
(0013065) xuegy    2023-06-24 05:45	Is there any tutorial case for rhoParticleFoam? This solver can enable BrownianMotion, but I have difficulty setting up a working physicalProperties.
(0013066) xuegy    2023-06-26 16:33	buoyantReactingFoam/reactingFoam doesn't include BrownianMotion like the legacy reactingParcelFoam does. rhoParticleFoam seems like to be the only solver that supports BrownianMotion. However I couldn't set up a working case due to lack of tutorials. It could be another bug since I've tried almost all possible combinations.
(0013067) henry    2023-06-26 16:58	Please discuss your proposed change with the previous reporter to reach a consensus. If it not possible to provide a validation case then we cannot asses which formulation is correct. If there is no consensus on how this model should be implemented and no one is interested in using it we could remove it altogether.
(0013069) henry    2023-06-26 17:37	Please discuss your proposed change with the previous reporter to reach a consensus.
(0013070) will    2023-06-27 08:22	> buoyantReactingFoam/reactingFoam doesn't include BrownianMotion like the legacy reactingParcelFoam does That's not true. It's supported for all relevant cloud types. It's just not in a library that is included by default. That might be an oversight. But, it is easily remedied. If you put `libs ("liblagrangianParcelTurbulence.so");` in your controlDict, then BrownianMotion will be available. The library split between parcel and parcelTurbulence may not be needed any more. Lagrangian used to have a more complicated dependency tree than it has now. We could probably combine them into the same library now (i.e., the parcel library).

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3990	[OpenFOAM] Bug	minor	always	2023-06-22 08:50	2023-06-22 15:08
Reporter:	cgoessni	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:	Test-Function1: table integration wrong for outOfBounds repeat?
Description:	If I use a simple table dictionary for the Test-Function1 function table ( (0 0) (1 1) ); outOfBounds repeat; x0 0; x1 1; nX 2; it would output a value of 1 for the integral from 0 to 1, instead of 0.5.
Tags:
Steps To Reproduce:	Run Test-Function1 with the attached "table" file $ Test-Function1 table
Additional Information:
Attached Files:	table.dat (53 bytes) 2023-06-22 08:50 https://bugs.openfoam.org/file_download.php?file_id=3447&type=bug table (80 bytes) 2023-06-22 08:50 https://bugs.openfoam.org/file_download.php?file_id=3448&type=bug

Notes
(0013057) henry    2023-06-22 15:08	Resolved by commit 3d95d179ead55a15749fd36b5520075790c4d63f

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3961	[OpenFOAM] Bug	major	always	2023-03-04 23:48	2023-06-20 15:34
Reporter:	ZoeSydney	Platform:	Docker desktop 4.17.0 released o
Assigned To:		OS:	macOS Monterey
Priority:	normal	OS Version:	12.6.3
Status:	new	Product Version:	10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Cannot launch openfoam10-macos after installation
Description:	Hi there I have been trying to install &launch openfoam on my laptop for a week. But it seems that something is preventing openfoam10-macos from being launched. Details for the installation: Macbook Pro: macOS Monterey 12.6.3; Memory: 16 GB 1867 MHz DDR3 Docker Desktop 4.17.0 released on 2023-02-27; XQuartz 2.8.5 2023-01-26 ParaView-5.11.0-MPI-OSX10.13-Python3.9-x86_64.pkg I have tried troubleshooting myself but still need help figuring out the problem. I ensured the docker was running in the background when I launched openfoam. I've attached several screenshots. One of them shows that "No directory exists" when I tried to launch openfoam. I'm sure there is a folder named "openfoam" in /Users/Zoo, and Xquartz can recognize the folder.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	Screen Shot 2023-03-05 at 10.26.10 am.png (85,983 bytes) 2023-03-04 23:48 https://bugs.openfoam.org/file_download.php?file_id=3410&type=bug Screen Shot 2023-03-05 at 10.24.50 am.png (64,374 bytes) 2023-03-04 23:48 https://bugs.openfoam.org/file_download.php?file_id=3411&type=bug Screen Shot 2023-03-05 at 10.22.48 am.png (17,955 bytes) 2023-03-04 23:48 https://bugs.openfoam.org/file_download.php?file_id=3412&type=bug Screen Shot 2023-03-05 at 10.19.40 am.png (11,584 bytes) 2023-03-04 23:48 https://bugs.openfoam.org/file_download.php?file_id=3413&type=bug Screen Shot 2023-03-05 at 10.18.03 am.png (23,219 bytes) 2023-03-04 23:48 https://bugs.openfoam.org/file_download.php?file_id=3414&type=bug openfoam10-macos_modified (6,914 bytes) 2023-06-20 15:34 https://bugs.openfoam.org/file_download.php?file_id=3445&type=bug

Notes
(0013053) Chris Barton    2023-06-20 15:34	Hi, I also had this problem and was able to get it to work by modifying the file openfoam10-macos from http://dl.openfoam.org/docker/ I'll attache my modified file below. I called the file openfoam10-macos when I was using it, but uploaded it here as openfoam10-macos_modified for clarity. it's not greatly coded (I've never used docker before) but worked for me... I may have accidentally broken some other functionality so it's probably worth having someone who knows things to have a look at the changes. And there are some unnecessary 'echos' I used to figure out what the variable values were which can be removed. I hope this helps. Chris

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3986	[OpenFOAM] Bug	minor	always	2023-06-16 07:31	2023-06-16 11:10
Reporter:	cgoessni	Platform:
Assigned To:	henry	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	no change required
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	CourantNo and pressure function objects fail in case of compressible flow
Description:	Running CourantNo and pressure function objects for compressible flow simulations fail because the function objects do not request the rho_ field in the fields() function. They would need a similar implementation of fields() function as the age functionObject.
Tags:
Steps To Reproduce:	All crashes are reproducible e.g. with the tutorials/fluid/pitzDaily case. Run the tutorial as-is until the first time step is written. Then: For CourantNo functionObject: 1.) Run "foamPostProcess -func CourantNo -time 0.001" It would crash with: --> FOAM FATAL ERROR:     request for volScalarField rho from objectRegistry region0 failed     available objects of type volScalarField are 0()     From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>]     in file /opt/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 211. For pressure functionObject: 1.) Ensure that rho_ field is required by setting the following in the controlDict/functions:     pressure     {        type pressure;        libs ("libfieldFunctionObjects.so");        calcTotal yes;        calcCoeff no;        pRef 1e5;     } 2.) run "foamPostProcess -time 0.001" --> FOAM FATAL ERROR:     request for volScalarField rho from objectRegistry region0 failed     available objects of type volScalarField are 5 ( pMean pPrime2Mean p p_0 p_0_0 )     From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&) const [with Type = Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>]     in file /opt/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 211.
Additional Information:
Attached Files:

Notes
(0013048) henry    2023-06-16 11:05	> They would need a similar implementation of fields() function as the age functionObject. This would cause them to fail for incompressible cases. Try using the -solver option:     foamPostProcess -solver fluid -func CourantNo
(0013049) henry    2023-06-16 11:09	or     foamPostProcess -field rho -func CourantNo
(0013050) henry    2023-06-16 11:10	User support request.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3987	[OpenFOAM] Bug	trivial	always	2023-06-16 08:56	2023-06-16 10:01
Reporter:	eletrong	Platform:	GNU/Linux
Assigned To:	henry	OS:	Arch Linux
Priority:	normal	OS Version:	Rolling release
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Doxygen does not enter applications/modules
Description:	Doxygen does not enter applications/modules
Tags:
Steps To Reproduce:	$ cd doc/Doxygen $ ./Allwmake -> No doc for the new solvers.
Additional Information:	One should add $(WM_PROJECT_DIR)/applications/modules to the INPUT config parameter in the Doxyfile.
System Description
Attached Files:

Notes
(0013047) henry    2023-06-16 10:01	Resolved by commit 9ef6fc70f0ea17c2a6bc378a703741606dcb6b55

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3962	[OpenFOAM] Bug	minor	always	2023-03-15 15:34	2023-05-30 12:24
Reporter:	cgoessni	Platform:	amd64
Assigned To:		OS:	CentOS
Priority:	normal	OS Version:	7
Status:	new	Product Version:	dev
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	meshToMesh constructor: wrong order of patchMap content?
Description:	According to the documentation, the patchMap HashTable contains pairs of <srgPatchName> <tgtPatchName>. Could it be that the parsing inside meshToMesh constructor does reverse this order? Suggested patch attached.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	diff_meshToMesh_C.txt (656 bytes) 2023-03-15 15:34 https://bugs.openfoam.org/file_download.php?file_id=3415&type=bug

Notes
(0012959) henry    2023-03-15 16:25	It is not clear what documentation you are referring to, nor how to reproduce the problem, or even what the problem is. Could you please provide a more complete bug-report?
(0012960) cgoessni    2023-03-15 19:18	from https://doc.cfd.direct/openfoam/user-guide-v10/mapfields: "The first list is patchMap that specifies mapping of data between pairs of source and target patches that are geometrically coincident, as shown in Figure 5.16. The list contains each pair of names of source and target patch." However, if I map from source patch nameA to target patch nameB, i.e. patchMap (nameA nameB); it would complain that nameB does not exist in source mesh, suggesting that the code reads it in different order than the user guide would suggest.
(0013020) chris    2023-05-22 17:55	The documentation does not mention the order. The verb "contain" does not imply order by the sequence of what follows it. The example was taken from the cavity tutorial where the order is correct for the cases involved: "lid" is from target, "movingWall" from source. https://doc.cfd.direct/openfoam/user-guide-v10/cavity
(0013021) chris    2023-05-22 18:08	I have updated the documentation to make the ordering clear: https://doc.cfd.direct/openfoam/user-guide-v10/mapfields Cache takes 24 hours to update for the pages, so wait 24 hours before checking.
(0013031) cgoessni    2023-05-30 12:24	Thank you for the update. Now it reads very clearly!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3984	[OpenFOAM] Bug	minor	always	2023-05-26 07:14	2023-05-26 07:37
Reporter:	cgoessni	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:	tutorials/mesh/snappyHexMesh: symbolic links broken
Description:	After the recent restructure, the symbolic links for two snappyHexMesh tutorials are broken: tutorials/mesh/snappyHexMesh/iglooWithFridges tutorials/mesh/snappyHexMesh/motorBike
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0013030) henry    2023-05-26 07:37	Resolved by commit dcbe3891543610cf3987faef719f3c4a59fb65cd

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3982	[OpenFOAM] Bug	minor	always	2023-05-22 10:55	2023-05-23 16:42
Reporter:	cgoessni	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:	egrMixture does not correctly consider egr fraction for low fuel mass fractions
Description:	egrMixture assumes that parts of the "unburnt" (i.e. b=1) contain already burnt products. Thus, in https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/src/thermophysicalModels/multicomponentThermo/mixtures/egrMixture/egrMixture.C#L77, just returning the oxidant if the fuel mass fraction is very low is not correct. Instead, the correct fractions of oxidant and products should be returned - return oxidant_; + mixture_ = (1.0 - egr)*oxidant_; + mixture_ += egr*products_; I attached a diff which would make egrMixture more corret.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0013026) henry    2023-05-23 16:42	Resolved by commit 6230721333ab7607aa23fdbfb840822cc44360ad

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3651	[OpenFOAM] Bug	minor	always	2021-03-29 23:23	2023-05-22 17:20
Reporter:	jherb	Platform:	GNU/Linux
Assigned To:	henry	OS:	OpenSuSE
Priority:	normal	OS Version:	12.3
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Using csv files together with binary file format results in error if run in parallel
Description:	Using the following boundary condition, then executing decomposePar and run will result in an error: T boundary condition (excerpt):     innercore     {         type uniformFixedValue;         uniformValue         {             type tableFile;             format csv;             nHeaderLine 0; // number of header lines             refColumn 0; // time column index             componentColumns (1); // data column index             separator ","; // optional (defaults to ",")             mergeSeparators no; // merge multiple separators             file "$FOAM_CASE/constant/T/innercore_T.csv";         }         value uniform 797.15;     } decomposePar produces this:     innercore     {         type uniformFixedValue;         uniformValue tableFile;         uniformValueCoeffs         {             file "$FOAM_CASE/constant/T/innercore_T.csv";             format csv;             nHeaderLine 0;             refColumn 0;             componentColumns List<label> 1(1);             separator ",";             mergeSeparators 0;         }         value nonuniform List<scalar> 0 ;     } This is the error message of buoyantPimpleFoam -parallel: [0] [0] [0] --> FOAM FATAL IO ERROR: [0] Expected a ')' while reading binaryBlock, found on line 50 the word 'separator' [0] [0] file: /GRS/work/hej/OpenFOAM/hej-8/phenix/dissymmetric/top.2nd.001/processor0/9500/T at line 50. [0] [0] From function Foam::Istream &Foam::Istream::readEnd(const char *) [0] in file db/IOstreams/IOstreams/Istream.C at line 109. [0] FOAM parallel run exiting Happens for collated and uncollated file format. Changing the writeFormat to ascii "solves" the problem.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0011956) henry    2021-03-30 11:30	Revolved in OpenFOAM-8 by commit 1c97446d261011178af3ba5e0debe7588fbc18f0 Resolved in OpenFOAM-dev by commit 8fdf4eb6de97f29c710b627d5800ee9e0be7907d

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3981	[OpenFOAM] Bug	minor	always	2023-05-17 12:30	2023-05-17 21:39
Reporter:	blttkgl	Platform:	Unix
Assigned To:	will	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:	Inconsistent NASA polynomial coefficients for air
Description:	I have been having some stability issues with a moving piston-valve setup we've built, where we use a pureMixture mixture model with properties of air taken from the $FOAM_TUTORIALS folder. Upon closed examination, we noticed that the total enthalpy values calculated from the highCpCoeffs provided for air do not align with reference data we create using Cantera. While we do not have high temperatures in our setup, this discrepancy probably affects our enthalpy during PIMPLE iterations, causing instabilities especially during mesh mapping. In an attached figure, you can find a figure that demonstrates the total enthalpy calculated from: 1) Air polynomials under the tutorials folder, 2) Air enthalpy calculated from Cantera using GRI3.0 chemical mechanism for a 21% O2 72% N2 mixture, 3) Our polynomial fit on this curve (provided in attachment thermo.foam) It is probable that these polynomials are taken from literature, fitted for aerodynamics in mind with non-optimal high-end temperature values. We wanted to provide this fix to ensure that somebody else would not make the same mistake and take them directly from the tutorials. As far as I can tell, following tutorials include the polynomial coefficients or air with high end temperature issues: modules/multicomponentFluid/parcelInBox  modules/multicomponentFluid/verticalChannel modules/multicomponentFluid/verticalChannelLTS modules/multicomponentFluid/verticalChannelSteady modules/multiphaseEuler/bubbleColumnEvaporating modules/multiphaseEuler/bubbleColumnEvaporatingReacting modules/multiRegion/CHT/heatExchanger
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	thermo.foam (1,010 bytes) 2023-05-17 12:30 https://bugs.openfoam.org/file_download.php?file_id=3438&type=bug enthalpy_comparison.png (49,490 bytes) 2023-05-17 12:30 https://bugs.openfoam.org/file_download.php?file_id=3439&type=bug

Notes
(0013018) will    2023-05-17 21:39	Thanks for the report. Yes, the data in those cases is clearly unreliable. We also have the fits in `etc/thermoData/thermoData`, but these are optimised for high temperature combustion, and the fit for air starts to breaks down under 300K. Yours is better at the lower temperatures, and only diverges beyond 3000K. On balance, I think your data is the better compromise. I think evaporation at 300K-ish is a more likely use case than acetylene combustion. Pushed here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/a1c85e0771e6f26c1d4ebebaa8ba619ae83e0566

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3979	[OpenFOAM] Patch	minor	always	2023-05-15 14:26	2023-05-15 16:17
Reporter:	cgoessni	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:	fvCellSet::writeFileHeader() does not correctly write number of cells in case of parallel run
Description:	fvCellSet does not correctly write the number of cells of a cell set in the log file in case of a parallel run. The problem is visible when running tutorials/modules/compressibleVoF/ballValve. The mesh has 30400 cells. However, inside postProcessing/cavitationVolume/0/volFieldValue.dat, which is the output of a function that integrates the water vapour fraction over all cells, the second line suggests that the mesh has only 7600 cells. Attached diff would fix the small bug for me.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	diff_fvCellSet.txt (1,966 bytes) 2023-05-15 14:26 https://bugs.openfoam.org/file_download.php?file_id=3437&type=bug

Notes
(0013015) henry    2023-05-15 16:17	Resolved by commit b2d74bfdb4f7fc6b4ee3072694fe696f44e5c69b

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3977	[OpenFOAM] Bug	minor	always	2023-04-29 19:26	2023-04-29 21:48
Reporter:	demichie	Platform:	Unix
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:	volume fraction of dispersed phase in drag model Ergun
Description:	The definition of CdRe for the Ergun drag model is correct only for one dispersed phase, and wrong for more than one. In lines 67-75 of Ergun.C it is computed as     return         (4.0/3.0)        *(             150            *max(1 - continuous, dispersed.residualAlpha())            /max(continuous, continuous.residualAlpha())           + 1.75            *interface_.Re()         ); The numerator of the fraction in the first term of the sum should be the volumetric fraction of the dispersed phase, which is different from (1-continuous) when there are multiple dispersed phases.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0013007) henry    2023-04-29 21:48	Resolved by commit 4c68b4bf5b5a809d2c9e41b2123f3bc89a1f0e40

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3858	[OpenFOAM] Patch	minor	always	2022-07-13 01:56	2023-04-18 09:28
Reporter:	TZirwes	Platform:	GNU/Linux
Assigned To:	will	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	OpenFOAM 10 cannot be compiled with 64 bits labels
Description:	In a couple of places, invalid function calls are generated when compiling OpenFOAM 10 with 64 bit labels. A patch is attached that casts some of the literals ("0", "1" and "-1") into the "label" type to resolve the compiler errors.
Tags:
Steps To Reproduce:	Compile OpenFOAM 10 with 64 bit labels -> compiler errors occur Apply the patch and compile again -> compiles without errors
Additional Information:	Tested on OpenSuse, Ubuntu WSL and RedHat with gcc 7.1 and gcc 11
System Description
Attached Files:	label64.patch (3,256 bytes) 2022-07-13 01:56 https://bugs.openfoam.org/file_download.php?file_id=3324&type=bug

Notes
(0012673) will    2022-07-13 09:29	Thanks for the report. Fixed in version 10 and in dev. https://github.com/OpenFOAM/OpenFOAM-10/commit/d5b54df1766f2f6a6d268a4c8a60cb7499f80348 https://github.com/OpenFOAM/OpenFOAM-dev/commit/eb7b8763c4ea42239e0cf2f0eb5c72857cc7168d

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3970	[OpenFOAM] Bug	minor	have not tried	2023-04-12 01:40	2023-04-13 17:11
Reporter:	handrake0724	Platform:
Assigned To:	will	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	inconsistent behavior of createNonConformalCouples in some mesh in serial and parallel execution
Description:	I am testing NCC for sliding mesh and find that createNonConformalCouples command shows inconsistent message in serial and parallel execution, respectively. In serial execution, the log reads // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Reading "createNonConformalCouplesDict" Create mesh for time = 0 Adding nonConformalCyclic interfaces between patches:     (nonCouple1 nonCouple2) Named:     (nonConformalCouple_on_nonCouple1 nonConformalCouple_on_nonCouple2) With transform:     transformType none; patchToPatch: Calculating couplings between 92228 source faces and 92228 target faces     Source min/average/max coverage = 0.9999999999998507/0.999999999999998/1.000000000000077     Target min/average/max coverage = 0.9999999999997982/0.9999999999999991/1.000000000000153     Source average openness/error/depth/angle = 8.036399968942091e-17/6.970029914210327e-15/1.795228539683142e-15/2.104964404208377e-07     Source max openness/error/depth/angle = 6.170872498989154e-16/2.289950195991059e-13/3.661871450879536e-14/1.909095910416422e-06     193972 couplings calculated in 16.422774s fvMeshStitcher: Connecting Writing mesh to 1e-07 End but parallel execution reads // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Reading "createNonConformalCouplesDict" Create mesh for time = 0 Adding nonConformalCyclic interfaces between patches:     (nonCouple1 nonCouple2) Named:     (nonConformalCouple_on_nonCouple1 nonConformalCouple_on_nonCouple2) With transform:     transformType none; patchToPatch: Calculating couplings between 92228 source faces and 92228 target faces     Source min/average/max coverage = 0.9999999999998507/1.000000023146119/1.000180016634776     Target min/average/max coverage = 0.71307653030402/0.9999507986124163/1.000000000000153     Source average openness/error/depth/angle = 8.031489393100866e-17/7.766498376871098e-06/7.733407289636433e-10/0.0003962600795478927     Source max openness/error/depth/angle = 6.170872498989154e-16/0.4301387904644676/3.99899270311335e-05/24.75136731116615     193900 couplings calculated in 3.430375s fvMeshStitcher: Connecting Writing mesh to 0 End Especially, Source max angle shows quite different order: 1.909095910416422e-06 vs. 24.75136731116615. I have checked tutorial/incompressible/pimpleFoam/RAS/propeller and found the case showed consistent results. pimpleFoam fails to run successfully if I first decompose the mesh and apply createBaffles, splitBaffles followed by createNonConformalCouples while pimpleFoam runs good if I first apply createBaffles, splitBaffles followed by createNonConfomalCouples and then decompose the mesh. I could provide snappyHexMeshDict and geometries but the total size of the files exceeds the limit (2MB).
Tags:
Steps To Reproduce:	Compare the results of the following steps. case 1 a) decompose the mesh b) createBaffles in parallel mode c) splitBaffles in parallel mode d) createNonConformalCouples in parallel mode case 2 a) createBaffles in serial mode b) splitBaffles in serial mode c) createNonConfomalCouples in serial mode d) decompose the mesh
Additional Information:
Attached Files:	NCC_serial.png (397,677 bytes) 2023-04-13 05:55 https://bugs.openfoam.org/file_download.php?file_id=3426&type=bug NCC_parallel.png (538,386 bytes) 2023-04-13 05:55 https://bugs.openfoam.org/file_download.php?file_id=3427&type=bug

Notes
(0012987) will    2023-04-12 14:02    (Last edited: 2023-04-12 14:03)	There should not be a difference, so it might be a bug. To be clear, is this calculation happening at a time when the surface meshes line up exactly? It certainly looks that way in the serial output; an angle of 10^-6 is very small; you'd only get that if the patches were geometrically conformal. Have you updated to the latest patch version of OpenFOAM-10? A number of fixes have been implemented since release last summer. Better yet, have you tried OpenFOAM-dev? If you run `checkMesh -allGeometry` (in dev) in parallel it will write coverage fields into the `postProcessing` subdirectory. What do these look like? Where on the interface is the coverage different from the serial case? As you have determined, our large-ish parallelised tutorials do not show this difference between serial and parallel execution. So, I have no way of reproducing this. I would need the case. If the case is larger than the permitted upload size then you will need to make it available to us via some other file sharing service.
(0012988) will    2023-04-12 14:05	Also, maybe try doing the decompose after `splitBaffles` but before `createNonConfomalCouples` to see if it is actually the parallelisation of the baffles utilities that is to blame in some way.
(0012989) handrake0724    2023-04-12 15:06	As you noted, the surface meshes were geometrically conformal because the patches were generated from face zone by using createBaffles and splitBaffles. The executables for the OpenFOAM-10 were build from the latest patch version from OpenFOAM-10 repository. but I did not tried with OpenFOAM-dev. I will check it tomorrow and let you know the results. I will test it following you advice and let you know them as well. for the mesh, I will upload it on my google drive and share the url to it.
(0012990) handrake0724    2023-04-13 05:55	I have check what you said. 1. the results of doing the decompose after splitBaffles but before createNonConformalCouples does not show any differences from serial execution. So, I think the parallelization of baffles is not the culprit. 2. The command built from OpenFOAM-dev repository showed the same behavior as OpenFOAM-10 repository. 3. the figures of the coverage on the interface are uploaded. As you can see, there are two faces which have coverage value less than 1 on the top of the cylinder.
(0012991) handrake0724    2023-04-13 06:24	For case 1, I might make a mistake. doing the decompose after splitBaffles but before createNonConformalCouples has the same result (24.75136731116615.) as the parallel execution.
(0012992) handrake0724    2023-04-13 06:39	I have uploaded the mesh in my google drive. the link is https://drive.google.com/file/d/1boHFOs9zW1hjonnciK17pG8u6Kq1ZI-e/view?usp=drivesdk
(0012993) will    2023-04-13 17:11	The problem was in createBaffles. It should be fixed by these commits. https://github.com/OpenFOAM/OpenFOAM-dev/commit/5e8d1ff99ed35bc94a6874c185ade17a23e62bae https://github.com/OpenFOAM/OpenFOAM-10/commit/73bdbb2a3c7b82bbe554ca304180b20b6a931591

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3967	[OpenFOAM] Bug	crash	always	2023-03-22 14:07	2023-04-12 12:26
Reporter:	rrossi	Platform:	GNU/Linux
Assigned To:	will	OS:	Centos
Priority:	high	OS Version:	7
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	Case with NCC crashses in parallel
Description:	I'm running a case based on the compressibleInterFoam solver which worked just as fine with any number of processor without NCC. Using NCC, the case runs in parallel only with 2 cores using scotch for decomposition and crashes with larger numbers of cores (4, 48, 96 tested). Also, using 2 cores but the simple method for decomposition the case crashes. Can't attach case because even compressed and with the mesh only it's 4 MB in size. Can I use an external link instead?
Tags:
Steps To Reproduce:	Simply run the compressibleInterFoam solver with scotch method on any number of cores larger than 2
Additional Information:
System Description
Attached Files:	FOAM.err (10,708 bytes) 2023-03-22 15:51 https://bugs.openfoam.org/file_download.php?file_id=3423&type=bug runFoam.log (9,055 bytes) 2023-03-22 15:51 https://bugs.openfoam.org/file_download.php?file_id=3424&type=bug

Notes
(0012971) will    2023-03-22 14:33	Why is the case so large? Is the mesh included? If so, is it possible to reproduce this with a case that we can generate the mesh for? Could you upload a log of the failure? Maybe we can figure it out without needing the case. Have you tried OpenFOAM-dev? If all that fails, then yes, we will provide a mechanism for you to transfer the files to us.
(0012972) rrossi    2023-03-22 15:51	yes the mesh is include. Being a moving mesh case, it would be not straightfoward to create the meshes, merge them, set the initial condition etc etc Attached is the log file and err files I haven't tried the dev yet
(0012973) will    2023-03-23 09:08	> Being a moving mesh case, it would be not straightfoward to create the meshes, merge them, set the initial condition etc etc That's what an ./Allrun script is for. Can you create a script that I (or anyone else) can run that does these pre-processing steps?
(0012984) peksa    2023-04-06 08:59	Without having access to the actual case, I'd make a wild guess that this would work in recent OF-dev version as a bit similar parallel problem I had got fixed by commits some time ago.
(0012985) will    2023-04-06 12:21	@peksa Yes, that seems likely. The hash in the log indicates that the version of OpenFOAM-10 is from shortly after release, and hasn't been updated for bug fixes either. Closing. This is probably fixed, and the reporter hasn't responded for two weeks now. If the problem is encountered on an up-to-date build of dev or version 10 then a new report can be opened. But a case must also be made available (either via a file sharing service, or make it small enough to upload here). If there is no case I will close again as not reproducible.
(0012986) will    2023-04-12 12:25	A very similar crash came up in compiler testing, so whilst I can't be completely sure, I think this is resolved now. See the following commits: https://github.com/OpenFOAM/OpenFOAM-dev/commit/71979accf5d0830de3fa5360b20fa9d37576cbd4 https://github.com/OpenFOAM/OpenFOAM-10/commit/2dce8f82fa4864d242c8f7865dd52aba53e16fda

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3965	[OpenFOAM] Bug	minor	always	2023-03-21 09:52	2023-03-21 21:32
Reporter:	marniemann	Platform:	Unix
Assigned To:	will	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	fpe in data conversion / postprocessing for case with NCC Interface
Description:	When running attached case data conversion / postprocessing using foamToVTK or writeCellCenters fails with a floating point exception at 0.1 seconds of simulation time (i.e. after exactly one revolution of the rotating region).
Tags:
Steps To Reproduce:	run contained Allrun script
Additional Information:	only postprocessing at time 0.1 fails, 0.05 for instance works fine. Moreover, postprocessing does NOT fail for a slightly changed rotation rate.
System Description
Attached Files:	20230321_OF10nccFPE.tar.gz (53,526 bytes) 2023-03-21 09:52 https://bugs.openfoam.org/file_download.php?file_id=3419&type=bug

Notes
(0012968) will    2023-03-21 21:32	Thanks for the report. It's really helpful when the case just runs without manual intervention and clearly reproduces the problem. Fixed in version 10 and in dev. https://github.com/OpenFOAM/OpenFOAM-10/commit/362b7b6bb8eb5c4ac92e12856b3455cdacc1166a https://github.com/OpenFOAM/OpenFOAM-dev/commit/182490e0b20f21f604023e71b975314c2d59004a

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3953	[OpenFOAM] Patch	minor	sometimes	2023-01-25 08:58	2023-01-26 08:58
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:	dev
		Target Version:
Summary:	Fixes for lagrangian parcel liquid models
Description:	I have attached a patch, which fixes a couple of issues: 1. The generic "liquid" liquid does not currently work if used with steady tracking. The problem is that clouds are repeatedly cloned and restored when doing steady tracking and the clone-function in liquid.H calls the default constructor, which in turn calls default constructors of autoPtr. These destroy the contents of the original autoPtrs, which then can't be restored. The patch adds a copy-constructor to liquid, which calls "clone"-functions. Also, when searching the lagrangian codebase for examples of other clone-functions/copy-constructors, I noticed that the scaledForce-model has and incorrect copy constructor, which uses nullPtr. The patch includes a fix for that. 2. The second issue is that the list of carrierIds is not re-sized in phaseProperties reorder-function. This creates out-of-bounds bugs in several places when looping over all liquids and trying to use corresponding carrierId. The bug can be fixed by also re-sizing the carrierIds.
Tags:
Steps To Reproduce:	To reproduce all issues, I have added modified verticalChannelSteady, where H2O has been replaced with a custom liquid specification, air is added as a second liquid and drag is replaced by scaled drag. By default one gets --> FOAM FATAL ERROR: object of type N4Foam9Function1IdEE is not allocated after the first cloud update due to the liquid cloning bug. The other two bugs cause a crash during the second update. The "liquid" air specification is just a dummy to trigger the bug without having to add species to the test case. In real cases the bug happens if one has multiple clouds with different liquids and not all clouds have all liquids specified under their singleMixtureFractionCoeffs such that the resizing is needed.
Additional Information:
Attached Files:	patch.diff (3,019 bytes) 2023-01-25 08:58 https://bugs.openfoam.org/file_download.php?file_id=3395&type=bug verticalChannelSteady.tar.gz (5,975 bytes) 2023-01-25 08:58 https://bugs.openfoam.org/file_download.php?file_id=3396&type=bug

Notes
(0012939) will    2023-01-26 08:58	Yes, this stuff comes up occasionally. Not everything has been tested with cloud clone/restore, and not everything has had copy construction implemented thoroughly. Thanks for the patch. Applied here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/64ce9b2e2563e4be0e38a7f1795d479cb61910f9

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3952	[OpenFOAM] Patch	text	N/A	2023-01-24 12:19	2023-01-24 18:28
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:	Fixes for typos and formatting
Description:	Hi, I have attached a couple of patches which contains fixes to typos and centering of class declarations. As the full diff is quite large, I have also split it to two smaller pieces. All changes are text-only. The files are typos.diff: fixes to typos + formatting of couple of Info statements declarations.diff: fixes class declaration centering fullDiff.diff: typos+declarations+automatic update of copyrights
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	typos.diff (21,675 bytes) 2023-01-24 12:19 https://bugs.openfoam.org/file_download.php?file_id=3392&type=bug declarations.diff (235,565 bytes) 2023-01-24 12:19 https://bugs.openfoam.org/file_download.php?file_id=3393&type=bug fullDiff.diff (389,302 bytes) 2023-01-24 12:19 https://bugs.openfoam.org/file_download.php?file_id=3394&type=bug

Notes
(0012936) henry    2023-01-24 18:28	resolved by commit 00ca8905a058713ff899015fd2548ea2d3b24539

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3950	[OpenFOAM] Bug	minor	always	2023-01-20 16:30	2023-01-21 11:28
Reporter:	Dano62	Platform:	Unix
Assigned To:		OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	new	Product Version:	10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	paraFoam not working after updating Paraview to 5.10.1
Description:	After installing the update to paraview, I can no longer use the paraFoam command to launch Paraview. However, it can be launched using paraFoam -builtin.
Tags:
Steps To Reproduce:	1. Install openFoam 10 on Ubuntu (prior to installing the patch paraFoam worked fine) 2. Intsall patch as per https://openfoam.org/news/paraview-5-10/ to update Paraview to 5.10.1 3. Attempt to launch paraview with the command paraFoam. Receive error message below in additional information. 4. Launch paraview with the command paraFoam -builtin. Paraview launches.
Additional Information:	Error message when attempting to launch 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
System Description
Attached Files:

Notes
(0012933) chris    2023-01-21 09:44	Which version of Ubuntu are you running?
(0012934) chris    2023-01-21 09:59	No need to respond to the previous question. I found that the reader modules did not get compiled on Ubuntu 22.04 and 22.10. Am rebuilding the packs now and will upload to the repository shortly...
(0012935) chris    2023-01-21 11:28	The faulty package has been deleted and replaced. Because it is a replacement with the same version number, I suggest deleting the faulty one: apt purge openfoam10 then do an update of the repository and install the replacement apt update apt install openfoam10

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3942	[OpenFOAM] Bug	text	N/A	2022-12-12 12:07	2022-12-12 18:53
Reporter:	blttkgl	Platform:	Unix
Assigned To:	henry	OS:	Other
Priority:	low	OS Version:	(please specify)
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Typo in engineCompRatio.C
Description:	engineCompRatio.C file under postProcessing/miscellaneous/ has a typo at the header, it should be TDC (top dead center) instead of TCD     "Note that if you have valves and/or extra volumes it will not work,     since it calculates the volume at BDC and TCD."
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012921) henry    2022-12-12 18:53	Resolved by commit d020df456c6265c8759f8dfae5807fa43a9198e2

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3938	[OpenFOAM] Bug	minor	always	2022-11-29 06:58	2022-11-29 14:36
Reporter:	cgoessni	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:	timeActivatedFileUpdate: missing timeToUserTime conversion
Description:	timeActivatedFileUpdate is missing a timeToUserTime conversion. Additionally, the time check might be better if "<=" was used, since with the current version "<", the file update would be one time step too late. Proposed diff attached.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	diff_timeActivatedFileUpdate.txt (650 bytes) 2022-11-29 06:58 https://bugs.openfoam.org/file_download.php?file_id=3376&type=bug

Notes
(0012902) henry    2022-11-29 14:36	Thanks for reporting. Resolved by commit 303c0167045dcd13905abbebaa4c52fc5d912ceb

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3935	[OpenFOAM] Bug	minor	always	2022-11-27 12:12	2022-11-28 14:58
Reporter:	nucerl	Platform:	GNU/Linux
Assigned To:	henry	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Discrepancy on the implementation of the IATE Turbulent Breakup source, Rti
Description:	1 Foam::tmp<Foam::fvScalarMatrix> 2 Foam::diameterModels::IATEsources::turbulentBreakUp::R 3 ( 4 const volScalarField& alphai, 5 volScalarField& kappai 6 ) const 7 { 8 volScalarField::Internal R 9 ( 10 IOobject 11 ( 12 "turbulentBreakUp:R", 13 iate_.phase().time().timeName(), 14 iate_.phase().mesh() 15 ), 16 iate_.phase().mesh(), 17 dimensionedScalar(kappai.dimensions()/dimTime, 0) 18 ); 19 20 const scalar Cti = Cti_.value(); 21 const scalar WeCr = WeCr_.value(); 22 const volScalarField Ut(this->Ut()); 23 const volScalarField We(this->We()); 24 25 forAll(R, celli) 26 { 27 if (We[celli] > WeCr) 28 { 29 R[celli] = 30 2*Cti*Ut[celli]*sqrt(1 - WeCr/We[celli])*exp(-WeCr/We[celli]); 31 } 32 } 33 34 return fvm::Su(R, kappai); 35 } The implementation of the only source term, Rti, is given in the snippet above. It can be seen that the defined 1/ms unit of Rti in line 17 of the snippet is not consistent with the implemented unit in line 30 which is 1/ms}. It can also be seen in line 34 of the snippet that the Su() function is utilized which treats the source term explicitly by modifying the source coefficients. The returned unit of the function is m/s*1/m = 1/s which is $not consistent with the other sink terms and the rest of the Interfacial Curvature Transport Equation (ICTE) implemented in OpenFOAM. The rate comparison is shown in the Snap#1 of the provided snaps after canceling out the long common terms in the reference and implemented equations. The effect of the above-mentioned unit inconsistencies can be seen in the rate comparison which revealed that the implemented Rti is not consistent with the reference model [Ishii et. al, 2005]. Just considering the reference model, the required model can be derived as shown in Snap#2. It looks like the discrepancy comes from a missing length of a unit in the denominator (i.e. d: Sauter Mean Diameter) and a different constant. Changing the current model to the required one ensures that the local unit of Rti is consistent with the unit of other source terms which is 1/s and the unit of the returned value consequently becomes 1/ms which is also consistent with rest of the terms in the implemented ICTE. The discrepancy among the sources indicates an error unless it is fixed somewhere else in the code for Rti that I am not aware. It should also be noted the required form given in Snap#2 was also used in twoPhaseEulerFoam solver in OpenFOAM V7 (https://github.com/OpenFOAM/OpenFOAM-7/blob/master/applications/solvers/multiphase/twoPhaseEulerFoam/twoPhaseSystem/diameterModels/IATE/IATEsources/turbulentBreakUp/turbulentBreakUp.C). However, the Su() function was not used to calculate Rti in OpenFOAM V7. I set up a test case to see the difference between the two models shown in Snap#2. The required model in Snap#2 is implemented to OpenFOAM V10 as shown in lines 24 and 32 of the snippet given in the Steps To Reproduce section (ignore the newIATE). However, the effect was negligible. Regardless of the implementation results, further investigation is needed to clarify TI modeling.
Tags:
Steps To Reproduce:	1 Foam::tmp<Foam::fvScalarMatrix> 2 Foam::diameterModels::newIATEsources::turbulentBreakUp::R 3 ( 4 const volScalarField& alphai, 5 volScalarField& kappai 6 ) const 7 { 8 volScalarField::Internal R 9 ( 10 IOobject 11 ( 12 "turbulentBreakUp:R", 13 newiate_.phase().time().timeName(), 14 newiate_.phase().mesh() 15 ), 16 newiate_.phase().mesh(), 17 dimensionedScalar(kappai.dimensions()/dimTime, 0) 18 ); 19 20 const scalar Cti = Cti_.value(); 21 const scalar WeCr = WeCr_.value(); 22 const volScalarField Ut(this->Ut()); 23 const volScalarField We(this->We()); 24 const volScalarField& d(newiate_.d()()); //ebicer 25 26 forAll(R, celli) 27 { 28 if (We[celli] > WeCr) 29 { 30 R[celli] = 31 //2*Cti*Ut[celli]*sqrt(1 - WeCr/We[celli])*exp(-WeCr/We[celli]); 32 (1.0/3.0)*Cti/d[celli]*Ut[celli]*sqrt(1 - WeCr/We[celli])*exp(-WeCr/We[celli]); //ebicer 33 } 34 } 35 36 return fvm::Su(R, kappai); 37 }
Additional Information:
System Description
Attached Files:	Snap#1.png (113,841 bytes) 2022-11-27 12:12 https://bugs.openfoam.org/file_download.php?file_id=3371&type=bug Snap#2.png (43,263 bytes) 2022-11-27 12:12 https://bugs.openfoam.org/file_download.php?file_id=3372&type=bug IATE General Form.png (161,601 bytes) 2022-11-28 12:40 https://bugs.openfoam.org/file_download.php?file_id=3375&type=bug

Notes
(0012886) henry    2022-11-27 20:29    (Last edited: 2022-11-27 20:38)	I agree that the dimensions are incorrect but by a factor of sqr(kappai) rather than 1/d (I am not sure what "d" is in the code snippet). Also according to eq. 11-163 in Mamoru Ishii, Takashi Hibiki Thermo-Fluid Dynamics of Two-Phase Flow Second Edition the expression should be divided by 18 rather than 3 so I think the correct expression is:             R[celli] =                 (Cti/18)*Ut[celli]*sqr(kappai[celli])                *sqrt(1 - WeCr/We[celli])*exp(-WeCr/We[celli]);
(0012887) nucerl    2022-11-27 23:36	Dear Henry, I am not sure how the unit sqr(kappai) missing since the local R (dimensionedScalar(kappai.dimensions()/dimTime, 0)) is 1/ms and the returned R (fvm::Su(R, kappai)) is in m/s*1/m = 1/s. kappai has the unit of 1/m. What am I missing here? All the literature of IATE is combined in Ishii's book, however the details of the derivations are usually missing. Although it is the same in one-group IATE, the equation you are referring to is for two-group IATE. I'd recommend checking Wu et. al, 1998 (One-group interfacial area transport in vertical bubbly flow) or Dr. Kim's thesis in 1999 (Interfacial Area Transport Equation and Measurement of Local Interfacial Characteristics) for more details. Back to the expression you provided, the 1/18 comes from how the sphericity (shape factor) is defined for assuming the bubbles to be in spherical shape, i.e. 1/36*PI(). However, please remember that the expression is for IATE not ICTE which is implemented in OpenFOAM. The "d" in the snippet refers to the Sauter mean diameter (shown below) which is updated after the kappaiEqn is solved in IATE.C. Foam::tmp<Foam::volScalarField> Foam::diameterModels::IATE::d() const {     return d_; } If you want to calculate R[celli] in terms of kappai but not d then the you can replace d with 6/k which ensures both the units and the constant. Please see the equations 4 and 19 through 22 in the following link (https://snip.mathpix.com/nucerl/notes/11e456fc-17f4-427c-ab48-b927c863844a) for detailed explanation. Thank you, Erol.
(0012889) henry    2022-11-28 07:28    (Last edited: 2022-11-28 08:44)	fvm::Su(R, kappai) returns R as an explicit source which should and does have the units of kappai/time according to             R[celli] =                 (Cti/18)*Ut[celli]*sqr(kappai[celli])                *sqrt(1 - WeCr/We[celli])*exp(-WeCr/We[celli]); From the references I have the term would be divided by 18. eq. 11-163 in Mamoru Ishii, Takashi Hibiki Thermo-Fluid Dynamics of Two-Phase Flow Second Edition I cannot work out the correspondence between your notes and the references I have.
(0012890) henry    2022-11-28 08:48	Resolved in OpenFOAM-dev by commit 3aea199ebebd440e0032ad40e61e6c968b248ba5
(0012893) nucerl    2022-11-28 12:40	It's still not correct. Regardless of the explicit/implicit treatment, the IATE source must return 1/ms. The partial differential equation (dk/dt) has a unit of 1/ms. As I already mentioned, the term having a factor of 1/18 does not mean we can directly use it. OpenFOAM does not solve for interfacial are concentration (ai), it solves for interfacial curvature (kappai). You can see this in the implementation of the sink terms as well; Random Collision (Rrc) and Wake Entrainment (Rwe). The sources in the uploaded image are the same as your reference but the implementation is different. For the Turbulent Breakup, there are 2 ways: 1) Using kappai:             R[celli] =                 (Cti/18)*Ut[celli]*kappai[celli]                *sqrt(1 - WeCr/We[celli])*exp(-WeCr/We[celli]); 2) Using d_: const volScalarField& d(iate_.d()());             R[celli] =                 (Cti/3)*Ut[celli]/d[celli]                *sqrt(1 - WeCr/We[celli])*exp(-WeCr/We[celli]);
(0012894) henry    2022-11-28 13:54	The dimensions of                (Cti/18)*Ut[celli]*kappai[celli]                *sqrt(1 - WeCr/We[celli])*exp(-WeCr/We[celli]); are 1/s, but R has dimensions of 1/ms so your proposed expression is incorrect.
(0012896) henry    2022-11-28 13:57	I don't agree with your assessment of the 1/18.
(0012897) nucerl    2022-11-28 14:11	From my understanding the internal R should have the unit of 1/s and once it’s multiplied by kappai through Su() then source R will have the unit of 1/ms. This is how it is done for the Rrc source as well. Though it uses implicit source treatment, Sp(). So, unless Su() somehow multiplies R with kappai in a way that I don’t understand, then I don’t know why the defined unit of R[celli] should be 1/ms instead of 1/s.
(0012899) henry    2022-11-28 14:18    (Last edited: 2022-11-28 14:31)	Where in Su() is R multiplied by kappai?
(0012900) nucerl    2022-11-28 14:34	I guess I have a misunderstanding of what return fvm::Su(R, kappai); does. I think that’s where my confusion comes from.
(0012901) henry    2022-11-28 14:58	Resolved by commit 3aea199ebebd440e0032ad40e61e6c968b248ba5

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3936	[OpenFOAM] Bug	minor	always	2022-11-27 12:30	2022-11-28 14:17
Reporter:	nucerl	Platform:	GNU/Linux
Assigned To:	henry	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	The implemented Weber Number (We) in the IATE model should be a function of Turbulent Fluctuation Velocity, Ut
Description:	1 Foam::tmp<Foam::volScalarField> Foam::diameterModels::IATEsource::We() const 2 { 3 return 4 otherPhase().rho()*sqr(Ur())*phase().d()/sigma(); 5 } The returned We in IATEsource.C seems be a function of Relative Velocity, Ur, however in the actual reference model it should be a function of Turbulent Fluctuation Velocity, Ut. In general, Ut is generally used in the We number. Though numerically it does not make a huge difference for a specific case shown in the uploaded screenshot below, the correct form should be implemented for lower We cases.
Tags:
Steps To Reproduce:	1 Foam::tmp<Foam::volScalarField> Foam::diameterModels::IATEsource::We() const 2 { 3 return 4 otherPhase().rho()*sqr(Ut())*phase().d()/sigma(); //ebicer 5 }
Additional Information:
System Description
Attached Files:	We#1.png (266,829 bytes) 2022-11-27 12:30 https://bugs.openfoam.org/file_download.php?file_id=3373&type=bug We#2.png (274,509 bytes) 2022-11-27 12:30 https://bugs.openfoam.org/file_download.php?file_id=3374&type=bug

Notes
(0012885) henry    2022-11-27 19:43	The current implementation is exactly according to the specification provided by the sponsor of the project. However as you point out the turbulent eddy impaction term should use the turbulent Weber number not the relative velocity Weber number which is appropriate for bubble breakup due to shearing off, according to Mamoru Ishii, Takashi Hibiki Thermo-Fluid Dynamics of Two-Phase Flow Second Edition I will refer this proposed change to the sponsor.
(0012891) henry    2022-11-28 08:49	Resolved in OpenFOAM-dev by commit 3aea199ebebd440e0032ad40e61e6c968b248ba5
(0012898) henry    2022-11-28 14:17	Resolved by commit 3aea199ebebd440e0032ad40e61e6c968b248ba5

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3934	[OpenFOAM] Bug	major	always	2022-11-25 21:57	2022-11-25 22:48
Reporter:	peksa	Platform:	Linux
Assigned To:	henry	OS:	Centos
Priority:	normal	OS Version:	7
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	ChemistryModel compilation issue
Description:	While compiling a fresh clone of OF-dev, ChemistryModel classes throw the following error: In file included from lnInclude/chemistryModel.H:327:0,                  from chemistrySolver/chemistrySolver/chemistrySolvers.C:27: lnInclude/chemistryModel.C: In member function 'virtual Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::chemistryModel<ThermoType>::tc() const': lnInclude/chemistryModel.C:460:73: error: expected primary-expression before '>' token      const volScalarField& rho = this->mesh().lookupObject<volScalarField> ... ... I compiled of-dev succesfully a few days ago so probably this is related to the latest commits.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012879) henry    2022-11-25 22:13	Try with this: commit 96cf91b5bb69f8aa18335927f638b4d0ef447ac1 Author: Henry Weller <http://cfd.direct> Date: Fri Nov 25 22:11:58 2022 +0000     chemistryModel: Updated for clang
(0012880) peksa    2022-11-25 22:34	The new commit fixed the issue. Thank you. For clarification, I'm having GCC 5.4.0 and openmpi-1.10.7 as an environment.
(0012881) henry    2022-11-25 22:47	That is an old gcc version, you might want to consider upgrading.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3931	[OpenFOAM] Bug	minor	always	2022-11-11 22:05	2022-11-22 02:00
Reporter:	ningli	Platform:	GNU/Linux
Assigned To:		OS:	RHEL/CentOS/Rocky Linux
Priority:	normal	OS Version:	8.x 9.x
Status:	new	Product Version:	10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	OpenFOAM-10 undefined symbols while compiling with Clang/AOCC
Description:	We experienced link time errors while building OpenFOAM-10 with the Clang compiler or the AOCC compiler which is based upon Clang. This applies to both vanilla Clang (version 13/14 assessed) and AOCC 3.2/4.0. A typical error looks like: make[1]: Leaving directory '/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/applications/solvers/basic' wmake combustion make[1]: Entering directory '/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/applications/solvers/combustion' wmake chemFoam make[2]: Entering directory '/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/applications/solvers/combustion/chemFoam' clang++ -std=c++14 -m64 -pthread -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=64 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-undefined-var-template -O3 -march=znver3 -DNoRepository -ftemplate-depth-100 -I/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/src/physicalProperties/lnInclude -I/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/src/thermophysicalModels/specie/lnInclude -I/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/src/thermophysicalModels/reactionThermo/lnInclude -I/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/src/thermophysicalModels/basic/lnInclude -I/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/src/ODE/lnInclude -I/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/src/thermophysicalModels/chemistryModel/lnInclude -I/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/src/finiteVolume/lnInclude -I/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/src/meshTools/lnInclude -IlnInclude -I. -I/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/src/OpenFOAM/lnInclude -I/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/src/OSspecific/POSIX/lnInclude -fPIC -L/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/platforms/linux64ClangDPInt64Opt/lib/dummy -lPstream /home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/platforms/linux64ClangDPInt64Opt/applications/solvers/combustion/chemFoam/chemFoam.o -L/home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/platforms/linux64ClangDPInt64Opt/lib \     -lchemistryModel -lfiniteVolume -lmeshTools -lOpenFOAM -ldl \      -lm -o /home/ningli12/apps/OpenFOAM/org-10/AOCC+OpenMPI/OpenFOAM-10/platforms/linux64ClangDPInt64Opt/bin/chemFoam ld.lld: error: undefined symbol: Foam::fluidReactionThermo::New(Foam::fvMesh const&, Foam::word const&) >>> referenced by chemFoam.C The key problem here is that the LLVM 'lld' linker do not handle indirect shared library dependencies. A workaround is to use the GNU system linker by specifying '-Xlinker --add-needed -fuse-ld=ld' in 'LINKEXE' as '--add-needed' (also the equivalent '--copy-dt-needed-entries' flag) has the effect of recursively searching those indirect referenced shared libraries. However, this only works if 'ld.bfd' is the system linker. 'ld.gold' and 'lld' do not support this function. Alternatively I would have to patch the Make/options files of about 25 solvers/utilities with additional -l flags to get them linked properly with 'ld.gold' or 'lld'. I am aware of the decade old discussions in https://bugs.openfoam.org/view.php?id=685 on a similar subject. Do you have new opinions on how this should be dealt with after all these years?
Tags:
Steps To Reproduce:	Following the standard build procedure and using the rules defined in OpenFOAM-10/wmake/rules/linux64Clang/ is just fine. I had to add -L\$(FOAM_LIBBIN)\/dummy -lPstream to the LINKEXE flag too to avoid problems building some solvers.
Additional Information:
System Description
Attached Files:

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3933	[OpenFOAM] Bug	trivial	always	2022-11-18 06:40	2022-11-18 08:45
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:	DebugVar("**********"); in interfaceSaturationTemperatureModelNew.C
Description:	There is a stray DebugVar-printout in interfaceSaturationTemperatureModelNew.C https://github.com/OpenFOAM/OpenFOAM-dev/blob/b36d8fca44936739d90a8f05371b35c7341b19f9/applications/solvers/modules/multiphaseEuler/interfacialCompositionModels/interfaceSaturationTemperatureModel/interfaceSaturationTemperatureModelNew.C#L39
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0012874) will    2022-11-18 08:45	Thanks for spotting. Fixed. https://github.com/OpenFOAM/OpenFOAM-dev/commit/b7188171645a7e6785f1c3fa9ec777dc267ce590

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3929	[OpenFOAM] Bug	crash	always	2022-11-09 10:07	2022-11-10 14:51
Reporter:	maHein	Platform:	Unix
Assigned To:	henry	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	interFoam freezes with empty processors
Description:	interFoam freezes at the first time step, when run in parallel with at least one empty processor (e.g. processor with zero cells). There is no error message, it justs keeps running after calculating the Courant number but never continues any further. In contrast, simpleFoam is able to run the exact same case in parallel. At first, this problem can easily mitigated by adjusting the decomposeParDict, so no processor has zero cells. However, I have one case with dynamic mesh (refiner + distributor), where the distributor actually leads to a processor with zero cells during runtime and thus a crash/freeze. Maybe this can be considered user error. However, since there is no error message it can be very hard to tackle this issue for a user.
Tags:
Steps To Reproduce:	I have attached a simple 2D case. Just run the Allrun script.
Additional Information:
System Description
Attached Files:	exampleCase.zip (290,691 bytes) 2022-11-09 10:07 https://bugs.openfoam.org/file_download.php?file_id=3370&type=bug

Notes
(0012869) henry    2022-11-09 10:42	Can you provide funding for this development? https://openfoam.org/news/funding-2023/
(0012870) maHein    2022-11-10 08:48	I expect this to be a bug which can be fixed easily. The error seems to come from the alphaCourantNo.H, which is called in interFoam.C. Here, in line 40 there is a if-statement checking whether the processor mesh has any internal faces:     if (mesh.nInternalFaces()) Commenting out this line fixes the issue. So why does this case run with pimpleFoam without error? Here, the CourantNo.H is called to compute the Courant number. However, this file has no if-statement checking for internal faces, although the rest of the calculation is similar to alphaCourantNo.H.
(0012871) henry    2022-11-10 08:53	Is your organisation interested in funding OpenFOAM maintenance?
(0012872) henry    2022-11-10 14:51	Resolved in OpenFOAM-dev by commits e1c0207695f93a9a2feadb720c10ffff1cb6c9ce and f088d89127dc462266907b05a75ec021f3a40047

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3928	[OpenFOAM] Bug	major	always	2022-11-08 13:05	2022-11-09 09:32
Reporter:	maHein	Platform:	Unix
Assigned To:	henry	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	dynamicMesh: refiner does not write refinementHistory correctly
Description:	When using adaptive mesh refinement, it is vital to have the refinement history in case of restarting a simulation. This field 'refinementHistory' can be written out to the polyMesh folder by the refiner with the bool 'dumpLevel' in dynamicMeshDict. However, since OpenFOAM 10 this does not work reliably anymore due to the following reason: in line 1681 of fvMeshTopoChangersRefiner.C, there is a if-statement that this field is only written if the mesh topology has actually changed in the current time step, e.g. the mesh was refined: if (mesh().topoChanged())
Tags:
Steps To Reproduce:	This behaviour can easily be reproduced taking any tutorial case with adaptive mesh refinement. For example, damBreakWithObstacle: Original setup: here, the refineInterval in dynamicMeshDict is set to 1, so refinement takes place every time step and thus the refinementHistory is written out every writeInterval (here 0.02, 0.04, 0.06, 0.08, and so on). New setup: changing refineInterval in dynamicMeshDict to 4, suddenly the refinement history is not written out at every writeInterval, instead only at 0.02, 0.08, ... Time step 0.04 and 0.06 are omitted, because the mesh was not refined in those specific time steps. This way, when restarting at 0.04 or 0.06, already refined cells get refined again because the refiner does not know they were already refined.
Additional Information:	This behaviour can probably be fixed by removing the if-statement in line 1681 of fvMeshTopoChangersRefiner.C because in OpenFOAM 9 there was no such statement in the dynamicRefineFvMesh.C.
System Description
Attached Files:

Notes
(0012863) henry    2022-11-08 16:10	> This behaviour can probably be fixed by removing the if-statement in line 1681 of fvMeshTopoChangersRefiner.C Presumably if you make this change the refinement history will be written even if at has not changed since the last time it was written.
(0012864) maHein    2022-11-08 16:22	That is correct and the way it was working in OpenFOAM 9. The current implementation forces the user to either set refineInterval to 1 or risk time folders which cannot be restarted as the refinement history is missing.
(0012865) henry    2022-11-08 16:32	Try this in OpenFOAM-dev  commit 6d74f7063751722b83e9bc6b2e0953fa4a65c368 Author: Henry Weller <http://cfd.direct> Date: Tue Nov 8 16:27:18 2022 +0000     fvMeshTopoChangers::refiner: Added changedSinceWrite_          which is set true if the mesh refinement changed since the last time the     refinement history was written so that it can be written only at the following     write time. if it proves robust I can make the same change to OpenFOAM-10
(0012866) maHein    2022-11-09 09:19	The commit works fine for the tutorial cases and should fix the issue.
(0012867) henry    2022-11-09 09:32	Resolved in OpenFOAM-10 by commit acd844182f00103a8d6b6b45dc6de2c388a4f660 Resolved in OpenFOAM-dev by commit 6d74f7063751722b83e9bc6b2e0953fa4a65c368

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3923	[OpenFOAM] Bug	minor	always	2022-11-02 10:03	2022-11-08 09:48
Reporter:	S3bT	Platform:	GNU/Linux
Assigned To:	will	OS:	Ubuntu
Priority:	normal	OS Version:	22.04
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Filter tutorial not working as expected
Description:	When running tutorials/modules/multicomponentFluid/filter one first encounters two sucessive errors: --> FOAM FATAL IO ERROR: keyword mu is undefined in dictionary "/media/sebastian/CFD-data/filterDev/constant/cloudProperties/solution/interpolationSchemes" --> FOAM FATAL IO ERROR: keyword kappa is undefined in dictionary "/media/sebastian/CFD-data/filterDev/constant/cloudProperties/solution/interpolationSchemes" which are easily cured by changing "thermo:mu" and "thermo:kappa" in /constant/cloudProperties to "mu" and "kappa" respectively. After that, the case runs, however not as expected. In /constant/cloudProperties it is specified that the cyclics are supposed to be type rebound, which used to be a workaround to generate patches that act as semi-permeable barriers in the sense that fluid may pass but particles may not. However, the particles pass right through the patches. I suspect that the cyclic property is ranked higher than the rebound condition.
Tags:
Steps To Reproduce:	Run tutorials/modules/multicomponentFluid/filter/Allrun
Additional Information:	I tried other OpenFOAM versions down to version 7 but the problem persists in all releases since 7.
System Description
Attached Files:	filter.png (130,414 bytes) 2022-11-02 10:03 https://bugs.openfoam.org/file_download.php?file_id=3361&type=bug

Notes
(0012838) henry    2022-11-02 10:17	> When running tutorials/modules/multicomponentFluid/filter one first encounters two sucessive errors: I don't get this error, in fact entries "thermo:mu" and "thermo:kappa" do no exist in any OpenFOAM-dev tutorials: git grep "thermo:mu" and git grep "thermo:kappa" return nothing and the case runs to completion.
(0012839) S3bT    2022-11-02 10:37	You're right. I just updated the dev line and the error no longer appears, as it has been fixed a couple of days ago in commit "87a0b8a". However, the particles still pass through the filter walls (cyclics), which I think is not intended as per the definitions in /constant/cloudProperties .
(0012840) henry    2022-11-02 10:57	> as it has been fixed a couple of days ago in commit "87a0b8a". This is not a fix, it is the complete development including the update of the tutorials.
(0012841) S3bT    2022-11-02 11:20	Ok, I understand. The errors are probably a problem I encountered because of a mismatch in the version of the tutorial case and my version of OpenFOAM dev. The problem I am actually concerned about is the particles passing through the cyclics for the filter tutorial. The cyclics - to my understanding - are only generated to create a patch to assign a rebound condition for the lagrangian particles. Since they don't rebound but pass right through (see attached picture) I don't see an option to create a particle boundary anymore that allows the flow to pass but not particles.
(0012842) S3bT    2022-11-02 11:23	PS: I reran the case with the very newest versions of the tutorial and OpenFOAM dev and particles still pass through the cyclics.
(0012843) will    2022-11-02 15:51    (Last edited: 2022-11-02 15:55)	What you want is incompatible with report https://bugs.openfoam.org/view.php?id=2458. In this case, the reporter wants coupled patches to be excluded in all circumstances, so that regex settings for other patches is convenient. > to generate patches that act as semi-permeable barriers in the sense that fluid may pass but particles may not The problem with this is you end up with particles rebounding on a surface whilst experiencing a drag force pushing them into that surface. Ultimately, the particles reach an infinite collision frequency and the simulation grinds to a halt. ... I guess you could have something similar to finite volume's "patchType" specifier which indicates explicitly that the user intends to override the default/automatic/constrained interaction. Is this worth adding for scenarios like this? I'm minded to say no, and go further and say that particle interactions with all constraint patches (symmetry, wedge, etc..., as well as cyclic) are fixed and not overridable. If you want to do something odd, like rebound from an internal surface, then you can use a cloud function object to achieve this.
(0012847) S3bT    2022-11-03 12:15	> The problem with this is you end up with particles rebounding on a surface whilst experiencing a drag force pushing them into that surface. Ultimately, the particles reach an infinite collision frequency and the simulation grinds to a halt. You are right, this is a problem I have not thought about yet, However, this is only true if the particle velocity and flow velocity are aligned. For cases like a fluidized bed, where the velocities at the barrier are opposite, this should not become a problem. ... I'm not quite sure what you mean when you say I can realize a rebound off an internal surface with a cloud function object. Do you mean to use the class as a template and create my own function object? Because I am not aware of any cloud function object that would do this... I do realize though that this is not a discussion about a bug anymore. For clarity purposes of the tutorial, I think it would be beneficial though if "(walls|cyc.*)" {     type rebound;  } would be changed to walls {     type rebound;  } in constant/cloudProperties. That way it becomes clear that particles are not supposed to rebound off the cyclics.
(0012862) will    2022-11-08 09:48    (Last edited: 2022-11-08 09:48)	OK, yes, if the carrier velocity opposes another force (i.e., gravity) then this makes quite a lot more sense. The bottom of a fluidised bed is a sensible place to apply a model like this. It seems to me that without the rebound on the cyclic, the filter case doesn't demonstrate anything useful beyond any of the other tutorials. So, I think, the obvious way to resolve this is just to delete it. Done here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/9a4bcbf7f4daa6d0443c02bc30c26d5be33fb712 Indeed, an appropriate cloud function does not currently exist, and would have to be written. I appreciate that the Lagrangian library does not make this process convenient. On reflection, I'm not sure if this is the best way forward. A "patchType"-like specifier might be neater. I would have to think about it. In any case, either would require development effort, which would have to be paid for. If you want to go this route, please contact us: https://openfoam.org/contact

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3919	[OpenFOAM] Bug	minor	always	2022-10-21 13:03	2022-11-06 19:07
Reporter:	manahara	Platform:	GNU/Linux
Assigned To:	henry	OS:	OpenSuSE
Priority:	normal	OS Version:	13.2
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	RE: 0003894: Mesh refiner cannot access rho_U field from objectRegistry
Description:	Issue previously reported in https://bugs.openfoam.org/view.php?id=3894 resolved by commit 30eb5e28e65d359dbe8c350b9073dcd492172904 I checked this earlier and works fine for first-order ddt schemes but still throws the unable to find rhoU_0 error when a second-order ddt scheme is used.
Tags:
Steps To Reproduce:	Run the aachen bomb tutorial as defined in issue #0003894, but change ddt scheme to backward.
Additional Information:
System Description
Attached Files:

Notes
(0012822) henry    2022-10-21 15:13	Correct, 2nd-order ddt schemes are not currently or previously supported with mesh refinement and other topology changes. It would take some careful thought and significant development effort to resolve this limitation, if you have budget for this work please contact CFD Direct.
(0012823) henry    2022-10-21 15:14	Pending funding.
(0012861) henry    2022-11-06 19:07	Resolved by commit 731b741b510a0bc7f9f74c33bbe71a36facc19a3

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3926	[OpenFOAM] Bug	minor	always	2022-11-04 08:42	2022-11-04 10:14
Reporter:	Apanasevich	Platform:	Unix
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:	Module multiphaseEuler: double entry in functionObjects/Make/options for lmultiphaseMomentumTransportModels
Description:	Identical entries in functionObjects/Make/options: see LIB_LIBS, lines 19 and 22
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012854) henry    2022-11-04 10:14	Resolved by commit 2180ed5c6ca1734a80c7254a196f0028253cfad6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3922	[OpenFOAM] Bug	minor	always	2022-11-02 08:39	2022-11-03 15:57
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:	Bug with fieldAverage together with foamPostProcess
Description:	Following this commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/65b7f628577fbbcb18d8fb7f686183f4ba0b0e3d the test/postProcessing/channel no longer works because fieldAverage is not able to find kMean from the registry. The reason for the bug is quite subtle: foamPostProcess constructs functionObjects before solver, so turbulence models are not available during construction of fieldAverage. This means that k-field is not available, so kMean is not added to registry. However, when actually calculating averages, k is in the registry and fieldAverage assumes that kMean also exist. When running a solver, functionObjects are constructed at the beginning of the time loop so turbulence fields etc. are already there. And before the commit, initialisation of fieldAverage was done later just when starting to calculate the averages. There would be several ways to fix this, but I was thinking would it be best to check for functionObject::postProcess and if true, don't do anything. Even before the commit, the postProcess would destroy averaging data because fieldAverage would try to read properties from startTime and fail resulting to overwriting the mean fields.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0012837) tniemi    2022-11-02 08:53	So I would propose fieldAveraging should check functionObject::postProcess in read, execute and write and skip if true. Possibly write a warning like https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/src/functionObjects/field/ddt/ddt.C
(0012853) henry    2022-11-03 15:57	Resolved by commit ee4f05411d2c3046e3a6fcc557674bc657183785

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3918	[OpenFOAM] Bug	crash	random	2022-10-21 11:06	2022-10-24 10:18
Reporter:	lorenzotrevisan	Platform:	x86_64
Assigned To:	henry	OS:	Slackware64
Priority:	normal	OS Version:	15.0
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	Strange behavior with eIcoTabulated
Description:	Trying to consider water tabulated properties, I'm experiencing strange behavior with eIcoTabulated that causes crash.
Tags:
Steps To Reproduce:	e.g.1: copy tutorials/multiphase/compressibleMultiphaseInterFoam/laminar/damBreak4phase/ and substitute ./constant/physicalProperties.water with the attached tabulated one:     - if you run the simulation it works fine,     - but if the initial temperature in ./0/T is changed from 293 to 300, the calculation crash with the following error:         "..."         "in file /home/ENGINSOFT/l.trevisan/OpenFOAM/OpenFOAM-dev/src/thermophysicalModels/specie/lnInclude/thermoI.H at line 313"         "Energy -> temperature conversion failed to converge:"         "..."     - and considering initial temperature at 300, if tabulated Cv value is changed from "(300 4130)" to "(301 4130)" in ./constant/physicalProperties.water the simulation work again. e.g.2: copy tutorials/multiphase/multiphaseEulerFoam/laminar/bubbleColumn/ and substitute ./constant/physicalProperties.water with the attached tabulated one:     - if you run the simulation it crashes with the following error:         "..."         "431.902 out of range 273 to 373"         "of NonUniformTable Cv"         "..."     - but considering only initial and final tabulated Cv values in ./constant/physicalProperties.water the simulation work.
Additional Information:	Similar behavior is expected with hIcoTabulated, eTabulated and hTabulated too.
System Description
Attached Files:	physicalProperties.water (2,893 bytes) 2022-10-21 11:06 https://bugs.openfoam.org/file_download.php?file_id=3359&type=bug

Notes
(0012832) tniemi    2022-10-24 08:42	As mentioned here https://bugs.openfoam.org/view.php?id=3915, correcting a bug in integratedNonUniformTable1.C seems to also help with this. Before the fix I could reproduce both problems, but after fix both cases ran. In general the tabulated properties can be a bit problematic around the node points if Cp or Cv value changes a lot. This may make it difficult for the Newton iteration from h/e-> to converge. However, at least in my tests with h and eTabulated (which don't use integratedNonUniformTable1), I have not bumped in to this issue in practice.
(0012834) henry    2022-10-24 10:18	Resolved in OpenFOAM-10 by commit 6327ab2820105ef9e77d7dd69c0d5b8e6b5cbeb4 Resolved in OpenFOAM-dev by commit d551993e89652771a39850d0b5a807f6782953aa

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3915	[OpenFOAM] Bug	minor	always	2022-10-18 12:22	2022-10-24 10:17
Reporter:	martinB	Platform:	GNU/Linux
Assigned To:	henry	OS:	OpenSuSE
Priority:	normal	OS Version:	13.2
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	First summand is added twice in integratedNonUniformTable
Description:	In file  src/thermophysicalModels/specie/thermophysicalFunctions/integratedNonUniformTable1/integratedNonUniformTable1.C lines 58 and 87, and same for lines 59 and 104: The first summand "intf_[i]" is added twice, once in line 58 and then again in line 87 in the member function intfdT(). Same for intfByT_. Can someone take a quick look?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012831) tniemi    2022-10-24 08:29	Yes, I think there is a bug and indeed intf_[i] and intfByT_ are added twice. I did a test where I defined values (     ( 298.15 1 )     ( 318.15 1 )     ( 330.15 1 )     ( 350.15 1 )     ( 370.15 1 )     ( 398.15 1 ) ); and printed out the resulting intf_. It gave 6(0 20 52 124 268 564) while the expected result would have been 6(0 20 32 52 72 100) Just writing intf_[i + 1] = intfdT(values()[i + 1].first()); intfByT_[i + 1] = intfByTdT(values()[i + 1].first()); in lines 58-59 should be correct. A made this change and it also seemed to fix https://bugs.openfoam.org/view.php?id=3918
(0012833) henry    2022-10-24 10:17	Resolved in OpenFOAM-10 by commit 6327ab2820105ef9e77d7dd69c0d5b8e6b5cbeb4 Resolved in OpenFOAM-dev by commit d551993e89652771a39850d0b5a807f6782953aa

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3905	[OpenFOAM] Bug	minor	always	2022-10-12 16:57	2022-10-23 10:17
Reporter:	evamaria	Platform:	Linux
Assigned To:	henry	OS:	Ubuntu
Priority:	normal	OS Version:	20.04
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	EDC v2016 - wrong limits
Description:	In the EDC.C (this applies for OpenFOAM-9 and OpenFOAM-10), the parameters Ctau and Cgamma for the EDC-Model are calculated for v2016. According to the reference in the EDC.H file [1] the constants are limited to their default values, which are: Cgamma_ = 2.13777 Ctau_ = 0.4083 The limits are set differently - the default values were mixed up: const scalar CtauI = min(C1_/(Da*sqrt(ReT + 1)), 2.1377); const scalar CgammaI =                 max(min(C2_*sqrt(Da*(ReT + 1)), 5), 0.4082); [1] Parente, A., Malik, M. R., Contino, F., Cuoci, A., & Dally, B. B. (2016).       Extension of the Eddy Dissipation Concept for turbulence/chemistry interactions to MILD combustion.       Fuel, 163, 98-111.
Tags:
Steps To Reproduce:
Additional Information:	Suggested changes: #Line 143 in OF-9 and Line 138 in OF-10 const scalar CtauI = max(min(C1_/(Da*sqrt(ReT + 1)), 5), 0.4082); #Line 145-146 in OF-9 and Line 143-144 in OF-10 const scalar CgammaI =      min(C2_*sqrt(Da*(ReT + 1)), 2.13777);
System Description
Attached Files:

Notes
(0012820) peksa    2022-10-21 11:46	I can confirm that there is such a mix in coefficients compared to ones reported in the original journal paper. Note that in the constructor, these coefficients are set in right order:     Cgamma_(this->coeffs().lookupOrDefault("Cgamma", 2.1377)),     Ctau_(this->coeffs().lookupOrDefault("Ctau", 0.4083)), , but used explicitly in wrong order as described in the original post.
(0012821) henry    2022-10-21 11:53	I have forwarded the issue to the authors of the paper who also contributed the implementation but so far not heard back. I will make the suggested change assuming it is what the authors intended.
(0012825) henry    2022-10-23 10:17	Resolved in OpenFOAM-10 by commit 6b938e005bb3ec5b53822540983d8292c483fcb8 Resolved in OpenFOAM-dev by commit e8325bbcecdec4e54e5476d1bc9755478cb86c80 It is not clear why the coefficients were hard-coded for the v2016 variant but run-time modifiable for the others, I have changed the code to use the coefficients consistently pending a response from the authors of the paper and implementation.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3894	[OpenFOAM] Bug	crash	always	2022-10-05 10:56	2022-10-21 12:59
Reporter:	blttkgl	Platform:	GNU/Linux
Assigned To:	henry	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Mesh refiner cannot access rho_U field from objectRegistry
Description:	When refiner type topoChanger is used with a compressible solver the topoChanger cannot find the vector rhoU_0 from the object registry and throws the following error. I also found this bug report from last year which may be relevant: https://bugs.openfoam.org/view.php?id=3636 --> FOAM FATAL ERROR:     request for volVectorField rhoU_0 from objectRegistry region0 failed     available objects of type volVectorField are 3 ( U_0 U rhoU )
Tags:
Steps To Reproduce:	Run the aachenBomb tutorial with a refiner topoChanger, using the C7H16 field for refining criteria.
Additional Information:
System Description
Attached Files:	dynamicMeshDict (1,681 bytes) 2022-10-09 18:17 https://bugs.openfoam.org/file_download.php?file_id=3351&type=bug

Notes
(0012783) peksa    2022-10-09 18:17	I was able to reproduce the error by introducing the attached dynamicMeshDict under constant directory in the aachenBomb tutorial. As the error message suggests, fvMeshTopoChangers::refiner::refineUfs() tries to access the rhoU_0 which is not available.
(0012786) henry    2022-10-10 21:45	Resolved by commit 30eb5e28e65d359dbe8c350b9073dcd492172904

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3917	[OpenFOAM] Bug	major	always	2022-10-21 00:58	2022-10-21 10:31
Reporter:	SamMallinson	Platform:	Linux
Assigned To:	will	OS:	Ubuntu
Priority:	normal	OS Version:	18.04
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	chtMultiRegionFoam case successfully runs in single core mode but gives erroneous result in parallel
Description:	I have been simulating the simple case of a parallel wall channel in 2D, with one wall attached to a solid block, at the bottom of which a heat flux is applied. The results compare very well with an analytical solution, see https://www.researchgate.net/publication/334028691_Conjugate_Heat_Transfer_in_Thermal_Inkjet_Printheads and in particular Figure 1 The case in question has been run under OpenFOAM-5, 6, 7 and 8, all giving good agreement between theory and simulation. I had neglected to update it to 9 last year, and when I came to update to 10, I noticed some unusual behaviour. In particular, when I run the case in single-core mode, I again obtain good agreement with the theory, but when I run in parallel, I get a large overprediction of the temperature profile. I have attached .tar-balls for the OpenFOAM-8 and OpenFOAM-10 cases (NB: for the latter, a number of changes were required, eg updating of thermophysical model for solid from constIso to constIsoSolid).
Tags:
Steps To Reproduce:	1. download and un-tar files in separate folders 1.1 prior to running each case, issue source /path/to/etc/bashrc for given code version 2. for OpenFOAM-8 case, ./Allrun - then inspect plots/T.png 3. for OpenFOAM-10 case single core, ./Allrun - then inspect plots/T.png 4. for OpenFOAM-10 case parallel case, ./AllrunPar - then inspect plots/T.png
Additional Information:	I've been running other cases from earlier version of OpenFOAM for some number of years; when I came to update them to version 10, I did not see this issue, instead the results were consistent with the earlier versions whether run single-core or parallel.
System Description
Attached Files:	cht_of10.tar (122,880 bytes) 2022-10-21 00:58 https://bugs.openfoam.org/file_download.php?file_id=3357&type=bug cht_of8.tar (225,280 bytes) 2022-10-21 00:58 https://bugs.openfoam.org/file_download.php?file_id=3358&type=bug

Notes
(0012815) tniemi    2022-10-21 08:15	I debugged this a little and one clear difference is that the gradient values for heater T BCs have very different values in parallel and in serial. The values are given through macro expansions and somehow they evaluate to different values in serial vs in parallel. eg. T heater outlet is gradient uniform 0.210084; in serial vs gradient uniform 300.0010504; in parallel. The case setups in OF8 are different. In OF8 the value is calculated before decomposition by using changeDictionary -enableFunctionEntries, in OF10 the fields already contain macros and they are decomposed resulting to different evaluation.
(0012816) tniemi    2022-10-21 08:33	I was able to simplify the problem, for some reason in OF10 if there is a fixedGradient BC with a given gradient, when the field is decomposed the gradient is recalculated and overwritten. This does not happen in OF8.
(0012817) tniemi    2022-10-21 09:10	The change in behavior happens in this commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/261d5ccd6d69ef1bf2e7f347dafa51fe123425d8. I think there is a bug in line 92 in fixedGradientFvPatchField.C, the gradient is mapped using mapper(gradient_, ptf), shouldn't it be mapper(gradient_, ptf.gradient_); ?
(0012819) will    2022-10-21 10:31	Thanks for the report, and thanks for finding and fixing the issue, Timo. I guess this has hung around so long because we don't use fixedGradient all that much, and when we do it's usually derived into something which overwrites the gradient, thereby masking the problem. Fixed in 9, 10 and dev: https://github.com/OpenFOAM/OpenFOAM-9/commit/00b327d198db183131a745002f18adde41a8f300 https://github.com/OpenFOAM/OpenFOAM-10/commit/8a1158492d95b4f5c1eb8adb12cae12809270ad8 https://github.com/OpenFOAM/OpenFOAM-dev/commit/091cba730d49fc43e6b90a21c42aa4569cadc9aa

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3916	[OpenFOAM] Bug	major	always	2022-10-19 13:59	2022-10-21 10:06
Reporter:	nidalsb	Platform:	GNU/Linux
Assigned To:	will	OS:	Ubuntu 20.04
Priority:	high	OS Version:	15.04
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	Reconstructing a mesh with a Cyclic/Fixed Jump condition returns error
Description:	Whenever I try to reconstruct a case with a fixed jump boundary condition I get the following error. running this with OpenFOAM v8, and v9 works just fine. Here is the error: ___________________________________________________________________________________________________________________________________________________________________ Create time Reconstructing fields for mesh region0 Time = 0.015s Reconstructing FV fields     Reconstructing volScalarFields         nut         p --> FOAM FATAL ERROR: Attempt to cast type processorCyclic to type fixedJump     From function To& Foam::refCast(From&) [with To = const Foam::fixedJumpFvPatchField<double>; From = const Foam::fvPatchField<double>]     in file /home/ubuntu/OpenFOAM/OpenFOAM-10/src/OpenFOAM/lnInclude/typeInfo.H at line 114. FOAM aborting #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::error::abort() at ??:? #2 Foam::fixedJumpFvPatchField<double> const& Foam::refCast<Foam::fixedJumpFvPatchField<double> const, Foam::fvPatchField<double> const>(Foam::fvPatchField<double> const&) at ??:? #3 non-virtual thunk to Foam::fixedJumpFvPatchField<double>::rmap(Foam::fvPatchField<double> const&, Foam::List<int> const&) at ??:? #4 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar" #5 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar" #6 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar" #7 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar" #8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #9 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar" Aborted (core dumped) __________________________________________________________________________________________________________________________________________________________________________________
Tags:
Steps To Reproduce:	1. Create a simple case (Channel Flow using PimpleFoam is similar to my use case) 2. Set the U boundary condition as Cyclic, The P boundary condition as a FixedJump 2. Run the simulation using Hierarchical decomposition 3. Run ReconstructPar (Above Error Occurs)
Additional Information:
System Description
Attached Files:

Notes
(0012818) will    2022-10-21 10:06	We do not support this. There is no processorFixedJump condition for a fixedJump patch field to decompose into. If you use "patchType" overrides on a cyclic patch then when decomposing you must constrain that patch to a single processor. The critical problem, as I see it, is that previous versions silently converted fixedJump faces into processorCyclic faces and vice versa. The resulting parallel simulation is then wrong as the processorCyclic faces have no jump applied. I have added error messages to decomposePar and reconstructPar to catch this problem and advise a user as to what to do (i.e., use decomposition constraints). I consider this to have resolved this issue. https://github.com/OpenFOAM/OpenFOAM-dev/commit/a7155a7e0a69f651c14fe6630cdecbc0d1c0d72c https://github.com/OpenFOAM/OpenFOAM-10/commit/875cb6280d95cbe0d7d6925aa8e70bca0fec612c

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3912	[OpenFOAM] Patch	minor	always	2022-10-17 13:32	2022-10-18 21: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:	dev
		Target Version:
Summary:	Patch to prevent crash when using films with surfaceFilmModel none in cloudProperties
Description:	Currently it is not possible to have particles (eg. passive tracers) with surfaceFilmModel none in a case which includes surface films. The NoSurfaceFilm-model calls SurfaceFilmModel(CloudType& owner) constructor which ignores owner and sets deltaFilmPatch_(0). This will cause a segFault when using deltaFilmPatch_[primaryPatchi] in cacheFilmFields. I have attached a patch which uses deltaFilmPatch_(owner.mesh().boundary().size()) to initialize the deltaFilmPatch_ similarly as in the other constructor.
Tags:
Steps To Reproduce:	In tutorials/modules/multicomponentFluid/splashPanel set surfaceFilmModel none; in constant/cloudProperties
Additional Information:
Attached Files:	patch.diff (738 bytes) 2022-10-17 13:32 https://bugs.openfoam.org/file_download.php?file_id=3355&type=bug

Notes
(0012814) will    2022-10-18 21:25	Thanks for the patch. Pushed here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/4b4c124f9785c51a78b8feab93f71b17955b8ca8

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3913	[OpenFOAM] Patch	text	always	2022-10-17 16:35	2022-10-18 11:56
Reporter:	lorenzotrevisan	Platform:	x86_64
Assigned To:	henry	OS:	Slackware64
Priority:	low	OS Version:	15.0
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	fix header typo in solidificationMeltingSource.H: "[thermo|lookup]" --> "[thermo\|lookup]"
Description:	fix header typo in src/fvModels/derived/solidificationMeltingSource/solidificationMeltingSource.H line 102: Pipe symbol in variable values field "[thermo|lookup]" causes the typo. Adding a back slash symbol "\" befro the pipe symbol should resolve the typo: "[thermo\|lookup]"
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012813) henry    2022-10-18 11:56	Resolved by commit bad5bd0bbe151975fc495ffc06fc391280b0ffaf

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3914	[OpenFOAM] Patch	text	N/A	2022-10-18 06:50	2022-10-18 08:24
Reporter:	tniemi	Platform:
Assigned To:	will	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Corrections for a couple of typos
Description:	I have attached a patch, which corrects a couple of typos in the header fields of mapped boundary conditions.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	patch.diff (3,821 bytes) 2022-10-18 06:50 https://bugs.openfoam.org/file_download.php?file_id=3356&type=bug

Notes
(0012811) will    2022-10-18 08:24	Thanks for the report and patch, Timo. Fixed here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/512e5dddd11d9b8e892faf117ed36a2a599fa44a

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3904	[OpenFOAM] Bug	minor	always	2022-10-12 14:41	2022-10-13 12:14
Reporter:	cgoessni	Platform:	amd64
Assigned To:	henry	OS:	CentOS
Priority:	normal	OS Version:	7
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	setWriteInterval and setTimeStep functionObjects do not convert user time to real time
Description:	One would expect that the values given to setWriteInterval and setTimeStep are in units userTime. However, there is no conversion userTimeToTime() yet in these two functionObjects. Patch attached.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	functionObjects_timeToUserTime_diff.txt (1,327 bytes) 2022-10-12 14:41 https://bugs.openfoam.org/file_download.php?file_id=3352&type=bug

Notes
(0012804) henry    2022-10-13 12:14	Resolved by commit 2972d1665309c93d4ee965d892420493701eadf3

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3907	[OpenFOAM] Bug	minor	always	2022-10-12 20:30	2022-10-13 11:34
Reporter:	michael.mueller-wrd	Platform:	Unix
Assigned To:	will	OS:	centOS
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:	functions for runtime visualization give output in wrong postProcessing directory for multi-region cases
Description:	For multi-region cases, functions defined in controlDict give output usually in directory: ./postProcessing/<region>/<funcName>/<time>/...*.dat For visualization like "surfaces", however, output is written at: ./postProcessing/<funcName>/<region>/<time>/...*.vtk Would be helpful and more clear to have that aligned and vtk output written to: ./postProcessing/<region>/<funcName>/<time>/...*.vtk
Tags:
Steps To Reproduce:	For example "heatExchanger" tutorial case: add functions to controlDict, e.g. functions {     #includeFunc residuals(region = air, p_rgh, U, h)     #includeFunc cuts(funcName=cuts_air, region = air, writeControl = writeTime) } add file system/cuts, e.g. fields ( U T ); interpolate true; type surfaces; libs ( "libsampling.so" ); writeControl writeTime; surfaceFormat vtk; interpolationScheme cellPoint; surfaces ( cut_x { type cuttingPlane ; planeType pointAndNormal ; point ( 0.25 0.025 0.25 ) ; normal ( 1 0 0 ); interpolate true; } cut_y { type cuttingPlane ; planeType pointAndNormal ; point ( 0.25 0.025 0.25 ) ; normal ( 0 1 0 ); interpolate true; } cut_z { type cuttingPlane ; planeType pointAndNormal ; point ( 0.25 0.025 0.25 ) ; normal ( 0 0 1 ); interpolate true; } ); residual output in: postProcessing/air/residuals(region=air,p_rgh,U,h)/0/residuals.dat vtk files in: postProcessing/cuts_air/air/0/cut_*.vtk postProcessing/cuts_air/air/50/cut_*.vtk ...
Additional Information:
System Description
Attached Files:

Notes
(0012799) henry    2022-10-12 21:33	We could make this change but it would take a bit of time and would not be backward-compatible with previous version or with user scripts relying on the current structure, however consistency is always good.
(0012802) michael.mueller-wrd    2022-10-13 08:49	My vote would go to consistency over backward-compatibility with user scripts.
(0012803) will    2022-10-13 11:34    (Last edited: 2022-10-13 11:34)	I think on balance, we agree. Consistency is more important in this instance. User scripts can/should be easily modified. Resolved in dev by the following commit: https://github.com/OpenFOAM/OpenFOAM-dev/commit/5b11f5a833e927aeb26a5f9adaf3931f58ca3c94 Now the region name always comes first, followed by the function name.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3902	[OpenFOAM] Bug	major	always	2022-10-10 13:24	2022-10-12 12:01
Reporter:	snow9	Platform:	Linux
Assigned To:	will	OS:	Ubuntu
Priority:	normal	OS Version:	22.04
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	Error in NCC simulations using 2nd order ddt schemes
Description:	Simulations using the NCC approach do not run after the 1st time step using 2nd order ddt schemes
Tags:
Steps To Reproduce:	It can be reproduced with any tutorial using NCC, e.g. compressible/rhoPimpleFoam/RAS/annularThermalMixer Change ddt scheme from "Euler" to "backward", for example.
Additional Information:	#0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigFpe::sigHandler(int) at ??:? #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" #3 Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const at ??:? #4 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:? #5 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:? #6 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:? #7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:? #8 Foam::fvMatrix<double>::solve() at ??:? #9 Foam::solvers::isothermalFluid::correctPressure() at ??:? #10 Foam::solvers::isothermalFluid::pressureCorrector() at ??:? #11 ? in "/path/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/foamRun" #12 ? in "/lib/x86_64-linux-gnu/libc.so.6" #13 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #14 ? in "/path/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/foamRun" Floating point exception
System Description
Attached Files:

Notes
(0012794) will    2022-10-12 12:01	Thanks for the report. Resolved in dev and version 10: https://github.com/OpenFOAM/OpenFOAM-dev/commit/a4ca75045c004f4d488fad33988a25394b754a61 https://github.com/OpenFOAM/OpenFOAM-10/commit/d72c3ccf156ba0191a0a090e651a0da0a96a83a3

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3903	[OpenFOAM] Bug	trivial	always	2022-10-11 19:45	2022-10-11 21:57
Reporter:	peksa	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:	Unnecessary print in interpolatingSolidBodyMotionSolver.C
Description:	Perhaps this print is a residue of debugging and could be removed? : https://github.com/OpenFOAM/OpenFOAM-dev/blob/778ea7bf89ff46de3fea1b904245d8e2d126e0c4/src/dynamicMesh/motionSolvers/displacement/solidBody/interpolatingSolidBodyMotionSolver/interpolatingSolidBodyMotionSolver.C#L138
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012793) henry    2022-10-11 21:57	Resolved by commit 45fe16d32542cb1f682a1315bcdd82e2f2db165b

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3896	[OpenFOAM] Bug	minor	always	2022-10-06 09:43	2022-10-11 11:32
Reporter:	billie	Platform:	GNU/Linux
Assigned To:	will	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	10
Product Build:		Resolution:	reopened
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	Creation of cyclic baffles fails with OpenFOAM 10
Description:	I am trying to migrate my models from OpenFOAM 8 to OpenFOAM 10. I noticed the commit https://github.com/OpenFOAM/OpenFOAM-10/commit/f93300ee111726d1f583fc016c14123d5e07383a which required changes to the input syntax for baffle creation.
Tags:
Steps To Reproduce:	Previously the baffle was defined using e.g.: internalFacesOnly true; fields true; baffles {     inte_eval_baffle     {         region fluid_body;         type faceZone;         zoneName inte_eval;         patchPairs         {             type cyclic;             transformType none;         }     } } For OpenFAOM 10 I changed it to e.g.: internalFacesOnly true; fields true; baffles {     inte_eval_baffle     {         region fluid_body;         type faceZone;         zoneName inte_eval;         owner         {             name inte_eval_baffle_side0;             type cyclic;             neighbourPatch inte_eval_baffle_side1;             transform none;         }         neighbour         {             name inte_eval_baffle_side1;             type cyclic;             neighbourPatch inte_eval_baffle_side0;             transform none;         }     } } When running createBaffles using the new format I get the following error: --> FOAM FATAL ERROR: problem : my edge:(0 1) in master points:(0 1) v.s. masterEdgeVerts:(2147483647 2147483647)     From function void Foam::globalMeshData::calcGlobalEdgeOrientation() const     in file meshes/polyMesh/globalMeshData/globalMeshData.C at line 1209. If necessary I can attach the full log and an example case.
Additional Information:	When using "fields true" in createBafflesDict the operation succeeds but later decomposPar fails because obviously the fields are not defined for the baffle sides. Related question. I am doing this because I want to evaluate the pressure at a faceZone. This does not work (or at least I found no way to do so directly) thus I created the cyclic baffle to evaluate the pressure like for a boundary patch. Is there a way to avoid the creation of the patches. If yes the problem wouldn't be relevant.
System Description
Attached Files:	testCase.7z (1,562,076 bytes) 2022-10-07 16:14 https://bugs.openfoam.org/file_download.php?file_id=3348&type=bug

Notes
(0012763) henry    2022-10-06 09:56	User support request.
(0012764) will    2022-10-07 08:34	On reflection, actually yes, can you please upload the case that reproduces this failure. If a failure mechanism has been introduced by recent changes then it would be good to find and fix it. > I am doing this because I want to evaluate the pressure at a faceZone. In which case your use of createBaffles is unnecessary. Any post-processing evaluation that is possible for a patch is also possible on a faceZone. Actually helping you do this would be user support, which we do not provide here.
(0012766) billie    2022-10-07 16:14	> On reflection, actually yes, can you please upload the case that reproduces this failure. If a failure mechanism has been introduced by recent changes then it would be good to find and fix it. Please find attached the test case. Curious if there is actually an issue. > In which case your use of createBaffles is unnecessary. Any post-processing evaluation that is possible for a patch is also possible on a faceZone. Actually helping you do this would be user support, which we do not provide here. Understood that there is no user support. If I am not mistaken I can just replace the regionType patch with faceZone. Looks like this was not possible when I set this up the first time.
(0012788) will    2022-10-11 11:32	It's actually got nothing to do with createBaffles. It's a failure in patch distance calculation in the new "profile" stuff in the flow rate inlet boundary condition. The patch wave couldn't handle an un-split baffle. Fixed in 10 and dev as of these commits: https://github.com/OpenFOAM/OpenFOAM-10/commit/9cc5fdb7ff0565e167176411afc6127b46ddf75e https://github.com/OpenFOAM/OpenFOAM-dev/commit/ebb02bc894529cd798fa244e074508931bf6e87e

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3901	[OpenFOAM] Feature	minor	always	2022-10-10 12:29	2022-10-10 14:40
Reporter:	billie	Platform:
Assigned To:	henry	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Clean compressed cellToRegion files with cleanCase
Description:	For multi region cases if writeCompression is enabled cleanCase from bin/tools/CleanFunctions does not remove cellToRegion.gz files. Would be great if this could be covered as well.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0012785) henry    2022-10-10 14:40	Resolved by commit b8ccebb5f415ba96dc563d0b06cd466486fc283c

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3897	[OpenFOAM] Patch	trivial	always	2022-10-06 14:13	2022-10-07 11:40
Reporter:	lorenzotrevisan	Platform:	x86_64
Assigned To:	henry	OS:	Slackware64
Priority:	low	OS Version:	15.0
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	tutorials/multiphase/multiphaseEulerFoam/laminar/damBreak4phase/constant/momentumTransport might be superfluous
Description:	tutorials/multiphase/multiphaseEulerFoam/laminar/damBreak4phase/constant/momentumTransport might be superfluous
Tags:
Steps To Reproduce:	remove tutorials/multiphase/multiphaseEulerFoam/laminar/damBreak4phase/constant/momentumTransport and run the tutorial
Additional Information:
System Description
Attached Files:

Notes
(0012765) henry    2022-10-07 11:40	Resolved by commit 1a3e2ab68ddac16cc80932b21f5883a15da9a425

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3895	[OpenFOAM] Bug	minor	always	2022-10-06 00:35	2022-10-06 09:21
Reporter:	VictorEijkhout	Platform:	GNU/Linux
Assigned To:	will	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	C++ compilation error algorithms/FvFaceCellWave/FvFaceCellWaveName.C
Description:	``` mpicxx -std=c++14 -m64 -DLIB_NAME=libfiniteVolume.so -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/work2/00434/eijkhout/frontera/webfoam/OpenFOAM-dev/src/triSurface/lnInclude -I/work2/00434/eijkhout/frontera/webfoam/OpenFOAM-dev/src/meshTools/lnInclude -IlnInclude -I. -I/work2/00434/eijkhout/frontera/webfoam/OpenFOAM-dev/src/OpenFOAM/lnInclude -I/work2/00434/eijkhout/frontera/webfoam/OpenFOAM-dev/src/OSspecific/POSIX/lnInclude -fPIC -c algorithms/FvFaceCellWave/FvFaceCellWaveName.C -o /work2/00434/eijkhout/frontera/webfoam/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/src/finiteVolume/algorithms/FvFaceCellWave/FvFaceCellWaveName.o In file included from algorithms/FvFaceCellWave/FvFaceCellWave.H:363,                  from algorithms/FvFaceCellWave/FvFaceCellWaveName.C:26: algorithms/FvFaceCellWave/FvFaceCellWave.C: In constructor ‘Foam::FvFaceCellWave<Type, TrackingData>::FvFaceCellWave(const Foam::fvMesh&, Foam::List<T>&, Foam::List<Foam::List<T> >&, Foam::List<T>&, TrackingData&)’: algorithms/FvFaceCellWave/FvFaceCellWave.C:558:9: error: no matching function for call to ‘Foam::FvFaceCellWave<Type, TrackingData>::sizesListList<Foam::List<Foam::PackedBoolList> >(Foam::labelList, bool)’   558 | )       | ^ In file included from algorithms/FvFaceCellWave/FvFaceCellWaveName.C:26: algorithms/FvFaceCellWave/FvFaceCellWave.H:244:25: note: candidate: ‘template<class Type, class TrackingData> template<class ListList, class Value> static ListList Foam::FvFaceCellWave<Type, TrackingData>::sizesListList(const labelList&, const Value&)’   244 | static ListList sizesListList(const labelList& s, const Value& value);       | ^~~~~~~~~~~~~ algorithms/FvFaceCellWave/FvFaceCellWave.H:244:25: note: template argument deduction/substitution failed: In file included from algorithms/FvFaceCellWave/FvFaceCellWave.H:363,                  from algorithms/FvFaceCellWave/FvFaceCellWaveName.C:26: algorithms/FvFaceCellWave/FvFaceCellWave.C:558:9: note: mismatched types ‘const Value’ and ‘bool’   558 | )       | ^ ```
Tags:
Steps To Reproduce:	Compilation with Intel 2019 compiler
Additional Information:
System Description
Attached Files:

Notes
(0012761) henry    2022-10-06 07:40	I am unable to reproduce this problem, OpenFOAM-dev compiles fine with the C++ compilers I have. Which C++ compiler are you using?
(0012762) will    2022-10-06 09:21	As it happens, I was already fixing this for somebody else. It's caused by a bug in Gcc-9.2 (that's what you are using, right?), but the fix is simple and if anything makes the code more explicit, so I don't mind working around Gcc's bug in this instance. Fixed in 10 and dev by the following commits: https://github.com/OpenFOAM/OpenFOAM-10/commit/b7e86e0e6d48d0378298101342098f91e183ae6a https://github.com/OpenFOAM/OpenFOAM-dev/commit/b77defca720e5e00ae527e3b57b40906f2c4472a (If I'm wrong, and it's not Gcc-9.2, or this change doesn't fix it for you, then please open another report)

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3820	[OpenFOAM] Bug	major	always	2022-03-30 09:19	2022-10-04 12:46
Reporter:	sjohn2	Platform:	Linux
Assigned To:		OS:	Ubuntu
Priority:	normal	OS Version:	21.10
Status:	new	Product Version:	dev
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Error in installation of OpenFoam-dev version in Ubuntu 21.10
Description:	There is an error with installlation of OpenFoam some solvers are not getting installed, please check the log files Installation procedure followed from the website Also in step sudo apt-get install libqt5x11extras5-dev libxt-dev qt5-default qttools5-dev curl there is an error E: Package 'qt5-default' has no installation candidate
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	log.zip (333,662 bytes) 2022-03-30 09:21 https://bugs.openfoam.org/file_download.php?file_id=3300&type=bug logredoAllwmake.zip (6,081 bytes) 2022-04-05 06:47 https://bugs.openfoam.org/file_download.php?file_id=3302&type=bug

Notes
(0012535) sjohn2    2022-04-05 06:47	When I redo Allwmake in OpenFoam folder there is an issue with wmake basic make[1]: Entering directory '/home/sjohn2/Documents/ACADEMIC_PROFESSIONAL/SOFTWARES/OPENFOAM/dev/OpenFOAM-dev/applications/solvers/basic' more of this can be seen in the log file
(0012760) lorenzotrevisan    2022-10-04 12:46	if you are in trouble with dependency hell, did you try to install the last sable version (sudo aptget install openfoam10) ? maybe it can help to install the dependencies needed to compile properly the dev as well, and possibly you can even skip compiling paraview.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3892	[OpenFOAM] Bug	major	always	2022-09-22 15:56	2022-09-22 20:54
Reporter:	juhkor	Platform:	GNU/Linux
Assigned To:	will	OS:	Debian desktop
Priority:	normal	OS Version:	11 "bullseye"
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	Decomposing of a NCC case with velocityComponentLaplacian motion solver fails
Description:	The decomposition of a NCC case with velocityComponentLaplacian motion solver fails with the following error message: --> FOAM FATAL ERROR: Attempt to cast type nonConformalProcessorCyclic to type processor     From function To& Foam::refCast(From&) [with To = const Foam::processorPointPatch; From = const Foam::pointPatch]     in file /home/johndoe/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/typeInfo.H at line 118. FOAM aborting #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::error::abort() at ??:? #2 ? in "/home/johndoe/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/decomposePar" #3 ? in "/home/johndoe/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/decomposePar" #4 ? in "/home/johndoe/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/decomposePar" #5 ? in "/home/johndoe/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/decomposePar" #6 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #7 ? in "/home/johndoe/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/decomposePar" Aborted The same case runs well (pimpleFoam) when not decomposed.
Tags:
Steps To Reproduce:	1. Unpack the test case (oscillatingInlet_CSV.tgz) 2. Move to the case directory 3. Run "decomposePar"
Additional Information:	OpenFOAM-dev Build: dev-fab4bbe0878d
System Description
Attached Files:	oscillatingInlet_CSV.tgz (493,149 bytes) 2022-09-22 15:56 https://bugs.openfoam.org/file_download.php?file_id=3347&type=bug

Notes
(0012750) will    2022-09-22 20:54	Thanks for pointing this out. Resolved in dev and version 10 by the following commits: https://github.com/OpenFOAM/OpenFOAM-dev/commit/bf21eb151eef254e536697d5e9fb4134f2fa3f1c https://github.com/OpenFOAM/OpenFOAM-10/commit/4820f18431572161cb6ba043eb6182345ddd4c66

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3891	[OpenFOAM] Patch	trivial	N/A	2022-09-21 12:17	2022-09-21 13:55
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: better error messages for actuationDiskSource
Description:	I have attached a small patch which fixes error messages in actuationDiskSource. At present the errors are quite confusing due to using a wrong error macro. Current error message: --> FOAM FATAL IO ERROR: file: unknown FOAM exiting Error after: --> FOAM FATAL IO ERROR: disk direction vector is approximately zero file: /turbineSiting/constant/fvModels/disk1 from line 19 to line 27.     From function void Foam::fv::actuationDiskSource::readCoeffs()     in file derived/actuationDiskSource/actuationDiskSource.C at line 65. FOAM exiting
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	patch.diff (1,684 bytes) 2022-09-21 12:17 https://bugs.openfoam.org/file_download.php?file_id=3346&type=bug

Notes
(0012748) henry    2022-09-21 13:55	Resolved by commit c90671c8b7596e81c3090834b427221abae0a014

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3889	[OpenFOAM] Bug	minor	always	2022-09-19 17:46	2022-09-21 13:09
Reporter:	jsoln	Platform:	GNU/Linux
Assigned To:	henry	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	The rhoPimpleFoam forwardStep tutorial, as packaged in OpenFOAM 10, encounters a negative temperature.
Description:	pimpleForwardStep$ rhoPimpleFoam ⋮ Starting time loop Courant Number mean: 0.249762 max: 0.25 Time = 0.002s ⋮ ⋮ ⋮ PIMPLE: Iteration 2 smoothSolver: Solving for Ux, Initial residual = 0.0070433, Final residual = 1.61834e-07, No Iterations 1 smoothSolver: Solving for Uy, Initial residual = 0.00532753, Final residual = 3.49144e-07, No Iterations 1 smoothSolver: Solving for e, Initial residual = 0.117347, Final residual = 2.9863e-06, No Iterations 2 smoothSolver: Solving for p, Initial residual = 0.00646344, Final residual = 1.12867e-08, No Iterations 2 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 time step continuity errors : sum local = 3.17861e-10, global = 2.89641e-10, cumulative = 5.56068e-09 ExecutionTime = 0.275743 s ClockTime = 1 s Courant Number mean: 0.251275 max: 1.17915 Time = 0.016s PIMPLE: Iteration 1 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 smoothSolver: Solving for Ux, Initial residual = 0.0764808, Final residual = 1.29e-06, No Iterations 1 smoothSolver: Solving for Uy, Initial residual = 0.064002, Final residual = 7.94223e-06, No Iterations 1 smoothSolver: Solving for e, Initial residual = 0.26368, Final residual = 4.9006e-06, No Iterations 3 smoothSolver: Solving for p, Initial residual = 0.0715941, Final residual = 6.77228e-08, No Iterations 2 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 time step continuity errors : sum local = 1.94255e-09, global = 1.06042e-09, cumulative = 6.6211e-09 PIMPLE: Iteration 2 smoothSolver: Solving for Ux, Initial residual = 0.00795199, Final residual = 9.99449e-11, No Iterations 1 smoothSolver: Solving for Uy, Initial residual = 0.021992, Final residual = 1.56364e-09, No Iterations 1 smoothSolver: Solving for e, Initial residual = 0.285134, Final residual = 2.3536e-08, No Iterations 2 --> FOAM FATAL ERROR: Negative initial temperature T0: -3.09503     From function static Foam::scalar Foam::species::thermo<Thermo, Type>::T(const ThermoType&, Foam::scalar, Foam::scalar, Foam::scalar, FType, dFdTType, LimitType, bool) [with ThermoType = Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleInternalEnergy>; FType = double (Foam::hConstThermo<Foam::perfectGas<Foam::specie> >::*)(double, double) const; dFdTType = double (Foam::hConstThermo<Foam::perfectGas<Foam::specie> >::*)(double, double) const; LimitType = double (Foam::hConstThermo<Foam::perfectGas<Foam::specie> >::*)(double) const; Thermo = Foam::hConstThermo<Foam::perfectGas<Foam::specie> >; Type = Foam::sensibleInternalEnergy; Foam::scalar = double]     in file /home/ubuntu/OpenFOAM/OpenFOAM-10/src/thermophysicalModels/specie/lnInclude/thermoI.H at line 299. FOAM aborting #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::error::abort() at ??:? #2 double Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleInternalEnergy>::T<Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleInternalEnergy>, double (Foam::hConstThermo<Foam::perfectGas<Foam::specie> >::*)(double, double) const, double (Foam::hConstThermo<Foam::perfectGas<Foam::specie> >::*)(double, double) const, double (Foam::hConstThermo<Foam::perfectGas<Foam::specie> >::*)(double) const>(Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleInternalEnergy> const&, double, double, double, double (Foam::hConstThermo<Foam::perfectGas<Foam::specie> >::*)(double, double) const, double (Foam::hConstThermo<Foam::perfectGas<Foam::specie> >::*)(double, double) const, double (Foam::hConstThermo<Foam::perfectGas<Foam::specie> >::*)(double) const, bool) at ??:? #3 Foam::hePsiThermo<Foam::psiThermo::composite, Foam::pureMixture<Foam::constTransport<Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleInternalEnergy> > > >::calculate() at ??:? #4 virtual thunk to Foam::hePsiThermo<Foam::psiThermo::composite, Foam::pureMixture<Foam::constTransport<Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleInternalEnergy> > > >::correct() at ??:? #5 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/rhoPimpleFoam" #6 ? in "/lib/x86_64-linux-gnu/libc.so.6" #7 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #8 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/rhoPimpleFoam" Aborted (core dumped
Tags:
Steps To Reproduce:	Ubuntu 22.04 LTS Bash CLI: $ run $ cp -r $FOAM_TUTORIALS/compressible/rhoPimpleFoam/laminar/forwardStep/ pimpleForwardStep $ cd pimpleForwardStep $ blockMesh ⋮ $ rhoPimpleFoam ⋮
Additional Information:	See attached file (pimpleForwardStepSessionErrorLog.txt) for further session details.
System Description
Attached Files:	pimpleForwardStepSessionErrorLog.txt (21,433 bytes) 2022-09-19 17:46 https://bugs.openfoam.org/file_download.php?file_id=3345&type=bug

Notes
(0012747) henry    2022-09-21 13:09	Resolved by commit 910a10bf395da16de85ad12e88bc5cb9abb4f7e0

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3890	[OpenFOAM] Bug	minor	sometimes	2022-09-20 13:41	2022-09-20 16:41
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:	dev
		Target Version:
Summary:	Unable to lookup parcelClouds
Description:	In the very latest dev, code that uses lookup<parcelCloud> in parallel will fail because there seems to be no clouds to be found. This will crash eg. cloudInfo and cloudAbsorptionEmission and scatter models. Possibly others as well. I didn't have time to debug this any further, but possibly related to this commit? https://github.com/OpenFOAM/OpenFOAM-dev/commit/fef0206bdb4e1166dc134469c3e09be788a59d0c#diff-d1f582aa583c59b1419bce335e02d79f8a9d2dc91a7879becdd6add79f5bfeaa Serial works.
Tags:
Steps To Reproduce:	Try to run tutorials/modules/multicomponentFluid/simplifiedSiwek in parallel, crashes due to radiation models not finding clouds.
Additional Information:
Attached Files:

Notes
(0012745) will    2022-09-20 16:41	It is that commit, yes. Thanks for pointing this out. Fixed here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/50aac13df575b8dd12efd6b6a338819e2bdbc182

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3888	[OpenFOAM] Bug	major	sometimes	2022-09-18 10:35	2022-09-20 09:04
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:	dev
		Target Version:
Summary:	compressible::alphatJayatillekeWallFunction sigFpe issue
Description:	After the recent commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/f2b6c550faa2e823d9dcb7c61b37d69d701628b7 I started to get crashes due to sigFpe in alphatJayatillekeWallFunction. After a little debugging it seems that the "sign(B)*vSmall" stabilisation is not enough for zeroGradient walls where A=B=0 but C is finite. Changing vSmall to eg. rootVSmall seems to solve the issue.
Tags:
Steps To Reproduce:	To reproduce, change "walls" to use alphatJayatillekeWallFunction in tutorials/modules/fluid/angledDuct/
Additional Information:
Attached Files:

Notes
(0012744) will    2022-09-20 09:03    (Last edited: 2022-09-20 09:04)	Thanks for the report. Fixed by this commit: https://github.com/OpenFOAM/OpenFOAM-dev/commit/a23937d86effce7b7f6a8cfffba9bc94f7af0424 A little backstory... We changed this function to a non-lagged form because we think that this is more consistent when dealing with fixed temperature boundary conditions. In that case, the new form recovers the modelled alphat exactly without any iteration. However, with fixed-gradient- or heat-flux-type boundary conditions, the old form was arguably more correct in that it uses exactly the heat flux that the temperature boundary condition calculated using the old alphat. However, in this case all the alphat condition is doing is trading diffusivity for temperature gradient. The heat flux is the same, so the affect on the simulation is minimal (there is potentially *no* effect). So, we judged the fixed-temperature case to be more important. It seemed to us that there was little need to run this boundary condition on zero-gradient or heat-flux boundaries. Though, as you point out, there should be no harm either, and the implementation should be robust to application anywhere. Hence being very happy to accept your change. As for generalisation... It is probably possible to mix these two options based on the matrix coefficients in the temperature/energy boundary condition. If the temperature condition is fixed value, then use the new version. If fixed gradient, use the old. If mixed, mix the two. If someone comes up with an example where this approach is needed then we will do just this.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3884	[OpenFOAM] Patch	crash	random	2022-09-14 10:25	2022-09-16 10:36
Reporter:	AliShaha	Platform:	uni
Assigned To:	will	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:	Problem Using LoadBalancer with cyclic BC --> 0003879
Description:	Hi, Thank you for your assistance on this issue and apologies for not being able to allocate funding as a doctoral student. OpenFoam-dev/10 crashes when calculating the inverse of a field on cyclic boundary patches after redistribution. A full error output and case setup are provided. Possible Fix: ========== The issue got fixed for me when I correct the coupled patches after redistribution. I did the following changes in src/dynamicMesh/fvMeshDistribute/fvMeshDistributeTemplates.C - correctProcessorPatchFields(): 268: - if (isA<processorPatchFieldType>(bfld[patchi])) 268: + if (bfld[patchi].coupled() || isA<processorPatchFieldType>(bfld[patchi])) 288: - if (isA<processorPatchFieldType>(bfld[patchi])) 288: + if (bfld[patchi].coupled() || isA<processorPatchFieldType>(bfld[patchi])) 300: - if (isA<processorPatchFieldType>(bfld[patchEvali])) 300: + if (bfld[patchEvali].coupled() || bfld[patchEvali].coupled()) hope it helps, Ali
Tags:
Steps To Reproduce:	ofdev: unzip the case setup ./Allrun -parallel
Additional Information:
System Description
Attached Files:	fvMeshDistributeTemplates.C (11,474 bytes) 2022-09-14 10:25 https://bugs.openfoam.org/file_download.php?file_id=3339&type=bug counterFlowFlame2D_GRI_dev.zip (32,219 bytes) 2022-09-14 10:25 https://bugs.openfoam.org/file_download.php?file_id=3340&type=bug error.txt (8,761 bytes) 2022-09-14 10:25 https://bugs.openfoam.org/file_download.php?file_id=3341&type=bug

Notes
(0012740) will    2022-09-16 10:36	Thanks for the report and patch. Fixed in dev by the following commit: https://github.com/OpenFOAM/OpenFOAM-dev/commit/34d8167f94c08bbab6db3b43915fb20ad72620b4

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3882	[OpenFOAM] Bug	major	always	2022-09-13 10:22	2022-09-13 12:57
Reporter:	Muerio	Platform:
Assigned To:	will	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	externalWallHeatFluxTemperature Q handled incorrectly
Description:	In OF10 the parameter Q for the boundary condition externalWallHeatFluxTemperature is handeled incorrectly: Parameters q and Q are summed up, but power Q is not transformed to a heat flux before adding it to the sum. Q should be divided by the area of the patch before adding it to the sum. See line in github: https://github.com/OpenFOAM/OpenFOAM-10/blob/8d73542293f9f15151181b5ba0c7696e03bb2ad5/src/ThermophysicalTransportModels/derivedFvPatchFields/externalWallHeatFluxTemperature/externalWallHeatFluxTemperatureFvPatchScalarField.C#L307
Tags:
Steps To Reproduce:	Use any case with a externalWallHeatFluxTemperature patch. Set parameter Q to any value, don't set q. Evaluating heat flux one the patch during simulation shows Q is used as heat flux, not power.
Additional Information:
Attached Files:

Notes
(0012728) will    2022-09-13 12:57	Thanks for the report. Resolved in dev and in version 10 by the following commits: https://github.com/OpenFOAM/OpenFOAM-dev/commit/e84f3d110c026a3cd6b012fddcc1387a7bef573c https://github.com/OpenFOAM/OpenFOAM-10/commit/0d8947e2a1b2e5028595cbc057004f3f504e07b7

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3881	[OpenFOAM] Bug	crash	always	2022-09-12 10:45	2022-09-13 08:24
Reporter:	heinten	Platform:	GNU/Linux
Assigned To:	will	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	topoSet - patchDistanceToCell crashes
Description:	topoSet crashes always when patchDistanceToCell is used for creating a cellSet. This happens both in OpenFOAM 10 and dev, but does not occur in OpenFOAM 9. The error message is as follows: Time = 0s     mesh not changed. Created cellSet mucusLayer     Applying source patchDistanceToCell     Adding cells a distance less than 0.2 from patches 1(movingWall) ... #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigSegv::sigHandler(int) at ??:? #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" #3 Foam::patchDistWave::wave(Foam::polyMesh const&, Foam::List<int> const&, Foam::Field<double>&) at ??:? #4 Foam::patchDistWave::calculate(Foam::polyMesh const&, Foam::HashSet<int, Foam::Hash<int> > const&, Foam::Field<double>&) at ??:? #5 Foam::patchDistanceToCell::combine(Foam::topoSet&, bool) const at ??:? #6 ? in "/app2/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt32Opt/bin/topoSet" #7 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #8 ? in "/app2/OpenFOAM/OpenFOAM-10/platforms/linux64GccDPInt32Opt/bin/topoSet" Speicherzugriffsfehler
Tags:
Steps To Reproduce:	Just take the cavity tutorial case for icoFoam and use the appended topoSetDict. It should create a cellSet containing cells, which are 0.2 or less away from the top wall ('movingwall').
Additional Information:
System Description
Attached Files:	topoSetDict (925 bytes) 2022-09-12 11:42 https://bugs.openfoam.org/file_download.php?file_id=3338&type=bug

Notes
(0012725) wyldckat    2022-09-12 11:11	@heinten: you wrote "use the appended topoSetDict"... if you meant "attached" instead of appended, it's not yet attached to this report.
(0012726) heinten    2022-09-12 11:42	Sorry, I forgot to attach it. Here it is…
(0012727) will    2022-09-13 08:24	Thanks for the report. Fixed in 10 and dev by the following commits: https://github.com/OpenFOAM/OpenFOAM-10/commit/8d73542293f9f15151181b5ba0c7696e03bb2ad5 https://github.com/OpenFOAM/OpenFOAM-dev/commit/251f549a24cae3453cb2379ac2028a4e441a975e

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3879	[OpenFOAM] Bug	crash	always	2022-09-05 10:40	2022-09-06 14:10
Reporter:	AliShaha	Platform:	Unix
Assigned To:	will	OS:	Ubuntu
Priority:	normal	OS Version:	20.04
Status:	resolved	Product Version:	10
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Problem using LoadBalancer with cyclic BC
Description:	Hello, I ran into a problem running LoadBalancer with cyclic BC. After the run, running reconstructParMesh and then reconstructPar leads to the following error: Create time Reconstructing fields for mesh region0 Time = 1e-05s Reconstructing FV fields     Reconstructing volScalarFields         OH         CN         C2H3 #0 Foam::error::printStack(Foam::Ostream&)corrupted double-linked list Aborted Also, an extra text appears in e.g. reconstructed CN file in the above example with processorBC?     procBoundary0to3throughtop     {         type processor;         patchType processorCyclic;         value nonuniform List<scalar> 100 I am not sure if the laodBalancer handles the cyclic BCs correctly during the simulation in the first place. But also it seems there is an issue when the case is reconstructed. The OpenFOAM code is updated to the latest commit (regarding AMI BC). Regards.
Tags:
Steps To Reproduce:	- cd OpenFOAM-10/tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D_GRI - blockMeshDict: divide the outlet bc into two cyclic patches (e.g. top and bottom) - 0.orig: update the boundary conditions - controlDIct: set endTime 4e-5 - ./Allrun-parallel
Additional Information:	I attached the modified tutorial.
Attached Files:	counterFlowFlame2D_GRI.zip (29,477 bytes) 2022-09-05 10:40 https://bugs.openfoam.org/file_download.php?file_id=3337&type=bug

Notes
(0012722) henry    2022-09-05 10:57	What level of funding could you allocate to further work on dynamic load-balancing to resolve this issue?
(0012724) will    2022-09-06 14:10	Version 10 does not support the reconstruction of meshes with processor cyclic patches. Dev does support this. It was added in the following commit: https://github.com/OpenFOAM/OpenFOAM-dev/commit/7e2dd6dd So, you will need to upgrade to dev if you wish to use this feature. Also, in investigating your case, I found a further bug in the handling of redistribution of processor cyclic fields. This has been fixed here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/46107572 So, if you upgrade to dev, make sure that it is a recent enough pull to include this commit. Otherwise you will just hit another bug.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3878	[OpenFOAM] Bug	text	always	2022-08-29 16:28	2022-09-02 22:03
Reporter:	jherb	Platform:	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:	Usage documentation in header of mixedFvPatchField.H wrong (refGradient instead of refGrad)
Description:	In the header of mixedFvPatchField.H the usage is documented as: Usage     \table         Property | Description | Required | Default value         valueFraction | weight field | yes |         refValue | fixed value | yes |         refGrad | patch normal gradient | yes |     \endtable But in the code, it is looked for refGradient and not refGrad: https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/src/finiteVolume/fields/fvPatchFields/basic/mixed/mixedFvPatchField.C#L54
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012721) henry    2022-09-02 22:03	Resolved by commit ffe9dbd5838ef0abf56ff17c38328d7f663e5d5e

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3869	[OpenFOAM] Bug	major	always	2022-07-29 13:25	2022-09-01 21:05
Reporter:	lorenzotrevisan	Platform:	x86_64
Assigned To:		OS:	Slackware
Priority:	normal	OS Version:	15.0
Status:	new	Product Version:	10
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	externalWallHeatFluxTemperature BC does not work anymore with compressibleInterFoam and compressibleMultiphaseInterFoam
Description:	externalWallHeatFluxTemperature BC does not work anymore with compressibleInterFoam and compressibleMultiphaseInterFoam the solvers output the following message: --> FOAM FATAL ERROR: Cannot find a fluidThermo or solidThermo instance     From function Foam::tmp<Foam::Field<double> > Foam::temperatureCoupledBase::kappa(const fvPatchScalarField&) const     in file derivedFvPatchFields/temperatureCoupledBase/temperatureCoupledBase.C at line 124.
Tags:
Steps To Reproduce:	copy a compressibleInterFoam or compressibleMultiphaseInterFoam tutorial and change any wall BC to externalWallHeatFluxTemperature as described in the v10 c++ source code guide
Additional Information:	I attach tutorials/multiphase/compressibleInterFoam/RAS/damBreak with BC 0/T modified for lowerWall as externalWallHeatFluxTemperature
System Description
Attached Files:	damBreak.tar.gz (3,818 bytes) 2022-07-29 13:25 https://bugs.openfoam.org/file_download.php?file_id=3331&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3876	[OpenFOAM] Bug	minor	always	2022-08-22 16:01	2022-08-23 09:57
Reporter:	michael.mueller-wrd	Platform:	GNU/Linux
Assigned To:	will	OS:	centOS
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	createNonConformalCouples fails for region meshes
Description:	As far as I understood, createNonConformalCouples needs to be run without arguments when there are multiple couplings and/or transformations involved. When using $> createNonConformalCouples -region <name> always a fatal error is thrown... --> FOAM FATAL ERROR: Wrong number of arguments, expected 2 found 0 Specifying the control dictionary with -dict <path_to_createNonConformalCouplesDict> does not help as well. Runs fine, however, when constant/<region>/polyMesh is copied directly into constant/ (sample test case has been set up with a 22.5 degree rotational transformation; NCC shall be used instead of cyclicAMI)
Tags:
Steps To Reproduce:	Try any multi-region case and apply createNonConformalCouples with transformation to a region mesh.
Additional Information:
System Description
Attached Files:

Notes
(0012718) will    2022-08-23 09:57	Thanks for the report. Fixed in version 10 and in dev: https://github.com/OpenFOAM/OpenFOAM-10/commit/38adef723c6d3bb41dc5e6fec4fd49182b52cb8e https://github.com/OpenFOAM/OpenFOAM-dev/commit/2b2a75e03b4c692fb65d56724f81a504df762ba6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3875	[OpenFOAM] Bug	minor	always	2022-08-19 08:22	2022-08-19 22:10
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:	Possible bug in some of the individual fvModel source functions?
Description:	A while ago a new feature was added which allows to evaluate individual fvModels (fvOptions back then) https://github.com/OpenFOAM/OpenFOAM-dev/commit/bd6c02167b1cd955d962d8b673d6cc851740dc8c I was now trying to use this feature and evaluate individual fvModels using their source(...)-functions. However, for some reason the functions which accept rho or alpha appear to simply drop these parameters when calling the source template function resulting to wrong addSup call. (functions from line 105 downwards in https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/src/finiteVolume/cfdTools/general/fvModels/fvModelTemplates.C) Is this a bug, or am I just misunderstanding something? If a bug, the source functions should be similar to those in fvModelsTemplates, which correctly passes alpha&rho.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	cavity.tar.gz (2,810 bytes) 2022-08-19 10:57 https://bugs.openfoam.org/file_download.php?file_id=3335&type=bug patch.diff (5,854 bytes) 2022-08-19 12:45 https://bugs.openfoam.org/file_download.php?file_id=3336&type=bug

Notes
(0012712) henry    2022-08-19 10:08	It is not clear what the problem is, can you reproduce it in one of the tutorials?
(0012713) tniemi    2022-08-19 10:57	I'm not sure if this feature is currently being used anywhere, but I have attached a very artificial example case based on the cavity tutorial (untar+blockMesh+foamRun). I have defined two coded fvModels, where the second one tries to print the maximum value of the source-term produced by the first one. However, fvModels["s1"].source(rho, eqn.psi()) does not call codeAddRhoSup and instead calls codeAddSup which contains NotImplemented. Same would happen with source(alpha, rho, field) -call My real use case is a custom functionObject which would need to evaluate the sources produced by fvModels separately for each source. These sources need rho and alpha fields to work correctly.
(0012714) tniemi    2022-08-19 11:17	To further clarify, in https://github.com/OpenFOAM/OpenFOAM-dev/blob/dafc8f283389abc85fa374e391e1ba1b3c458a39/src/finiteVolume/cfdTools/general/fvModels/fvModelTemplates.C#L112 I would expect return this->source(rho, field, field.name()); instead of return this->source(field, field.name()); and return source(field, fieldName, dimVolume/dimTime, rho); indtead of return source(field, fieldName, dimVolume/dimTime); And similar changes for the alpha+rho versions. fvModels-interface also includes special versions for geometricOne-fields, which might be possibly useful also for fvModel?
(0012715) henry    2022-08-19 11:37	What happens if you make your suggested changes? Does it then operate the way you wish?
(0012716) tniemi    2022-08-19 12:45	Here is a patch which modifies fvModel to work as I would like it to work. The patch is basically copy&paste from fvModels making all the functions to act identically. I added d2dt and geometricOne-versions for consistency.
(0012717) henry    2022-08-19 22:10	Resolved by commit d4f9f9efcdf0d3623f0a19f98ed89840085d5af1

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3874	[OpenFOAM] Bug	text	always	2022-08-12 17:51	2022-08-12 20:10
Reporter:	wyldckat	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:	Typo in the description in the new Function1s::omega class
Description:	Saw this in commit 2da5edec29f3d63a1d12fdbc1e2b4deb0be903e4 for OpenFOAM-dev, where in the description of the new Function1s::omega class, the following example:     or the equivalent specified in rad/s:     \verbatim         MRF         {             cellZone rotor;             origin (0 0 0);             axis (0 0 1);             rpm 6.28319;         }     \endverbatim was meant to specify "omega" instead of "rpm", namely:     or the equivalent specified in rad/s:     \verbatim         MRF         {             cellZone rotor;             origin (0 0 0);             axis (0 0 1);             omega 6.28319;         }     \endverbatim
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0012711) henry    2022-08-12 20:10	commit 7fdde885fee52173ebaf7d5e5e66fb7fab42482c

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3873	[OpenFOAM] Bug	minor	always	2022-08-08 17:51	2022-08-10 10:47
Reporter:	tniemi	Platform:
Assigned To:	will	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	test/fvMeshTools/cavity fails in dev when reconstructing time step 0.01
Description:	It seems that the cavity fvMeshTools test is failing in recent dev builds, probably related to https://github.com/OpenFOAM/OpenFOAM-dev/commit/c3ab7045135cb6e17f8d3e8ecaba41caab85d2c4. The first time step (0.005) gets reconstructed, but it fails with 0.01. Works, if directly issuing "reconstructPar -time 0.01" I'm not sure if this is just a problem with the test or could this be a problem in some actual case, I just bumped into this because automatic build pipeline was failing.
Tags:
Steps To Reproduce:	Run test/fvMeshTools/Allrun and check cavity/log.reconstrucPar --> FOAM FATAL ERROR: cannot find file "/u1/common/OpenFOAM/OpenFOAM-dev/test/fvMeshTools/cavity/0.01/polyMesh/cellProc"     From function virtual Foam::autoPtr<Foam::ISstream> Foam::fileOperations::uncollatedFileOperation::readStream(Foam::regIOobject&, const Foam::fileName&, const Foam::word&, bool) const     in file global/fileOperations/uncollatedFileOperation/uncollatedFileOperation.C at line 539. FOAM exiting
Additional Information:
Attached Files:

Notes
(0012708) tniemi    2022-08-10 07:14	Also postProcessing/channel test fails due to postProcess -> foamPostProcess change. Instead of runApplication -s postProcess $(getApplication) -postProcess -latestTime there should be something like runApplication -s postProcess foamPostProcess -solver fluid -latestTime Or alternatively define a getSolver-helper and then runApplication -s postProcess foamPostProcess -solver $(getSolver) -latestTime
(0012709) henry    2022-08-10 09:28    (Last edited: 2022-08-10 09:38)	I have updated the postProcess command: commit 19f984d58dd420ee621f4b8b5d202d8a59777f35 and added a get solver function and updated the tutorials and tests: commit bfa40570adaedfeafc07b670ed7b0624a5ab37a5
(0012710) will    2022-08-10 10:47	Thanks. It's because the serial mesh has changed **and** the processor mesh has changed, so reconstructPar doesn't know what to do. That workflow is highly unlikely to appear in an actual case. Fixed in dev by https://github.com/OpenFOAM/OpenFOAM-dev/commit/436c6e4403b6ddc7b82e5451884b1d11b578f3e9

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3870	[OpenFOAM] Bug	minor	always	2022-08-02 06:58	2022-08-02 08:41
Reporter:	hsncelik	Platform:	GNU/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:	"could not open file meshToMesh.H for source file" warning during compilation
Description:	wmake atmosphericModels gives the following warnings, probably related to added support for changes in decomposition between meshes: could not open file meshToMesh.H for source file atmosphericTurbulentTransportModels.C due to No such file or directory could not open file meshToMesh.H for source file derivedFvPatchFields/atmBoundaryLayer/atmBoundaryLayer.C due to No such file or directory could not open file meshToMesh.H for source file derivedFvPatchFields/nutkAtmRoughWallFunction/nutkAtmRoughWallFunctionFvPatchScalarField.C due to No such file or directory could not open file meshToMesh.H for source file derivedFvPatchFields/atmBoundaryLayerInletK/atmBoundaryLayerInletKFvPatchScalarField.C due to No such file or directory could not open file meshToMesh.H for source file derivedFvPatchFields/atmBoundaryLayerInletEpsilon/atmBoundaryLayerInletEpsilonFvPatchScalarField.C due to No such file or directory could not open file meshToMesh.H for source file derivedFvPatchFields/atmBoundaryLayerInletVelocity/atmBoundaryLayerInletVelocityFvPatchVectorField.C due to No such file or directory could not open file meshToMesh.H for source file porosityModels/powerLawLopesdaCosta/powerLawLopesdaCosta.C due to No such file or directory Adding -lsampling to the options file would solve the issue.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0012699) henry    2022-08-02 08:41	Resolved by commit 9fc05a6d2e1d11edbef4d41d838ef2d2bd33ed4a

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3868	[OpenFOAM] Patch	minor	always	2022-07-29 11:01	2022-07-30 22:20
Reporter:	lorenzotrevisan	Platform:	x86_64
Assigned To:	henry	OS:	Slackware
Priority:	normal	OS Version:	15.0
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	in tutorials/multiphase/compressibleInterFoam/RAS/damBreak/Allclean cleanCase could be replaced with cleanVoFCase
Description:	in new tutorial multiphase/compressibleInterFoam/RAS/damBreak Allclean script cleanCase command could be replaced with cleanVoFCase in order to remove unnecessary BCs 0/T.air and 0/T.water when cleaning case.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012697) henry    2022-07-30 22:20	Resolved by commit 3bcfdb1ae30b071b0da66dad80acdc30ed9c34ea

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3866	[OpenFOAM] Bug	crash	always	2022-07-22 18:50	2022-07-28 11:14
Reporter:	edwardji2005	Platform:	linux
Assigned To:	will	OS:	Ubuntu
Priority:	normal	OS Version:	20.04
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	patchFlowRateInjection + SprayCloud
Description:	Hello, When the patchFlowRateinjection is used in the SprayCloud, the Floating point exception always happens. After having debugged, I found the error is from the constructor of the class SprayCloud at the line of "averageParcelMass_ = this->injectors().averageParcelMass(); ". This line is called from the InjectionModelList.C file, and will return a value of mass/massTotal. However, When the patchFlowRateinjection is used, the constructor of patchFlowRateinjection will initialize the variable massTotal as zero (this->massTotal_ = 0.0; ) no matter which value of massTotal in the file sprayCloudProperties is used. Due to the zero massTotal, the Floating point exception happens when the expression of the "mass/massTotal" in the InjectionModelList.C file is evaluated. Could you please check it? Thanks a lot Edward
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012695) will    2022-07-27 16:51	The problem is that the concept of an "averageParcelMass" based on total injected quantities makes no sense for an injection which simply creates particles at a rate proportional to the flow rate of the carrier. It really shouldn't be part of the injection model's interface. Fortunately, "averageParcelMass" is only actually used in one breakup model (ReitzKHRT), so it is only a very small subset of the functionality that remains incompatible with the patch flow rate injection. The code will now raise a "NotImplemented" error if this combination is requested. Considered fixed in dev and in version 10. https://github.com/OpenFOAM/OpenFOAM-10/commit/b2f0c22c5002ec162897665260a59dab987cc8e8 https://github.com/OpenFOAM/OpenFOAM-dev/commit/32bef33f4c03d734161546d910dfe937a71209cb

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3857	[OpenFOAM] Bug	minor	always	2022-07-07 18:30	2022-07-28 06:45
Reporter:	mturcios777	Platform:	x86_64
Assigned To:		OS:	Ubuntu
Priority:	none	OS Version:	18.04
Status:	new	Product Version:	dev
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	reactingFoam solver crashes in parallel, not in serial
Description:	When running a decomposed case in parallel using reactingFoam and layeredEngine fvMeshMover, the solver crashes at the same place (327 CAD), when solving for the energy equation
Tags:
Steps To Reproduce:	1. Unpack test case 2. Navigate to reactingFoamTest/workDir 2. Run decomposePar 2. Run mpirun -np 24 reactingFoam -parallel
Additional Information:	A few tests that were run before reporting: 1) Run solver in serial, case ran to completion 2) Run rhoPimpleFoam, case in serial and parallel, case ran to completion 3) Run case on different machine under Ubuntu 20.04 LTS, case ran to completion (though different number of processors) Using SYSTEMPI on all configurations. Including the crash stack trace. This case worked with previous versions of OpenFOAM
System Description
Attached Files:	error.txt (134,404 bytes) 2022-07-07 18:30 https://bugs.openfoam.org/file_download.php?file_id=3323&type=bug

Notes
(0012665) henry    2022-07-07 18:47	It might take some time test and update your case to run reliably for which you will need to purchase support.
(0012666) peksa    2022-07-07 19:40	If you have the case attached, I could try to reproduce this. I have both Ubuntu18.04 and 20.04 available via WSL. Sounds a weird problem that it crashes only on one machine...
(0012667) mturcios777    2022-07-07 21:48	The case didn't upload as I need to include the mesh. Can I give you a onedrive link?
(0012668) peksa    2022-07-08 05:10	Sure, oneDrive is ok.
(0012669) mturcios777    2022-07-08 09:45	@peksa, send me an email: marco (dot) turcios (at) gmail.com and I'll send you the link
(0012670) peksa    2022-07-11 08:14	Hi, I was not able to reproduce your problem. I tried the following configurations which were all succesfull: 1) WSL Ubuntu 18.04 - OpenMPI-2.2.1 - decomposition 4 cores and 8 cores 2) WSL Ubuntu 20.04 - OpenMPI-4.0.3 - decomposition 4 cores and 8 cores 3) Centos-7 - OpenMPI-1.10.7 - decomposition 24 cores In all cases OpenFoam-dev was compiled from sources. Are you facing any issues with other cases in parallel with your machine which could give some further insight to this?
(0012671) mturcios777    2022-07-11 18:33	Some additional notes: No other parallel issues have been detected. We did notice that using a different number of processors (16 or fewer) helped the case run, and also using PiBCGStab as the matrix solver. When reviewing the Debug log, the solver crashes at line 164 of PiBCG.C: https://github.com/OpenFOAM/OpenFOAM-dev/blob/c70a7b83d67ca46530b13cf66070c69f8dd27f44/src/OpenFOAM/matrices/lduMatrix/solvers/PBiCG/PBiCG.C#L164         scalar wArT = 0;         // --- Select and construct the preconditioner         autoPtr<lduMatrix::preconditioner> preconPtr =         lduMatrix::preconditioner::New         (             *this,             controlDict_         );         // --- Solver iteration         do         {             // --- Store previous wArT             const scalar wArTold = wArT;             // --- Precondition residuals             preconPtr->precondition(wA, rA, cmpt);             preconPtr->preconditionT(wT, rT, cmpt);             // --- Update search directions:             wArT = gSumProd(wA, rT, matrix().mesh().comm());             if (solverPerf.nIterations() == 0)             {                 for (label cell=0; cell<nCells; cell++)                 {                     pAPtr[cell] = wAPtr[cell];                     pTPtr[cell] = wTPtr[cell];                 }             }             else             {                 const scalar beta = wArT/wArTold; PiBCGStab handles this differently. We are fine using PiBCGStab if it offers the same functionality, but it seems like there is a race condition or something where wArTold on some processors still has the zero value and we end up dividing by it. Is this a problem with MPI, compilation or the PiBCG solver?
(0012672) peksa    2022-07-12 07:10	Is the crash happening always with your particular machine? What iff you perturb the initial conditions slightly? Have you tested to write the previous time step (w.r.t crash) so you could try to reproduce the issue via restart? I'm just wondering if the flow/energy field would show some issue leading to crash? I have used PiBCGStab since its appearance and can recommend it as well.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3856	[OpenFOAM] Bug	minor	always	2022-07-05 18:47	2022-07-16 22:51
Reporter:	Tiberias_	Platform:	GNU/Linux
Assigned To:	henry	OS:	Fedora
Priority:	normal	OS Version:	36
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	#calcEntry in blockMeshDict produces IO Error with GCC 12
Description:	When building OpenFOAM dev, 9 or 8 with gcc 12.1 blockMesh gives following error: Create time Reading "blockMeshDict" Creating block mesh from     "system/blockMeshDict" Using #calcEntry at line 34 in file "/home/user/documents/workDir/3_fine_t/system/blockMeshDict" --> FOAM FATAL IO ERROR: error in IOstream "OSHA1stream.sinkFile_" for operation Ostream& operator<<(Ostream&, const string&) file: OSHA1stream.sinkFile_ at line 0.     From function virtual bool Foam::IOstream::check(const char*) const     in file db/IOstreams/IOstreams/IOstream.C at line 96. FOAM exiting calc entries looks like lx #calc "$xmax - $xmin"; ly #calc "$ymax - $ymin"; lz #calc "$zmax - $zmin"; xcells #calc "abs($lx / $dx)"; ycells #calc "abs($ly / $dy)"; zcells #calc "abs($lz / $dz)"; When building with gcc 11.2 at RHEL blockMesh works without problems.
Tags:
Steps To Reproduce:	build OpenFOAM dev with GCC 12.1 run any blockMesh case with calc entries
Additional Information:
System Description
Attached Files:

Notes
(0012658) henry    2022-07-05 22:08	There appears to be bugs in the optimiser in gcc-12.1, if you compile with -O0 it will run fine. I am currently using gcc-10.1 without any problems.
(0012659) Tiberias_    2022-07-06 00:28	I just compiled OF-dev with disabled optimising and for some reason the above error appears again. Just to make sure I did the right things, I changed the -O3 parameter in OpenFOAM-dev/wmake/rules/linux64Gcc/ to -O0. The parameter was also present during the compilation process.
(0012660) henry    2022-07-06 07:46	Yes this is the correct change, you would need to recompile the main OpenFOAM library. I have investigated the problem further and traced it to the sha1streambuf::xsputn function. According to the C++-11 standard this function may call an overload function (which is not currently provided): https://cplusplus.com/reference/streambuf/streambuf/xsputn/     Its default behavior in streambuf is to retrieve n characters, as if calling sputc for each, stopping if any call would return EOF. Except it is unspecified whether member overflow is called or whether other means are used in case of overflows. https://cplusplus.com/reference/streambuf/streambuf/overflow/     int overflow (int c = EOF);     Put character on overflow     Virtual function called by other member functions to put a character into the controlled output sequence without changing the current position.     It is called by public member functions such as sputc to write a character when there are no writing positions available at the put pointer (pptr).     Its default behavior in streambuf is to always return EOF (indicating failure), but derived classes can override this behavior to attempt to write the character directly and/or to alter pptr and other internal pointers so that more storage is provided, potentially writing unwritten characters to the controlled output sequence. Both filebuf and stringbuf override this virtual member function.     Parameters     c     Character to be put.     If this is the end-of-file value (EOF), no character is put, but the other effects of calling this function are attempted. Return Value     In case of success, the character put is returned, converted to a value of type int_type using member traits_type::to_int_type.     Otherwise, it returns the end-of-file value (EOF) either if called with this value as argument c or to signal a failure (some implementations may throw an exception instead). It looks like the gcc-12.1 implementation requires the overflow function whereas previous implementations didn't. I will work on this today.
(0012661) henry    2022-07-06 09:31	I implemented a dummy sha1streambuf::overflow(int c = EOF) which just prints a message and it is indeed called when compiled with gcc-12.1 but not with gcc-10.1. I will now implement the body of this function according to the C++11 specification and test.
(0012662) henry    2022-07-06 17:04	Try this: commit 0aabdbf4a796d7e1d3d53e9ce2db5fda2b8f5003 Author: Henry Weller <http://cfd.direct> Date: Wed Jul 6 16:58:44 2022 +0100     OSHA1stream: Updated to C++11          According to the C++11 standard the xsputn might call an overload function which     must be provided for correct operation and is required by gcc-12.1 but not     earlier releases.          See          https://cplusplus.com/reference/streambuf/streambuf/xsputn/              Its default behavior in streambuf is to retrieve n characters, as if calling         sputc for each, stopping if any call would return EOF. Except it is         unspecified whether member overflow is called or whether other means are         used in case of overflows.          https://cplusplus.com/reference/streambuf/streambuf/overflow/              int overflow (int c = EOF);                  Put character on overflow                  Virtual function called by other member functions to put a character             into the controlled output sequence without changing the current             position.                  It is called by public member functions such as sputc to write a             character when there are no writing positions available at the put             pointer (pptr).                  Its default behavior in streambuf is to always return EOF (indicating             failure), but derived classes can override this behavior to attempt to             write the character directly and/or to alter pptr and other internal             pointers so that more storage is provided, potentially writing unwritten             characters to the controlled output sequence. Both filebuf and stringbuf             override this virtual member function.              Parameters c             Character to be put.             If this is the end-of-file value (EOF), no character is put, but the other effects of calling this function are attempted.              Return Value             In case of success, the character put is returned, converted to a value             of type int_type using member traits_type::to_int_type.                  Otherwise, it returns the end-of-file value (EOF) either if called with             this value as argument c or to signal a failure (some implementations             may throw an exception instead).          Resolves bug-report https://bugs.openfoam.org/view.php?id=3856
(0012663) Tiberias_    2022-07-06 22:22	Works without problems now, blockMesh compiles dynamicCode as expected. Thanks for the fast response on that issue!
(0012664) henry    2022-07-06 22:42	Resolved in OpenFOAM-9 by commit b0c15bebd37142f3902901ed5e9a60e33ed456eb Resolved in OpenFOAM-dev by commit 0aabdbf4a796d7e1d3d53e9ce2db5fda2b8f5003

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3864	[OpenFOAM] Bug	crash	always	2022-07-15 17:34	2022-07-15 21:04
Reporter:	flavio.galeazzo	Platform:	AMD EPYC
Assigned To:	henry	OS:	CentOS
Priority:	normal	OS Version:	8
Status:	resolved	Product Version:	10
Product Build:		Resolution:	no change required
Projection:	none
ETA:	none	Fixed in Version:	10
		Target Version:
Summary:	Compilation error of FvFaceCellWave.C using GCC 9.2
Description:	I downloaded fresh from the repository OF-10 and OF-dev, and for both I got a compilation error for the file src/finiteVolume/algorithms/FvFaceCellWave/FvFaceCellWave.C The error message is below. wmake src/finiteVolume/ g++ -std=c++14 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=64 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -I/lustre/hpe/ws10/ws10.0/ws/hpcfcunh-HAWK_5/OpenFOAM/OpenFOAM-dev/src/triSurface/lnInclude -I/lustre/hpe/ws10/ws10.0/ws/hpcfcunh-HAWK_5/OpenFOAM/OpenFOAM-dev/src/meshTools/lnInclude -IlnInclude -I. -I/lustre/hpe/ws10/ws10.0/ws/hpcfcunh-HAWK_5/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude -I/lustre/hpe/ws10/ws10.0/ws/hpcfcunh-HAWK_5/OpenFOAM/OpenFOAM-dev/src/OSspecific/POSIX/lnInclude -fPIC -c algorithms/FvFaceCellWave/FvFaceCellWaveName.C -o /lustre/hpe/ws10/ws10.0/ws/hpcfcunh-HAWK_5/OpenFOAM/OpenFOAM-dev/platforms/linux64Gcc92DPInt64Opt/src/finiteVolume/algorithms/FvFaceCellWave/FvFaceCellWaveName.o In file included from algorithms/FvFaceCellWave/FvFaceCellWave.H:369,                  from algorithms/FvFaceCellWave/FvFaceCellWaveName.C:26: algorithms/FvFaceCellWave/FvFaceCellWave.C: In constructor ‘Foam::FvFaceCellWave<Type, TrackingData>::FvFaceCellWave(const Foam::fvMesh&, Foam::List<T>&, Foam::List<Foam::List<T> >&, Foam::List<T>&, TrackingData&)’: algorithms/FvFaceCellWave/FvFaceCellWave.C:747:9: error: no matching function for call to ‘Foam::FvFaceCellWave<Type, TrackingData>::sizesListList<Foam::List<Foam::PackedBoolList> >(Foam::labelList, bool)’   747 | )       | ^ In file included from algorithms/FvFaceCellWave/FvFaceCellWaveName.C:26: algorithms/FvFaceCellWave/FvFaceCellWave.H:250:25: note: candidate: ‘template<class Type, class TrackingData> template<class ListList, class Value> static ListList Foam::FvFaceCellWave<Type, TrackingData>::sizesListList(const labelList&, const Value&)’   250 | static ListList sizesListList(const labelList& s, const Value& value);       | ^~~~~~~~~~~~~ algorithms/FvFaceCellWave/FvFaceCellWave.H:250:25: note: template argument deduction/substitution failed: In file included from algorithms/FvFaceCellWave/FvFaceCellWave.H:369,                  from algorithms/FvFaceCellWave/FvFaceCellWaveName.C:26: algorithms/FvFaceCellWave/FvFaceCellWave.C:747:9: note: mismatched types ‘const Value’ and ‘bool’   747 | )       | ^ make: *** [/lustre/hpe/ws10/ws10.0/ws/hpcfcunh-HAWK_5/OpenFOAM/OpenFOAM-dev/wmake/rules/General/transform:26: /lustre/hpe/ws10/ws10.0/ws/hpcfcunh-HAWK_5/OpenFOAM/OpenFOAM-dev/platforms/linux64Gcc92DPInt64Opt/src/finiteVolume/algorithms/FvFaceCellWave/FvFaceCellWaveName.o] Error 1
Tags:
Steps To Reproduce:	Fresh repo and ./Allwmake
Additional Information:	System with AMD EPYC CPUs, CentOS 8, GCC 9.2, MPT 2.23
Attached Files:

Notes
(0012684) henry    2022-07-15 19:38	I just compiled OpenFOAM-dev with gcc-9.5.0, no errors, no warnings, no problems of any kind. Given that there have been 5 patch released of gcc-9 I assume that lots of bugs have been found and you should upgrade your gcc-9.2 to a more recent patch release or better still a more recent gcc version.
(0012685) flavio.galeazzo    2022-07-15 20:33	I confirm that I got OF-10 compiled using GCC 10.2. Thank you for the help.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3854	[OpenFOAM] Bug	minor	always	2022-07-01 13:12	2022-07-01 15:56
Reporter:	StasF1	Platform:	Unix
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:	moveMesh does not work with new dynamicMeshDict structure
Description:	moveMesh utility does not work with updated dynamicMeshDict structure.
Tags:
Steps To Reproduce:	In $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/movingCone/controlDict set application value to moveMesh ant try run the case using Allrun.
Additional Information:	--> FOAM FATAL IO ERROR: keyword motionSolver is undefined in dictionary "/m/work/t212/unix/work/stashes1/OpenFOAM/projects/cleanPropulsionInjection/run/ECNSprayD/RAS/moveMesh/movingCone/constant/dynamicMeshDict" file: /m/work/t212/unix/work/stashes1/OpenFOAM/projects/cleanPropulsionInjection/run/ECNSprayD/RAS/moveMesh/movingCone/constant/dynamicMeshDict from line 19 to line 38.     From function T Foam::dictionary::lookup(const Foam::word&, bool, bool) const [with T = Foam::word]     in file /m/home/home4/42/stashes1/unix/.local/opt/OpenFOAM-dev/src/OpenFOAM/lnInclude/dictionaryTemplates.C at line 43. FOAM exiting
System Description
Attached Files:

Notes
(0012654) henry    2022-07-01 13:57	Try moveDynamicMesh, it should handle all mesh motion and changes. My plan is to remove the old moveMesh and rename moveDynamicMesh -> moveMesh is would be more obvious to the users.
(0012655) henry    2022-07-01 15:56	Resolved by commit 31da3ac2c677da0567c79aee40545b676c206021

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3853	[OpenFOAM] Patch	tweak	always	2022-06-25 13:41	2022-06-25 15:29
Reporter:	cgoessni	Platform:	amd64
Assigned To:	henry	OS:	Debian
Priority:	low	OS Version:	stable
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	small error in error message in decomposePar
Description:	diff --git a/applications/utilities/parallelProcessing/decomposePar/decomposePar.C b/applications/utilities/parallelProcessing/decomposePar/decomposePar.C index cc6370f76..10d9b66b1 100644 --- a/applications/utilities/parallelProcessing/decomposePar/decomposePar.C +++ b/applications/utilities/parallelProcessing/decomposePar/decomposePar.C @@ -288,7 +288,7 @@ int main(int argc, char *argv[])          {              FatalErrorInFunction                  << "Cannot combine geometry-only decomposition (-noFields)" - << " with field decomposition (-noFields or -copyZero)" + << " with field decomposition (-fields or -copyZero)"                  << exit(FatalError);          }      }
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0012653) henry    2022-06-25 15:29	Resolved by commit cf3a732789ebbbc734f39fae16b591bf0e6a7a7b

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3852	[OpenFOAM] Bug	minor	always	2022-06-24 19:26	2022-06-24 19:46
Reporter:	cgoessni	Platform:	amd64
Assigned To:	henry	OS:	Debian
Priority:	normal	OS Version:	stable
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	decomposePar -ifRequired does not work
Description:	According to the manual page, -ifRequired should run decomposePar if the number of processors has changed:   -ifRequired only decompose geometry if the number of domains has changed However, it would still error out when the number of processors has changed: --> FOAM FATAL ERROR: Case is already decomposed with 18 domains, use the -force option or manually remove processor directories before decomposing. e.g.,     rm -rf /home/clemens/OpenFOAM/clemens-dev/run/kivaTest/processor*
Tags:
Steps To Reproduce:	Take kivaFoam, decompose it with any number of processors, change the number of processors in decomposeParDict and run "decomposePar -ifRequired"
Additional Information:
Attached Files:

Notes
(0012652) henry    2022-06-24 19:46	Resolved by commit 4745b9761da3f644de413a3031331c787702f9f8

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3851	[OpenFOAM] Bug	minor	always	2022-06-24 08:51	2022-06-24 11:38
Reporter:	deo	Platform:	GNU/Linux
Assigned To:	henry	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Implementation of operator=(diagTensor) missing in Tensor class?
Description:	tensor test;     test = diagTensor(1,2,3); fails to compile: /software/OpenFOAM/OpenFOAM-9/src/OpenFOAM/lnInclude/Tensor.H:208:21: warning: inline function ‘void Foam::Tensor<Cmpt>::operator=(const Foam::DiagTensor<Cmpt>&) [with Cmpt = double]’ used but never defined          inline void operator=(const DiagTensor<Cmpt>&);                      ^~~~~~~~ and: undefined reference to `Foam::Tensor<double>::operator=(Foam::DiagTensor<double> const&)' collect2: error: ld returned 1 exit status make: *** [/software/OpenFOAM/OpenFOAM-9/wmake/makefiles/general:154: build/Test-hexaScalar] Error 1 Implementation is indeed missing from TensorI.H.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012647) cgoessni    2022-06-24 10:24	I don't think that you can use the constructor of diagTensor like that. Try with New/new.
(0012648) deo    2022-06-24 10:40	Why not? And why would it work with symmTensor then?     tensor test;     diagTensor test2(1,2,3);     symmTensor test3(1,2,3,4,5,6);     test = test2; // Fails to compile     test = test3; // Compiles     test = diagTensor(1,2,3); // Fails to compile     test = symmTensor(1,2,3,4,5,6); // Compiles Again, I think the implementation of operator=(diagTensor) is missing from the Tensor class.
(0012649) cgoessni    2022-06-24 11:03	Then please ignore my comment, my C++ is a bit rusty.
(0012651) henry    2022-06-24 11:38	Resolved by commit 2628dfe679ffee0f2613073b0dfba428875f3b59

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3850	[OpenFOAM] Bug	major	always	2022-06-22 05:48	2022-06-24 11:34
Reporter:	mturcios777	Platform:	Linux
Assigned To:	henry	OS:	Ubuntu
Priority:	high	OS Version:	20.04 LTS
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Lagrangian injection uses realtime, but TimeFunction1 integral expects userTimes and can't follow flowRate as written
Description:	I am currently working on updating our lagrangian models using userTime with engine models to work in OF-dev and was having trouble matching the flowRate profile. The massTotal is correct, but the flow profile does not. In searching through the InjectionModel.C and the various implementations, the problem seems to occur in the volumeToInject function. According to the code, SOI, duration and the time arguments used to integrate are all in seconds; for example in ConeNozzle: Conversion of duration: https://cpp.openfoam.org/dev/ConeInjection_8C_source.html#l00189 volumeToInject: https://cpp.openfoam.org/dev/ConeInjection_8C_source.html#l00288 However, volumeToInject uses the integral function for TimeFunction1, which expects userTime and converts to time: https://cpp.openfoam.org/dev/TimeFunction1_8C_source.html#l00094 There appears to be inconsistency in where the conversion of values should occur I have been using mass basis parcels so that the total target mass is always injected. With the integration inconsistency, the flowRate is essentially truncated at whatever the duration scaled to real time is
Tags:
Steps To Reproduce:	I am working on a test case to upload without proprietary information, but the basic steps are: 1) Create a case with a cloud that has a userTime (engine cases with any kind of injector should suffice) 2) Specify the duration,flowRate and SOI in the appropriate userTime (Crank angle degrees in an engine case) 3) Make the parcelBasis mass so that the total mass at the end of injection is respected no matter what 3) Run the simulation and plot the liquid mass injected
Additional Information:	Converting the flowRate to time does nothing as the initial scaling and truncation happen when volumeTotal is calculated.
System Description
Attached Files:	aachenEngineInjTest.tar.gz (178,315 bytes) 2022-06-22 06:54 https://bugs.openfoam.org/file_download.php?file_id=3321&type=bug aachenEngineInjTest.tar-2.gz (178,305 bytes) 2022-06-22 07:36 https://bugs.openfoam.org/file_download.php?file_id=3322&type=bug

Notes
(0012630) mturcios777    2022-06-22 06:54	Test case with logfiles of liquid injected mass, columns are: Time numbeParcelsAdded massIntroduced liquidPenetration
(0012631) mturcios777    2022-06-22 07:36	Updated case to have separate files for time and userTime injection flowRate profiles
(0012632) henry    2022-06-22 09:05	> According to the code, SOI, duration and the time arguments used to integrate are all in seconds Would you rather the injection specification were in CA or seconds? We discussed this when updating the implementation and concluded that seconds would probably be better for injectors.
(0012633) henry    2022-06-22 11:25	The injection models convert the start of injection and duration from userTime to time:     SOI_ = owner.db().time().userTimeToTime(SOI_);     duration_ = owner.db().time().userTimeToTime(duration_); Would you rather all injection specification were in real time or some in real time and some in user time?
(0012634) henry    2022-06-22 13:33	If the profiles are specified in user-time I think TimeFunction1 should be changed thus: template<class Type> Type Foam::TimeFunction1<Type>::value(const scalar x) const {     return function_->value(time_.timeToUserTime(x)); } template<class Type> Type Foam::TimeFunction1<Type>::integral (     const scalar x1,     const scalar x2 ) const {     return         time_.userTimeToTime(1)        *function_->integral         (             time_.timeToUserTime(x1),             time_.timeToUserTime(x2)         ); } I am not sure how to run your case or analyse or interpret the results, could you test this change and let me know if it resolves the issue.
(0012635) mturcios777    2022-06-22 14:59	Thank you for looking into this. Prior to the change in how time is handled, if a simulation was an engine simulation then everything was specified in userTime. I think having all inputs to be in userTime would require the least modifications to the codebase. I will test the proposed code change and get back to you. I also realize I didn't leave enough instructions, it was super late when I finished that case. The case uses reactingFoam. There is an include statement at the top of the system/controlDict in workDir, as well as in constant/liquidSprayProperties. To run the case as an engine case, change these includes to #include"../../masterSheet.txt.CAD" To run as a regular case, change the include to #include"../../masterSheet.txt.time" And temporarily remove the dynamicMeshDict
(0012636) henry    2022-06-22 15:04	> I think having all inputs to be in userTime would require the least modifications to the codebase. Changing these inputs from user-time to time is easy and if it makes more sense to the users I am happy to make the change. I am not sure what the most common specification for injection in engines is so I will need input from the users of this functionality.
(0012637) peksa    2022-06-22 17:22	This is a tricky design choice indeed. Injection, and in particular, injection duration, is a specific event which may not be intuitively correlated with the engine CAD time because then change in RPM would implicitly change the injection event, which in my opinion, results in easy mistakes and would require subsequent injection setup changes. On the other hand, different RPM requires typically different injection profile anyway... Typically, fuel injection mass/volume flow rate profiles are estimated based on specific numerical tools or by experiments. Such profiles are typically expressed in SI units and when considering duration, it is estimated/given based on knowledge on injector control signals, expressed in seconds. However, start of injection (SOI) in user input dictionary is easiest to keep in CAD grasp on when the injection takes place. Hence, for me the most logical input types would be: - SOI: engineTime [CAD] - profiles: SI units [m3/s or kg/s] - duration: [seconds] Of course, the above has a drawback of mixing units which is not a good habit either. In the end, I believe that users create injection setups / profiles with some sort of script outside openfoam so I think clarity should be weighted most here. Any ideas / comments mturcios777 ?
(0012638) mturcios777    2022-06-22 17:43	@henry, the proposed fix does solve the problem and the flowRateProfile when specified in userTime is respected. We did have a concern that other libraries and objects that use TimeFunction1 may not function properly though if they assume that input is in userTime. An alternative solution so that the flowProfile is in time which we have tested is to change any calls to value and integrate in ALL the injection models to use converted userTime. Searching through the code the injection models are the only place TimeFunction1 is used. A third alternative is to use Function1 insteam of timeFunction1 and assume the user always has their profile correct. We have not tested this. @peksa, in previous versions of OpenFOAM with the specific engineTime class, all the user inputs had to be CAD. This made sense to us as we have pre-processing scripts where RPM is an input parameter and the flowProfile is created in crank angle. I think most users would have a similar means of converting profiles.
(0012639) mturcios777    2022-06-22 18:16	Here is input from a colleague who helped find the issue and propose the second possible workaround, for additional information: Just to insist, the current implementation of the InjectorModels is inconsistent/bugged with the current design choice to convert all time-related variables in realTime (not userTime) and give the flowRateProfile in realTime (not userTime). Indeed, the value() and integral() functions of the TimeFunction1 class (used to evaluate and integrate the flowRateProfile in InjectionModels), in their current implementation, take inputs in userTime (not realTime) and convert them to realTime using the function userTimeToTime(), as the flowRateProfile is given in realTime by design. However, the variables fed to the functions value() and integral() in the InjectionModels are in realTime (design choice), whereas to use these functions the variables should be in fact in userTime. This results in an erroneous behavior of the InjectorModel in all instances where userTime is not realTime. A proposed fix for the current design choice of converting all time variables to realTime and to keep the flowRateProfile in realTime is to convert to userTime the inputs of the functions value() and integral() using owner.db().time().timeToUserTime(x) in all calls to flowRateProfile.value() and flowRateProfile.integral() in the InjectorModels (not in TimeFunction1). An alternative solution would be the proposed above fix, where all time variables are converted to realTime but the flowRateProfile is given in userTime, and where the evalute() and integral() functions of TimeFunction1 read in realTime variables and convert them to userTime (as the flowRateProfile is in userTime by design in this scenario). Another solution is to keep all time variables in userTime as well as the flowRateProfile in the InjectionModels and to use the time variables as is in the functions value() and integrate() of TimeFunction1.
(0012640) henry    2022-06-22 18:46    (Last edited: 2022-06-22 18:59)	I am capable if implementing any of the options, I just need to know which of the user inputs should be in CA and which is seconds.
(0012641) mturcios777    2022-06-22 22:13	I will consult internally and get back to you by the end of the week. On a design/architechture side, is there a reason we have the addition of TimeFunction1 and Function1. Is it to reduce the amount of conversions required for userTimes? In any case, some documentation in the injectors and TimeFunction1 laying out which times are expected as arguments would be helpful, so we know when to supply them. Knowing that TimeFunction1 expects realTimes and integrates based on the equivalent userTime would have saved a lot of trouble in figuring out this bug.
(0012642) henry    2022-06-22 22:36	TimeFunction1 is more convenient to use if the input table or function is specified in user time, that is the point. If the input were to be specified in real time then Function1 would be used and TimeFunction1 could be deleted.
(0012643) cgoessni    2022-06-23 12:59	If we run our engine cases with injection, we normally specify the x-values, i.e. time, in CAD, i.e. userTime, and the y-values in SI units (kg/s)
(0012644) henry    2022-06-23 13:06	Is that your preference or what you do because that is what is currently supported in OpenFOAM?
(0012645) cgoessni    2022-06-23 14:13	This would be our preference. However, we currently do not have an injection setup in OpenFOAM (yet).
(0012646) mturcios777    2022-06-23 22:18	Our preference would also be that the flowRate be specified in userTime.
(0012650) henry    2022-06-24 11:34	Resolved by commit 9d50ffdfbb99a87bcf08bae7cfd5922ef07ad604

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3847	[OpenFOAM] Bug	crash	always	2022-06-07 15:06	2022-06-07 16:46
Reporter:	AliShaha	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:	Crash in running counterFlowFlame2D_GRI tutorial in parallel
Description:	OpenFoam crashes when running Allrun-parallel script in:  /OpenFOAM-dev/tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D_GRI Reason: inconsistency between the decompositionMethod and loadBalancer when multiConstraint is set to true. OpenFOAM-dev/src/fvMeshDistributors/loadBalancer/fvMeshDistributorsLoadBalancer.C, lines 148 and 150:         const int nWeights = cpuLoads.size() + 1;         weights.setSize(nWeights*mesh.nCells()); OpenFOAM-dev/blob/c1acd88a37fe7b74ec5cfc759c2d6ee32d5194b2/src/parallel/decompose/decompositionMethods/decompositionMethod/decompositionMethod.C, lines 691-697     if (nWeights > 0 && cellWeights.size() != mesh.nCells())     {         FatalErrorInFunction             << "Number of weights " << cellWeights.size()             << " differs from number of cells " << mesh.nCells()             << exit(FatalError);     } Balancer sets the cellWeights size to: (nWeights*nCells) however decompositionMethod throws error when (cellWeights.size() != mesh.nCells()).
Tags:
Steps To Reproduce:	~ cd /OpenFOAM-dev/tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D_GRI ~ ./Allrun-parallel
Additional Information:
System Description
Attached Files:

Notes
(0012626) henry    2022-06-07 16:46	Resolved by commit 39422ac00ae6aa40d6970fa03a1e0b4eefd2d208

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3817	[OpenFOAM] Bug	minor	random	2022-03-15 14:50	2022-05-19 08:57
Reporter:	michael.mueller-wrd	Platform:	GNU/Linux
Assigned To:	will	OS:	centOS
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	3D parallel simulation using cyclicAMI, decomposed using scotch; randomly runs or gives fatal error
Description:	When using cyclicAMI patches in a rotational symmetric 3D case, it may happen that (a) the case runs fine in parallel (e.g. np=128, np=256), and (b) the case fails to run with "FOAM FATAL ERROR: Unable to set sources and target faces" (e.g. np=32, np=192) depending on the number of processors. Serial simulation always runs fine, thus, there is not an error related to the cyclicAMI specification in polyMesh/boundary. For decomposition, scotch method was used and no constraints are defined in order to avoid imbalanced mesh distribution over processors. Case geometry is rather complex with sth. like 10-100M cells and a high number of cells connected to cyclicAMI patches. (The case should run on some 100s of processors.) I don't know if that is an actual bug or if there is a workaround to avoid the random behaviour. Anyway, the random behaviour in terms of at which no. of processors it still works and at which it throws an fatal error appears to be quite strange.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012596) will    2022-05-19 08:57	This issue should be resolved by the new Non-Conformal Coupled (NCC) development. The advancing front algorithm for generating the coupled geometry has been completely rewritten and bears no relation to the one used by AMI. So, I would assume that the failure mode that you have experienced is not present with NCC. https://github.com/OpenFOAM/OpenFOAM-dev/commit/569fa31d09f98e29d1aaf84d40bb16043f104ec6 I do not have access to the case, however (I assume it is large and problematic to share), so I cannot verify that it now runs with NCC. I am sure though that any issues with NCC will be sufficiently different from the issues with AMI that this bug report will not be of relevance. So, I'm considering it resolved. If you encounter any problems running this case with NCC, please contact us, or file a new bug report, as appropriate.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1422	[OpenFOAM] Bug	minor	always	2014-10-24 12:29	2022-05-19 08:47
Reporter:	dhora	Platform:
Assigned To:	will	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	neighbour face search in cyclicAMI
Description:	Problems can be observed if one patch of an (e.g. cylindrical) AMI interface is split by a baffle with zero thickness into two or more separate regions. The neighbour face search algorithm doesn't find all the neighbour faces and sum(weights) can deviate significantly from 1.
Tags:	AMI
Steps To Reproduce:
Additional Information:
Attached Files:	foam_ami.tar.gz (310,021 bytes) 2015-03-05 15:22 https://bugs.openfoam.org/file_download.php?file_id=999&type=bug tgtWeights.png (52,901 bytes) 2015-03-10 12:52 https://bugs.openfoam.org/file_download.php?file_id=1017&type=bug

Notes
(0003957) user4    2015-03-05 09:11	The neighbour search should re-start until all is covered. Do you have a (simple) testcase for this?
(0003963) dhora    2015-03-05 15:23	You can run the case with pimpleDyMFoam.
(0004065) user4    2015-03-10 12:58	We can replicate the problem. Attached the output from moveDynamicMesh -checkAMI at time 0.02408554. It is indeed the baffle which breaks the advancing front algorithm that finds the weights. Can you work around it while we think about this one?
(0004070) user4    2015-03-10 16:25	As a workaround: - make sure you don't have duplicated points on the baffle so the slave patch is continuous (you can see these duplicated points with checkMesh -allGeometry) - or put the static side faces in INT-SIDE-2, the rotating side faces in -1 again to do the same
(0004087) dhora    2015-03-11 16:59	It's not an urgent issue. Nevertheless, thanks a lot for the workaround.
(0012595) will    2022-05-19 08:47	This issue is resolved by the new Non-Conformal Coupled (NCC) development. NCC's advancing front algorithm remains correct even when the patch is split along a set of edges such as in this case. https://github.com/OpenFOAM/OpenFOAM-dev/commit/569fa31d09f98e29d1aaf84d40bb16043f104ec6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2274	[OpenFOAM] Bug	minor	always	2016-09-28 15:45	2022-05-18 11:15
Reporter:	Shorty	Platform:	GNU/Linux
Assigned To:	will	OS:	Ubuntu
Priority:	normal	OS Version:	16.04
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	ACMI Boundary does not let particle go through (act like a wall)
Description:	Dear all, the usage of the ACMI boundary condition in conjunction with particle flows is not working as expected. The ACMI boundary acts on the particles as a wall. The case attached is a simple modification of the oscillatingInlet tutorial with two particles. One of them should pass from one domain through the ACMI to the second one that is not possible at the moment.
Tags:	ACMI, cyclicACMI, icoUncoupledKineticParcelDyMFoam, parcels
Steps To Reproduce:	Execute the run script...
Additional Information:	I also tried the case without flow, while the gravity was the accelerating force for the particle. Although in this case, the particle just were kept by the ACMI wall.
System Description
Attached Files:	oscillatingInletACMI2D_particle.tar.gz (594,183 bytes) 2016-09-28 15:45 https://bugs.openfoam.org/file_download.php?file_id=1764&type=bug

Notes
(0006931) wyldckat    2016-09-28 16:39	This feels like it's identical to the issue #1836: http://bugs.openfoam.org/view.php?id=1836 If it is, then it's already fixed in the OpenFOAM-dev development line. Therefore, please try with OpenFOAM-dev before anyone else tries to debug this case.
(0006932) Shorty    2016-09-28 18:44	I checked the case with the latest OpenFOAM-dev version and the problem still exist. I also checked it with the AMI boundary condition. Here it is working. For the ACMI (attached) not. If you need the AMI case (that is working), let me know.
(0006945) MattijsJ    2016-09-30 12:24	You've got your patch interaction rebounding all particles if they hit the ACMI blockage patch. They might never hit the ACMI cyclic patch so never trigger the special handling for ACMI/AMI. What happens if you let the particles ignore the blockage patches?
(0006946) Shorty    2016-09-30 13:34	Hi Mattijs, I already tried it (i forgot to mention it). If I unset the interaction model - the parcel will stick to the wall and nothing more will happen. If I remove the [b]uncoupled[/b] ACMI patches from the interaction patches, I get the error that I have to specify all patches: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Selecting distribution model fixedValue Selecting dispersion model none Selecting patch interaction model localInteraction --> FOAM FATAL ERROR: All patches must be specified when employing local patch interaction. Please specify data for patches: 2 ( ACMI1_blockage ACMI2_blockage ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(0006977) MattijsJ    2016-10-07 09:40	Ok, the problem is that there are two faces on top of each other (blockage patch and cyclicACMI). If the particle would hit the cyclicACMI it would do the right thing, but if it hits the blockage it just regards it as a normal patch/wall. Since the two faces are on exactly the same location (since using the same points) it is probably the order of both faces in the cell next to it that determines which of these gets hit first. What needs to happen is for the blockage patch to 'know' that another patch determines the patch interaction.
(0012594) will    2022-05-18 11:15	This issue should be resolved by the new Non-Conformal Coupled (NCC) development. NCC does not use duplicate poly faces, so the issue in question will not occur. We have test cases (incompressible/pimpleFoam/RAS/ballValve) in which particles (streamlines) successfully cross partially overlapped couplings. https://github.com/OpenFOAM/OpenFOAM-dev/commit/569fa31d09f98e29d1aaf84d40bb16043f104ec6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
2561	[OpenFOAM] Bug	crash	always	2017-05-24 09:52	2022-05-18 11:14
Reporter:	niklas.wikstrom	Platform:	GNU/Linux
Assigned To:	will	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:	cyclicACMI makes rhoCentral(DyM)Foam crash due to surface interpolation issue
Description:	rhoCentralFoam crashes (sigFpe) immediately in time loop on a cases containing cyclicACMI patches. The cause of the sigFpe seems to be that "interpolate(rho,neg)" produces a zero rho_neg field, which is then used in the denominator to calculate U_neg (around line 88, rhoCentralFoam.C). Thank you.
Tags:	ACMI, cyclicACMI
Steps To Reproduce:	Unpack attached small case. run included makeMesh.sh script run rhoCentralDyMFoam (or rhoCentralFoam)
Additional Information:	Case runs as expected in OpenFOAM 3.x. Case runs in OpenFOAM 4.x/dev using "linear" interpolation. Case runs in OpenFOAM 4.x/dev using e.g. sonicFoam (For completeness: Tested on Fedora-25;gcc-6.3.1 and Centos-7.3;gcc-4.8.5)
System Description
Attached Files:	slidingBlockTestCase.tgz (7,909 bytes) 2017-05-24 09:52 https://bugs.openfoam.org/file_download.php?file_id=2079&type=bug cyclicACMIFvPatchField.C (8,252 bytes) 2017-06-23 16:30 https://bugs.openfoam.org/file_download.php?file_id=2103&type=bug

Notes
(0008185) niklas.wikstrom    2017-05-24 10:04	I should perhaps mention that the same issue appears in version 4.x
(0008238) MattijsJ    2017-06-23 16:30	The issue is in cyclicACMIFvPatchField<Type>::patchNeighbourField(). Uncoupled faces assume a patchNeighbour value of 0. Attached version assumes a patchNeighbour value of the blockage patch (for uncoupled faces). Needs a bit of testing.
(0008294) MattijsJ    2017-06-30 10:42	Above fix adjusts only the patchNeighbour value so will unfortunately make e.g. Gauss gradient incorrect on the partially overlapping bits since the coupled part should only include coupled contributions and the blockage part only the 'wall' contributions. We probably have to have the value field calculated separately, instead of being calculated from internal and neighbour field.
(0012593) will    2022-05-18 11:14	Numerical issues with ACMI-based patch couplings have been resolved by the new Non-Conformal Coupled (NCC) development. See the following commit for explanation, and instructions for how to use NCC and convert cases from AMI. https://github.com/OpenFOAM/OpenFOAM-dev/commit/569fa31d09f98e29d1aaf84d40bb16043f104ec6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1841	[OpenFOAM] Bug	minor	always	2015-08-28 11:31	2022-05-18 11:10
Reporter:	user1226	Platform:	GNU/Linux
Assigned To:	will	OS:	Ubuntu
Priority:	normal	OS Version:	14.04
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Abnormal Courant number and abnormal phase fractions in /multiphase/multiphaseInterDyMFoam/laminar/mixerVesselAMI2D
Description:	MultiphaseInterDyMFoam has been executed for the case of mixerVesselAMI2D for the first time, the calculation has been terminated at Time=0.411847, though that endTime is set to 5 [s]. (Case1) I started to investigate the cause by changing the time step (deltaT) and when deltaT=5e-7 (for Case1, deltaT=1e-6) the calculation continued to Time=1.13274. (Case2) But I soon realised that it does not matter how small deltaT is: even though deltaT=1e-9, the calculation is terminated at around Time=0.4. Then I compared the "alphas" of two cases (Case1 and Case2) using ParaView time by time and I found that air adjoining water seems to penetrate the impeller for Case 1 (See attached GIF file). For Case2, no such penetration is found. The calculation log of the both cases, however, show abnormal Courant number and phase fractions before the run is terminated.
Tags:	AMI
Steps To Reproduce:	When I tried 2 phases (air and water) instead of 4 phases, I could reproduce a similar phenomenon: abnormal Courant number and abnormal phase fractions before termination of calculation. So I guess, so far, that the combination of handling multiphase fluids with large difference of densities (1 kg/m^3 for air and 1000 kg/m^3 for water) and AMI interacts each other. In fact, I did not have such problem when I executed /multiphaseInterFoam/laminar/mixerVessel2D.
Additional Information:	The calculation of /multiphaseInterFoam/laminar/mixerVessel2D is normally ended: normal Courant number and normal phase fraction
System Description
Attached Files:	mixerVesselAMI2D_Case1.gif (204,488 bytes) 2015-08-28 11:31 https://bugs.openfoam.org/file_download.php?file_id=1310&type=bug

Notes
(0005310) henry    2015-08-28 11:39	This problem relates to the non-convervation problems with AMI for multiphase flow which have been reported and discussed here many times.
(0012592) will    2022-05-18 11:10	Numerical issues with AMI-based patch couplings have been resolved by the new Non-Conformal Coupled (NCC) development. See the following commit for explanation, and instructions for how to use NCC and convert cases from AMI. https://github.com/OpenFOAM/OpenFOAM-dev/commit/569fa31d09f98e29d1aaf84d40bb16043f104ec6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1829	[OpenFOAM] Bug	major	always	2015-08-17 07:46	2022-05-18 11:10
Reporter:	user1216	Platform:	GNU/Linux
Assigned To:	will	OS:	Debian
Priority:	high	OS Version:	3.16.7-ck
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	pressure jumps occur, when restarting rotating mesh simulation with interPhaseChangeDyMFoam
Description:	The problem occurs in both 2.3.x and 2.4.x. I started a cavitating propeller simulation using interPhaseChangeDyMFoam with cyclicAMI BCs and the rotating mesh motion defined in the constant/dynamicMesh dictionary. The simulation runs well and gives good qualitative results when started from time "0". The problem occurs when I restart the simulation from a later saved time step. I need to reduce the time step to do so, but if I do, the simulation is able to at least start running again. But just after the first simulated time step, there is then a total change of the pressure field, which gives me new maximum and minimum values of pressure, which are 2 to 3 orders of magnitude higher than they were before the restart! The influence is present in the whole fluid domain and basically destroys any pre-converged results. I checked whether the propeller position is correct at restart and it sure is. I tested this for my own propeller simulation, as well as for the tutorial case of interPhaseChangeDyMFoam. Thank you very much for your help.
Tags:
Steps To Reproduce:	Start a propeller simulation (e.g. interPhaseChangeDyMFoam propeller tutorial) with the rotatingMotion and cyclicAMIs. Wait until you see some sort of cavitation and save a time step where you restart the simulation from. Write the very next time step after restart and have a look at the pressure field, which should be totally disturbed in the whole domain.
Additional Information:	1. Read about the correctPhi bug in an older release. Tried to comment this out, but results were the same (crappy). 2. When I let the propeller rotate for some time, then restart with a small time step the pressure jumps occur whether I start with interPhaseChangeDyMFoam (with mesh rotation) or with interPhaseChangeFoam (without further mesh rotation) despite the propeller position being correct. 3. When starting a simulation without mesh rotation (but the same setup including the AMIs) using interPhaseChangeFoam, then restart the simulation at some time, this error does NOT occur, despite cavitation being there as well and so on. The only difference to the case where the error occurs is that there was rotation BEFORE the restart. This is why my guess is now that this has to do something with the rotatingMotion. 4. I simulated lots of cavitating simulations before with interPhaseChange(DyM)Foam and the restarts worked nicely all the time. But these simulations were all with stationary meshes... 5. The problem occurs in both 2.3.x and 2.4.x.
System Description
Attached Files:	stackOverflow_propellerError_02.png (75,609 bytes) 2015-08-17 07:46 https://bugs.openfoam.org/file_download.php?file_id=1292&type=bug stackOverflow_propellerError_01.png (39,190 bytes) 2015-08-17 07:47 https://bugs.openfoam.org/file_download.php?file_id=1293&type=bug

Notes
(0005254) user1216    2015-08-17 07:48	First image is after restart, second image is initial domain before restart.
(0012591) will    2022-05-18 11:10	Numerical issues with AMI-based patch couplings have been resolved by the new Non-Conformal Coupled (NCC) development. See the following commit for explanation, and instructions for how to use NCC and convert cases from AMI. https://github.com/OpenFOAM/OpenFOAM-dev/commit/569fa31d09f98e29d1aaf84d40bb16043f104ec6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1388	[OpenFOAM] Bug	minor	always	2014-09-01 06:03	2022-05-18 11:09
Reporter:	user863	Platform:	linux
Assigned To:	will	OS:	redhat
Priority:	normal	OS Version:	6.4
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	mass flow of AMI1 and AMI2 do not match in pimpleDyMFoam/propeller tutorial
Description:	Take the tutorial incompressible/pimpleDyMFoam/propeller and inspect the mass flow of AMI1 and AMI2 sum(AMI1) for phi = -1.79746e-09 sum(AMI2) for phi = 4.01012e-05 there are not the same. What is the reason of the difference? Why the 2 massflow are not identical?
Tags:	AMI
Steps To Reproduce:	1) open the tutorial incompressible/pimpleDyMFoam/propeller/ and in controlDict add the two following blocks to get the massFlow of AMI1 and AMI2 functions {     #include "readFields"     #include "Q"     #include "surfaces"     #include "forces"     massFlow_AMI1     {         type faceSource;         functionObjectLibs ("libfieldFunctionObjects.so");         outputControl timeStep;         log true;         // Output field values as well         valueOutput true; // false;         source patch;         sourceName AMI1;         operation sum;         surfaceFormat vtk;         fields         (             phi         );      }     massFlow_AMI2     {         type faceSource;         functionObjectLibs ("libfieldFunctionObjects.so");         outputControl timeStep;         log true;         // Output field values as well         valueOutput true; // false;         source patch;         sourceName AMI2;         operation sum;         surfaceFormat vtk;         fields         (             phi         );      } } 2) launch the Allrun and inspect the log.pimpleDyMFoam file, you will see that the AMI1 and AMI2 massFlow do not match.
Additional Information:
Attached Files:

Notes
(0012590) will    2022-05-18 11:09	Numerical issues with AMI-based patch couplings have been resolved by the new Non-Conformal Coupled (NCC) development. See the following commit for explanation, and instructions for how to use NCC and convert cases from AMI. https://github.com/OpenFOAM/OpenFOAM-dev/commit/569fa31d09f98e29d1aaf84d40bb16043f104ec6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
1337	[OpenFOAM] Bug	minor	sometimes	2014-07-07 08:50	2022-05-18 11:09
Reporter:	user851	Platform:	Linux
Assigned To:	will	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	interDyMFoam performance of parallel solving depends on position of pressure reference point in enclosed space
Description:	One Japanese user reported that the performance of interDyMFoam parallel solving depends on position of pressure reference point in enclosed space. I attached report and case. He needs comment about reason of it. If it is like bug, he hopes to fix. OpenFOAM-2.3.x-ddafa9836ad9 OS:Linux Mint13 （Ubuntu 12.04）
Tags:	AMI
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	BugReport20140707.zip (685,044 bytes) 2014-07-07 08:50 https://bugs.openfoam.org/file_download.php?file_id=769&type=bug withoutAMI.zip (286,754 bytes) 2014-07-09 06:32 https://bugs.openfoam.org/file_download.php?file_id=770&type=bug

Notes
(0003151) henry    2014-07-07 09:42	The test-case is using AMI, do you find the same behaviour for moving-mesh cases without AMI?
(0003154) user851    2014-07-08 03:02	No, he doesn't have experience without AMI.
(0003155) henry    2014-07-08 07:32	No problem, we will wait for results without AMI before investigating further.
(0003157) user851    2014-07-09 06:32	He tested it without AMI. the result shows there is no problem. So,Do you think AMI seems to have issues ?
(0003158) henry    2014-07-09 07:39	Yes the AMI has boundedness and conservation issues which are particularly serious for VoF.
(0012589) will    2022-05-18 11:09	Numerical issues with AMI-based patch couplings have been resolved by the new Non-Conformal Coupled (NCC) development. See the following commit for explanation, and instructions for how to use NCC and convert cases from AMI. https://github.com/OpenFOAM/OpenFOAM-dev/commit/569fa31d09f98e29d1aaf84d40bb16043f104ec6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
887	[OpenFOAM] Bug	major	always	2013-06-13 09:28	2022-05-18 11:09
Reporter:	user677	Platform:
Assigned To:	will	OS:
Priority:	urgent	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Conservativity Problem of AMI-Interpolation
Description:	Testcase evaluation has shown conservativity issues for AMI-Interfaces. Interfaces are conservative with respect to their neighbour but loose mass compared to inlet/outlet. Our suspicion is that the matrix-update in the fvPatchField / GAMGInterfaceField does not fullfil conservativity. Computation of fluxes with the interpolation may be globally conservative but using averaged fluxes together with weights seams to lead to conservativity failure. We think it would be better to use local variables together with the weights to compute the fluxes there instead of using the already averaged fluxes.
Tags:	AMI
Steps To Reproduce:	If you need a testcase please send me an email where i can put it. It exceeds the 2MB limit.
Additional Information:
Attached Files:	WP_000743.jpg (1,101,284 bytes) 2013-06-13 09:28 https://bugs.openfoam.org/file_download.php?file_id=520&type=bug

Notes
(0012588) will    2022-05-18 11:09	Numerical issues with AMI-based patch couplings have been resolved by the new Non-Conformal Coupled (NCC) development. See the following commit for explanation, and instructions for how to use NCC and convert cases from AMI. https://github.com/OpenFOAM/OpenFOAM-dev/commit/569fa31d09f98e29d1aaf84d40bb16043f104ec6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
883	[OpenFOAM] Bug	major	always	2013-06-10 15:13	2022-05-18 11:08
Reporter:	olle	Platform:	x86
Assigned To:	will	OS:	Red Hat Enterprise Linux 5.9 x86
Priority:	urgent	OS Version:	5.9
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Loosing mass when using cyclicAMI together with interDyMFoam
Description:	I have combined the mixerVesselAMI2D and sloshingTank2D tutorials so that the outer region is rotating and the inner region is standing still. Gravity is in negative y-dir. Inital state is that the domain is filled with alpha1=1 up to y=0.04. After 4 seconds (simulation time) about 30% of alpha1 has been lost. See attached case (can be runned using the Allrun script).
Tags:	AMI
Steps To Reproduce:	Run attached case with Allrun script and monitor the evolution of "phase1 volume fraction" in the output.
Additional Information:
System Description
Attached Files:	mixerVesselAMIInterDyM.tar.gz (7,302 bytes) 2013-06-10 15:13 https://bugs.openfoam.org/file_download.php?file_id=518&type=bug Screenshot-Gnuplot.png (9,393 bytes) 2013-06-11 15:48 https://bugs.openfoam.org/file_download.php?file_id=519&type=bug

Notes
(0012587) will    2022-05-18 11:08	Numerical issues with AMI-based patch couplings have been resolved by the new Non-Conformal Coupled (NCC) development. See the following commit for explanation, and instructions for how to use NCC and convert cases from AMI. https://github.com/OpenFOAM/OpenFOAM-dev/commit/569fa31d09f98e29d1aaf84d40bb16043f104ec6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
663	[OpenFOAM] Bug	major	always	2012-10-15 09:23	2022-05-18 11:08
Reporter:	user525	Platform:	Linux
Assigned To:	will	OS:	Ubuntu
Priority:	urgent	OS Version:	12.04.01 64 bit
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	AMI corrupts passive scalar
Description:	The passive scalar are NOT correctly calculated when using AMI. Using a simple tutorial case (mixerVesselAMI2D) with fixedvalue uniform T (as example), immediately are shown cells with higher and lower temperature close to one wing (interesting, not all wings....) .   Starting form a uniform field, the problem seems related to a Phi divergence that is not null in those cells, increasing or decreasing the total T (passive scalar) in those cells. The non 0 divergence, may cause of course other issues not yet discovered...
Tags:	AMI
Steps To Reproduce:	using tutorial example mixerVesselAMI2D, add passive scalar (e.g Temperature) as described for icoFoam in http://openfoamwiki.net/index.php/How_to_add_temperature_to_icoFoam , acting on mixerVesselAMI2D tutorial. The same result can be obtained for any passive scalar. Modify transportProperties my_icoFoam.C and createField.H fvSchemes and fvSolution In "0" directory, set the boundaryField for stator and rotor in new the T file with fixed uniform temperature, so that *no changes should occur* in temperature when mixer rotating {         type fixedValue;         value uniform 100;     } Run the solver. Open paraFoam, and discover that exist cluster of cells that shows higher themperature and cluster of cells that show lower temp. than 100°C. See image.
Additional Information:
System Description
Attached Files:	Schermata del 2012-10-15 09:59:26.png (118,105 bytes) 2012-10-15 09:23 https://bugs.openfoam.org/file_download.php?file_id=387&type=bug

Notes
(0001730) user525    2012-10-15 17:55	The cells concerned with the problem, are the ones close/around to pRefCell. Changing the pRefCell Value, makes the problem appear around that new pRefCell. PIMPLE { ....     pRefCell 0;     pRefValue 100; }
(0001731) user525    2012-10-15 18:05	Commenting out the divergence operator in the passive scalar solver, makes error disappear. Things seems to show that the problem is concerned with divergence error caused in the very first cell calculated.         fvScalarMatrix TEqn         (             fvm::ddt(T)             //+ fvm::div(phi, T) < commented out ============             - fvm::laplacian(DT, T)         );         TEqn.solve();         T.correctBoundaryConditions();
(0001732) user525    2012-10-15 21:45	More info... Before passive scalar solver, dumped out divergence values; It shows clearly the FIRST Cells have a very HUGE DIVERGENCE, very different from the other cells dump and code follow: -------------------------------------------------- time step continuity errors : sum local = 8.08573e-09, global = -1.18856e-09, cumulative = -1.18467e-09 GAMG: Solving for p, Initial residual = 0.0747711, Final residual = 0.000343049, No Iterations 6 GAMG: Solving for p, Initial residual = 0.000336345, Final residual = 1.99852e-06, No Iterations 6 GAMG: Solving for p, Initial residual = 1.9989e-06, Final residual = 5.45285e-07, No Iterations 2 time step continuity errors : sum local = 3.22009e-09, global = -2.85251e-10, cumulative = -1.46992e-09 Divergence: 3072 ( -0.00377731 <============ here 6.81498e-05 -0.000131197 <============ here 1.04748e-05 -8.13186e-05 9.22288e-06 -2.76134e-05 ..... ..... ----------------------------------------------------------------                 turbulence->correct();             }         } Info << "Divergence:" << endl; Info << scalarField(fvc::div(phi)) << endl;         fvScalarMatrix TEqn         (             fvm::ddt(T)             + fvm::div(phi, T)             - fvm::laplacian(DT, T)         ); --------------------------------------------------
(0001736) user525    2012-10-16 21:30	Tutorial case + passive scalar tested also on OF 2.1.x But with the same result: ----------------------------------------------------------------------- time step continuity errors : sum local = 8.08573e-09, global = -1.18856e-09, cumulative = -1.18467e-09 GAMG: Solving for p, Initial residual = 0.0747711, Final residual = 0.000343049, No Iterations 6 GAMG: Solving for p, Initial residual = 0.000336345, Final residual = 1.99852e-06, No Iterations 6 GAMG: Solving for p, Initial residual = 1.9989e-06, Final residual = 5.45285e-07, No Iterations 2 time step continuity errors : sum local = 3.22009e-09, global = -2.85251e-10, cumulative = -1.46992e-09 Divergence with OpenFoam 2.1.x: 3072 ( -0.00377731 6.81498e-05 -0.000131197 1.04748e-05 -8.13186e-05
(0001783) user270    2012-11-20 13:48	I was experiencing similar issues to the ones described here. After reproducing mentioned test case, I run into similar results. Running the test case on 64bit Ubuntu 10.04, OF-2.1.1
(0012586) will    2022-05-18 11:08	Numerical issues with AMI-based patch couplings have been resolved by the new Non-Conformal Coupled (NCC) development. See the following commit for explanation, and instructions for how to use NCC and convert cases from AMI. https://github.com/OpenFOAM/OpenFOAM-dev/commit/569fa31d09f98e29d1aaf84d40bb16043f104ec6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3838	[OpenFOAM] Bug	major	always	2022-05-14 10:44	2022-05-14 13:02
Reporter:	peksa	Platform:	Unix
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:	kivaTest tutorial fails due to missing V0
Description:	Hi, Running XiFoam kivaTest tutorial with one of the latest dev commits (13.05.2022 16c0c68e9262547ce9d37ecb3908be1ad41ef748) results in error as follows: --> FOAM FATAL ERROR: V0 is not available     From function const Internal& Foam::fvMesh::V0() const     in file fvMesh/fvMeshGeometry.C at line 220.
Tags:
Steps To Reproduce:	cd OpenFOAM-dev/tutorials/combustion/XiFoam/RAS/kivaTest ./Allrun
Additional Information:
System Description
Attached Files:

Notes
(0012580) henry    2022-05-14 13:02	Resolved by commit 7dd5c4d3fac0704492a5b81f3315abe7d3443a6f

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3833	[OpenFOAM] Bug	minor	always	2022-05-02 11:31	2022-05-05 11:39
Reporter:	michael.mueller-wrd	Platform:	GNU/Linux
Assigned To:	will	OS:	centOS
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:	decomposition of fields very slow
Description:	With recent dev version (as of 2022/04/11) the case decomposition has become drastically slower compared to previous versions. Apparently, the fields decomposition takes a lot more time than before... for some applications (with mesh size < 100M cells) this may actually take several hours up to 1 day with dev version. What may be the reason for that? Is using -copyZero option already the solution/workaround for this issue?
Tags:
Steps To Reproduce:	Tried to reproduce it with shellAndTubeHeatExchanger tutorial, and increased blockMesh refinement by factor 2. 1. $> ./Allmesh.layers (yields ca 5M cells) 2. $> reconstructParMesh -allRegions -constant 3. $> rm processor.* 4. $> time decomposePar -allRegions -noFields 5. $> time decomposePar -allRegions -fields Timings show: real time for v9: -noFields option = 19.8s / -fields option = 3.9s real time for dev: -noFields option = 20.9s / -fields option = 12.2s
Additional Information:
System Description
Attached Files:

Notes
(0012567) henry    2022-05-02 12:56	Can you trace which commit in OpenFOAM-dev has caused this problem?
(0012568) michael.mueller-wrd    2022-05-02 13:16	Did not try to trace it yet... but I may at least state that for a former dev version (as of 2021/12/14), it was working as expected.
(0012569) michael.mueller-wrd    2022-05-02 14:16	For dev version download as of 2022/02/18, it was working just fine as well (sth. like 4s real time for the given example).
(0012573) will    2022-05-03 12:31	The difference between version 9 and dev is that the flowRateInletVelocity is now using a profile, which requires the calculation of a patch wall distance. This is being done within decomposePar in order to generate values on the field. This is unavoidable. If you want equivalent behaviour to version 9, then you need to remove the profile from the velocity inlet boundary conditions. If I do this then decomposePar takes a similar amount of time to version 9. There is something we can fix here, though. I have changed the mapping constructor of flowRateInletVelocity so that the wall distance is mapped from the complete to the processor meshes, instead of being re-calculated. This cheapens it up field decomposition a bit (down from approx 9 s to 6 s on my machine). It is also more correct. You can't do the wall distance calculation properly on the processor meshes, because the relevant walls might be on another processor. Commit here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/38262243ccdd13bd936541d2373ccfd1974db597
(0012574) will    2022-05-05 11:39	Note that following discussion on the OpenFOAM hub, another bug which was negatively affecting the speed of decomposition was discovered and subsequently fixed. Commit in question: https://github.com/OpenFOAM/OpenFOAM-dev/commit/fc74899204654184a79e2dc9437c2f7518cf0ea3

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3831	[OpenFOAM] Patch	trivial	always	2022-04-29 10:38	2022-04-29 12:30
Reporter:	lorenzotrevisan	Platform:	x86_64
Assigned To:	henry	OS:	Slackware
Priority:	low	OS Version:	15.0
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	fix header typos
Description:	The data file header object keyword entry in files: OpenFOAM-dev/etc/templates/singleFluidCHT/constant/initialConditions and OpenFOAM-dev/tutorials/heatTransfer/chtMultiRegionFoam/coolingSphere/constant/initialConditions are set to controlDict, but should be initialConditions.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012566) henry    2022-04-29 12:30	Resolved by commit 58444464aac38171e04d29ee33f7601de3c2f660

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3830	[OpenFOAM] Bug	minor	N/A	2022-04-26 22:34	2022-04-27 10:31
Reporter:	joaquin	Platform:	GNU/Linux
Assigned To:	henry	OS:	Other
Priority:	low	OS Version:	(please specify)
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Inconsistent default constant in kEpsilon model
Description:	The default constant 'C3' in the kEpsilon model is informed to be -0.33 in the .H file, but it's actually 0 in the .C file.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012565) henry    2022-04-27 10:31	Resolved by 4aab8572a4c71d6b0ed883786d2e82c1f85806c0

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3828	[OpenFOAM] Bug	minor	always	2022-04-21 13:26	2022-04-21 15:20
Reporter:	kimmo	Platform:	GNU/Linux
Assigned To:	will	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	volFieldValue-function object with 'min' operation doesn't work for scalar fields as expected
Description:	In OF version 9 the fieldMinMax- function object was replaced by volFieldValue -function object. If the volFieldValue -function object is used for scalar fields (e.g. 'p') the 'min' operation doesn't output any negative values. The behavior is different from version 8 where volFieldValue -function object with 'min'-operation gives the correct negative value if there are negative values present in the scalar field.
Tags:
Steps To Reproduce:	Add the following function objects to the motorBike-tutorial and run it:     min_pressure     {         type volFieldValue;         libs ("libfieldFunctionObjects.so");         log true;         writeFields false;         regionType all;         operation min;         fields (p);     }     average_pressure     {         type volFieldValue;         libs ("libfieldFunctionObjects.so");         log true;         writeFields false;         regionType all;         operation volAverage;         fields (p);     } The min_pressure doesn't output negative values but the average_pressure is negative. There is obviously negative values in the 'p'-field. If you run the tutorial with OF version 8 with the same function objects the output is correct.
Additional Information:	This behavior was observed at least in Ubuntu 20.04 and 18.04.
System Description
Attached Files:

Notes
(0012555) will    2022-04-21 15:20	Thanks for the report. Fixed in both version 9 and in dev. https://github.com/OpenFOAM/OpenFOAM-9/commit/d71c4d2a3b0b3401f165d88e098a85a7a1686e6e https://github.com/OpenFOAM/OpenFOAM-dev/commit/18cd22fe5d5a9f4a7238842da0ad064f9ca54844

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3825	[OpenFOAM] Bug	major	always	2022-04-11 15:52	2022-04-11 16:10
Reporter:	NicolasDelaisse	Platform:	GNU/Linux
Assigned To:	henry	OS:	CentOS
Priority:	normal	OS Version:	7
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	In cavitatingFoam correction of Uf is done with relative phi instead of absolute phi
Description:	In the solver cavitatingFoam.C, in case of a dynamic mesh, Uf is corrected In pEqn.H, on line 83 with the flux phi, which has been made relative on line 19, see the code below: ---------------------------------------------------- phi = fvc::flux(HbyA) + rhorAUf*fvc::ddtCorr(U, phi, Uf); fvc::makeRelative(phi, U); .... // Correct Uf if the mesh is moving fvc::correctUf(Uf, U, phi); ----------------------------------------------------- Based on the implementation of fvc::correctUf in fvcMeshPhi.C (see below), I believe the absolute flux phi should be used. This is also supported by the use of the function in other solvers. ----------------------------------------------------  void Foam::fvc::correctUf  (      autoPtr<surfaceVectorField>& Uf,      const volVectorField& U,      const surfaceScalarField& phi  )  {      const fvMesh& mesh = U.mesh();        if (mesh.dynamic())      {          Uf() = fvc::interpolate(U);          surfaceVectorField n(mesh.Sf()/mesh.magSf());          Uf() += n*(phi/mesh.magSf() - (n & Uf()));      }  }  ---------------------------------------------------- If this is not a bug, I would appreciate a comment on why the relative flux is used and why this is different from other solvers. Otherwise, a possible fix is proposed below:  ---------------------------------------------------- // Correct Uf if the mesh is moving fvc::correctUf(Uf, U, fvc::absolute(phi, U));  ---------------------------------------------------- Thanks in advance
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012544) henry    2022-04-11 16:10	Resolved by commit 48e2ff1fecc05b19fa3f421b2bbec6b2be3f735d

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3666	[OpenFOAM] Patch	trivial	always	2021-04-26 16:20	2022-04-06 16:35
Reporter:	lorenzotrevisan	Platform:	x86_64
Assigned To:	henry	OS:	Slackware
Priority:	low	OS Version:	14.2
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Some small fixies for coolingSphere turorial
Description:	In tutorials/heatTransfer/chtMultiRegionFoam/coolingSphere/constant/: - transportProperties should not be needed due to the considered solver does include energy/heat; - momentumTransport should not be needed because turbulence model is defined in tutorials/heatTransfer/chtMultiRegionFoam/coolingSphere/templates/materials/ for each fluid. In tutorials/heatTransfer/chtMultiRegionFoam/coolingSphere/templates/materials/water/thermophysicalProperties Prandtl number is set to 0.7 [-], but typical value for liquid water is about 7 [-].
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012536) lorenzotrevisan    2022-04-06 09:51	re-reading the description written a year ago, I realize that it doesn't make much sense as I wrote it. As it is not editable, I rephrase the remark: In tutorials/heatTransfer/chtMultiRegionFoam/coolingSphere/constant/ the files transportProperties and momentumTransport are superfluous, because already specified in the templates for all the materials. I noted that in the actual OpenFOAM-dev sources these files have already been deleted, and Prandtl number for water in templates/materials/water/physicalProperties is correct with a value of 7 [-]. So I am sorry for the bad formulation of the issue due to my poor skill (I'm still learning ;-), and ask to close the issue because already resolved. I take this opportunity to thank you for this really useful tutorial.
(0012537) henry    2022-04-06 16:35	Resolved in OpenFOAM-dev by commit 4b65112182e439d2ef51f79992b63f57f4d155b9

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3821	[OpenFOAM] Bug	crash	always	2022-04-03 11:34	2022-04-04 11:33
Reporter:	Yuusha	Platform:	GNU/Linux
Assigned To:	henry	OS:	Mageia
Priority:	normal	OS Version:	8
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Compilation error with polyTopoChange/polyTopoChange/polyTopoChange.C
Description:	Compiling OpenFOAM-dev on Mageia 8 gives the error attached when trying to compile polyTopoChange/polyTopoChange/polyTopoChange.C. g++ --version : g++ (Mageia 10.3.0-2.mga8) 10.3.0 WM_LABEL=SIZE = 64 I tried on several computers with Mageia 8 and in super-user (installation in /opt) and normal user (installation in $HOME) and the error is always the same. Same computers have a functional installation of OpenFOAM-7 without any error.
Tags:
Steps To Reproduce:	1. source $HOME/OpenFOAM/OpenFOAM-dev/etc/bashrc WM_LABEL_SIZE=64 FOAMY_HEX_MESH=yes 2. ./Allwmake -j 4 3. See compilation error
Additional Information:
System Description
Attached Files:	log.make (9,862 bytes) 2022-04-03 11:34 https://bugs.openfoam.org/file_download.php?file_id=3301&type=bug

Notes
(0012534) henry    2022-04-04 11:33	Resolved by commit 4fe853fa8743a33e1b840fbebadc625661d19ddc

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3818	[OpenFOAM] Bug	trivial	always	2022-03-22 21:12	2022-03-22 21:32
Reporter:	Tiberias_	Platform:	GNU/Linux
Assigned To:	henry	OS:	Ubuntu
Priority:	low	OS Version:	20.04
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	-doc option leads to dead URL
Description:	pimpleFoam -doc leads to http://cpp.openfoam.org/9/pimpleFoam_8C.html which routes to 404. Adding "v" before version number leads to the correct page according to previous versions (http://cpp.openfoam.org/v8/pimpleFoam_8C.html) Same behaviour with -srcDoc option
Tags:
Steps To Reproduce:	Try -doc option with random application in version 9.
Additional Information:
System Description
Attached Files:

Notes
(0012532) henry    2022-03-22 21:32	Resolved by commit 348f1ffc02b37625f3613d595d587f846aabf945

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3814	[OpenFOAM] Feature	minor	always	2022-03-07 11:24	2022-03-10 09:26
Reporter:	petteri	Platform:	GNU/Linux
Assigned To:	henry	OS:	Ubuntu
Priority:	normal	OS Version:	14.04
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Zoltan configuration inconsistency
Description:	The file etc/config.sh/zoltan allows for setting the variable ZOLTAN_ARCH_DIR which allone is not sufficient to configure zoltan when a system installation for zoltan is used. The reason for this is that the zoltan library binary is assumed (by files $FOAM_SRC/renumber/Allwmake and $FOAM_SRC/renumber/zoltanRenumber/Make/options) to be located in path: $FOAM_EXT_LIBBIN/$FOAM_MPI/libzoltan.a The aforementioned is inconsistent with the metis and scotch dependencies. Scotch and metis binaries and headers are assumed to be found from $?_ARCH_PATH/lib and $?_ARCH_PATH/include, respectively, which allows for a system installation of those libraries without modifying $FOAM_SRC and only setting the ARCH_PATH correctly. Would it be possible to change the zoltan binaries to be used from $ZOLTAN_ARCH_PATH/lib in $FOAM_SRC? Or better yet, allow the user to configure ZOLTAN_LIB_PATH and ZOLTAN_INCLUDE_PATH separately for allowing even more flexibility?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012509) henry    2022-03-07 11:39	I have not attempted to use a system installation for zoltan and don't have one available on my machine. Given that it is a small library try compiling the latest sources is the ThirdParty-dev directory, the download link is in the README. If you have to use the system installation I am not sure if it is in the same place on all machines and have no idea what the paths should be set to in general. But if you can provide a patch to allow users to set the variables however they want and test it on your machine I can include it provided it does not break the current method.
(0012510) henry    2022-03-07 12:50	Note it is likely that we will replace Zoltan with an alternative library in the future due to the very limited support for weighted redistribution. Also the native Zoltan renumbering method is rather simplistic and not as good as the Cuthill-McKee method supplied in OpenFOAM. If you can arrange for a parMeTiS licence that might be a better option if you need weighted balance for chemistry.
(0012511) petteri    2022-03-07 13:27	Here's a patch that works on our end and allows us to use system compiled zoltan: https://diffy.org/diff/e2185b09b5338 Note that in the patch only the OpenFOAM side environment is modified. The patch should allow for the old way of running the ThirdParty-dev/Allwmake but I did not test it. Also, it would be safer to change all occurences of '$FOAM_EXT_LIBBIN/$FOAM_MPI' to $ZOLTAN_LIB_PATH also in ThirdParty-dev/Allwmake to ensure that the paths stay up to date. The reason we want to use system compiled libraries as much as possible is that we have better control of dependencies on a cluster which has different architectures. We have had strange crashes with mpi if mixed openmpi/scotch/zoltan combinations have been used when certain (older) nodes are involved. We need to be able to compile (and configure) all libraries separately and ensure that they function properly. Since we use many different versions of OpenFOAM, handling all the paths in ThirdParty-directories gets messy and is error prone and those errors typically occur during runtime.
(0012512) henry    2022-03-07 13:34	> Also, it would be safer to change all occurences of '$FOAM_EXT_LIBBIN/$FOAM_MPI' to $ZOLTAN_LIB_PATH also in ThirdParty-dev/Allwmake to ensure that the paths stay up to date. This is not clear, could you please make all the changes you need and test to make sure it doesn't break the current operation? It might be better to wait until after Zoltan is replaced to avoid this maintenance overhead.
(0012513) petteri    2022-03-07 14:50	Here's a patch for the ThirdParty-dev/Allwmake: https://diffy.org/diff/aafcd0c24c9bb I tested that after rebuilding the latest dev tutorials combustion/reactingFoam/counterFlowFlame2D_GRI and interFoam/RAS/floatingObject run correctly.
(0012514) henry    2022-03-07 16:42	I don't see how your changes make the handling of Zoltan consistent with Scotch or Metis, you have added export ZOLTAN_INCLUDE_PATH=$ZOLTAN_ARCH_PATH/include export ZOLTAN_LIB_PATH=$FOAM_EXT_LIBBIN/$FOAM_MPI but there is no equivalent for Scotch or Metis. Have you also added SCOTCH_INCLUDE_PATH etc.?
(0012515) henry    2022-03-07 16:55	The changes you have made are not correct, $FOAM_EXT_LIBBIN/$FOAM_MPI/libzoltan.a is the correct path for Zoltan which is build against a particular version of MPI. ptScotch is handled in the same manner, see src/parallel/decompose/ptscotchDecomp/Make/options LIB_LIBS = \     -L$(SCOTCH_ARCH_PATH)/lib \     -L$(FOAM_EXT_LIBBIN)/$(FOAM_MPI) \     -lptscotch \     -lptscotcherrexit \     -lscotch \     -lrt where -L$(FOAM_EXT_LIBBIN)/$(FOAM_MPI) is used to add the path for the -lptscotch -lptscotcherrexit libraries.
(0012516) henry    2022-03-07 16:58	It would be possible to add a -L$(ZOLTAN_ARCH_PATH)/lib entry which you could use but it is not possible to remove the -L$(FOAM_EXT_LIBBIN)/$(FOAM_MPI) as this is required by the OpenFOAM installation.
(0012517) henry    2022-03-07 17:17	This should do what you want without breaking current functionality: commit 18f4f2f9e724edae4ca1d4711eb6fc37f57035f9 (HEAD -> master, origin/master, origin/HEAD) Author: Henry Weller <http://cfd.direct> Date: Mon Mar 7 17:14:34 2022 +0000     Zoltan: Added alternative library location $ZOLTAN_ARCH_PATH/lib          to support linking to system installations of the Zoltan library.          Resolves the feature request https://bugs.openfoam.org/view.php?id=3814
(0012518) petteri    2022-03-08 07:10	Thanks for the update, I think we will manage from now on. Few notes: > The changes you have made are not correct, $FOAM_EXT_LIBBIN/$FOAM_MPI/libzoltan.a is the correct path for Zoltan which is build against a particular version of MPI I'm not sure if its necessary to have "correct paths" for the zoltan build (or any library for that matter) because that only enforces the user to compile third party code in a specified (OpenFOAM-dependent) location. If it is necessary for Zoltan and OpenFOAM to use the same version of mpi, having the library binaries in some named location won't enforce this. The reason why I separated ZOLTAN_INCLUDE_PATH and ZOLTAN_LIBRARY_PATH is because those are the only things required by FOAM_SRC. However, you are correct that separating the two is still incosistent with scotch and metis. Having the first part of $ZOLTAN_ARCH_PATH/lib is good and allows for ZOLTAN_ARCH_PATH to point somewhere completely independent of OpenFOAM. However, I'm not sure what is the benefit of having the 'lib' there. User may equally well want to store the binaries in some system/lib64, system/WHATEVER. But like I said this works for us. Thanks again for the quick patch!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3815	[OpenFOAM] Feature	major	always	2022-03-08 13:34	2022-03-09 11:14
Reporter:	kasperbilde	Platform:	GNU/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:	fluent3DMeshToFoam not able to read mesh from R2021
Description:	Hi, I've previously used fluent3DMeshToFoam to convert Fluent meshes to Foam and I recently upgraded to Fluent R2021 R2. I created a mesh and got the following error due to square brackets in the .msh ASCII file. /*---------------------------------------------------------------------------*\   ========= |   \\ / F ield | OpenFOAM: The Open Source CFD Toolbox    \\ / O peration | Website: https://openfoam.org     \\ / A nd | Version: dev      \\/ M anipulation | \*---------------------------------------------------------------------------*/ Build : dev-69858a80ec41 Exec : fluent3DMeshToFoam fluent3DmeshToFoam_bug.msh Date : Mar 08 2022 Time : 14:31:14 Host : "DKAALT0912" PID : 7777 I/O : uncollated Case : /mnt/c/Users/dkaakbea/OpenFOAM/flocculatorDesign/basecase 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 Reading header: "ANSYS(R) TGLib(TM) 3D, revision 18.1.0" Reading header: "ANSYS(R) TGLib(TM) 3D, revision 18.1.0" Dimension of grid: 3 Number of points: 8263 Number of faces: 12816 Number of cells: 2617 PointGroup: 64 start: 1274 end: 8262. Reading points...done. PointGroup: 136 start: 0 end: 1273. Reading points...done. FaceGroup: 62 start: 763 end: 12815. Reading mixed faces...done. FaceGroup: 13 start: 0 end: 179. Reading mixed faces...done. FaceGroup: 14 start: 180 end: 359. Reading mixed faces...done. FaceGroup: 12 start: 360 end: 762. Reading mixed faces...done. CellGroup: 60 start: 0 end: 2616 type: 1 Zone: 60 name: solid type: fluid. Reading zone data...done. Zone: 12 name: walls type: wall. Reading zone data...done. Zone: 14 name: outlet type: pressure-outlet. Reading zone data...done. Zone: 13 name: inlet type: velocity-inlet. Reading zone data...done. Zone: 62 name: interior--solid type: interior. Reading zone data...done. --> FOAM FATAL ERROR: Do not understand characters: [     on line 21154     From function virtual int yyFlexLexer::yylex()     in file fluent3DMeshToFoam.L at line 749. FOAM exiting Not sure whether this was introduced in an earlier version of Fluent, but I can confirm it was working well with Fluent 2019 R3. When removing the square brackets from the ASCII file, fluent3DMeshToFoam functions again. sed -e 's/\|\[0-9\]//g' -i fluent3DmeshToFoam_bug.msh fluent3DMeshToFoam -scale 0.001 fluent3DmeshToFoam_bug.msh
Tags:
Steps To Reproduce:	Reproduce error: 1. Insert fluent3DmeshToFoam_bug.msh in a case. 2. fluent3DMeshToFoam fluent3DmeshToFoam_bug.msh Fix by removing square brackets from ASCII .msh file. 1. sed -e 's/\|\[0-9\]//g' -i fluent3DmeshToFoam_bug.msh 2. fluent3DMeshToFoam fluent3DmeshToFoam_bug.msh
Additional Information:
Attached Files:	fluent3DmeshToFoam_bug.msh (911,619 bytes) 2022-03-08 13:34 https://bugs.openfoam.org/file_download.php?file_id=3294&type=bug fluent3DmeshToFoam_bug-2.msh (911,624 bytes) 2022-03-08 18:32 https://bugs.openfoam.org/file_download.php?file_id=3295&type=bug fluent3DMeshToFoam.L (43,055 bytes) 2022-03-08 21:32 https://bugs.openfoam.org/file_download.php?file_id=3296&type=bug

Notes
(0012520) henry    2022-03-08 13:49    (Last edited: 2022-03-08 13:59)	We have no access to Fluent and so no way to maintain the converter. Can you supply a patch which ensures the converter works with the current AND previous Fluent releases? I tested the .msh file you attached but it converted fine and does not contain any square brackets.
(0012521) kasperbilde    2022-03-08 14:24	I'll look into it. It might take a while, as I haven't got so much time at the moment. I don't know if you can put it "on hold" or something. If anyone else encounters this from Google search, they can simply remove the brackets from the .msh-file until a patch is made.
(0012522) henry    2022-03-08 14:38	I couldn't find any square brackets in the .msh file you sent and it converts fine.
(0012523) henry    2022-03-08 14:47	Here is the log I get when I convert the file attached here: Create time Reading header: "ANSYS(R) TGLib(TM) 3D, revision 18.1.0" Reading header: "ANSYS(R) TGLib(TM) 3D, revision 18.1.0" Dimension of grid: 3 Number of points: 8263 Number of faces: 12816 Number of cells: 2617 PointGroup: 64 start: 1274 end: 8262. Reading points...done. PointGroup: 136 start: 0 end: 1273. Reading points...done. FaceGroup: 62 start: 763 end: 12815. Reading mixed faces...done. FaceGroup: 13 start: 0 end: 179. Reading mixed faces...done. FaceGroup: 14 start: 180 end: 359. Reading mixed faces...done. FaceGroup: 12 start: 360 end: 762. Reading mixed faces...done. CellGroup: 60 start: 0 end: 2616 type: 1 Zone: 60 name: solid type: fluid. Reading zone data...done. Zone: 12 name: walls type: wall. Reading zone data...done. Zone: 14 name: outlet type: pressure-outlet. Reading zone data...done. Zone: 13 name: inlet type: velocity-inlet. Reading zone data...done. Zone: 62 name: interior--solid type: interior. Reading zone data...done. --> FOAM Warning : Found unknown block of type: "73"     on line 22257 FINISHED LEXING Creating patch 0 for zone: 13 name: inlet type: velocity-inlet Creating patch 1 for zone: 14 name: outlet type: pressure-outlet Creating patch 2 for zone: 12 name: walls type: wall Creating cellZone 0 name: solid type: fluid Creating faceZone 0 name: interior--solid type: interior faceZone from Fluent indices: 763 to: 12815 type: interior patch 0 from Fluent indices: 0 to: 179 type: velocity-inlet patch 1 from Fluent indices: 180 to: 359 type: pressure-outlet patch 2 from Fluent indices: 360 to: 762 type: wall Writing mesh to "constant/region0"
(0012524) kasperbilde    2022-03-08 18:32	I accidentally attached the file where the brackets had already been removed. This is the right one.
(0012525) henry    2022-03-08 21:32	I have played around with the text parsing and the attached version parses your case but I don't have many .msh files to test it on to make sure it is backward compatible. Could you test it before I commit it to OpenFOAM-dev?
(0012526) kasperbilde    2022-03-09 09:45	Ah, that was quick! I have tested the updated mesh converter on .msh files generated by Fluent 2019 R3, Fluent 2020 R1 and Fluent 2021 R2. I, unfortunately, don't have licenses for previous versions. The updated converter works for all meshes tested.
(0012527) henry    2022-03-09 11:14	Resolved by commit 318f78b660ba2aa8dc5f4ed1e7643997f47546e6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3812	[OpenFOAM] Bug	minor	always	2022-03-02 21:50	2022-03-04 18:38
Reporter:	ahess	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:	dev
		Target Version:
Summary:	Refinement history lost after redistribution preventing unrefining.
Description:	Use of a distributor causes a break in the refinement history leading to over refinement of the mesh. Tests using the refiner+distributor to refine a moving interface in interFoam develop patches of refined mesh that do not unrefine even though the criterion specifies they are eligible to and their cell levels are reported correctly. This only occurs when a distributor is used and appears near processor boundaries, possibly implying that the splitCells are not being transferred. This occurs with and without the refinementHistory constraint. When modeling moving interfaces such as droplets with high levels of refinement and frequent redistribution this blocks most unrefinement and causes the mesh size to blow up. I wasn't sure if this was due to the incomplete nature of the feature or an oversight so I am presenting it here.
Tags:
Steps To Reproduce:	Run with a distributor and a refiner that is refining a feature that is non-stationary. I've modified the interFoam/capillaryRise to demonstrate the effects when run in parallel.
Additional Information:
System Description
Attached Files:	capillaryRise.zip (586,159 bytes) 2022-03-02 21:50 https://bugs.openfoam.org/file_download.php?file_id=3292&type=bug capillaryRise_unrefineable_cells.png (122,357 bytes) 2022-03-02 21:50 https://bugs.openfoam.org/file_download.php?file_id=3293&type=bug

Notes
(0012508) henry    2022-03-04 18:38	Resolved by commit 16788ffc368863576a01ef776fd2419cdf532f9f

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3810	[OpenFOAM] Patch	text	sometimes	2022-02-28 12:41	2022-03-01 22:57
Reporter:	wyldckat	Platform:
Assigned To:	chris	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	WSL v2 can change its host IP address once in a while, so we need 'DISPLAY' to be set accordingly each time
Description:	In page https://openfoam.org/download/windows/ - we currently have this command for WSL v2:     echo "export DISPLAY=$(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null):0" >> ${HOME}/.bashrc However, this hard-codes the IP address to the current one. Therefore, we need this to always be set directly from the origin file, each time a new command line is started. The fix is simple, namely we have to escape the 2 dollar signs:     echo "export DISPLAY=\$(awk '/nameserver / {print \$2; exit}' /etc/resolv.conf 2>/dev/null):0" >> ${HOME}/.bashrc
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0012507) chris    2022-03-01 22:57	Thanks Bruno, change applied.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3807	[OpenFOAM] Bug	minor	always	2022-02-17 13:22	2022-02-18 16:36
Reporter:	peksa	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:	userTime conversion and cut-plane sampling issue
Description:	Dear developers, When utilising the userTime conversion in controlDict, the surface sampling fails to write at user-given time intervals. The issue may rise due to usage of mesh based time name in sampledSurfaces.C ?
Tags:
Steps To Reproduce:	- Copy kivaTest tutorial from tutorials/combustion/XiFoam/RAS/kivaTest - add the following cuttingPlane function object to controlDict /* ---------------------------------------------- */     cuttingPlane     {         type surfaces;         libs ("libsampling.so");              writeControl runTime;         //writeInterval 1e-5; // WORKS         writeInterval 1; // DOES NOT WORK              surfaceFormat vtk;              fields ( p U );              interpolationScheme cellPoint;              surfaces         (             zNormal             {                 type cuttingPlane;                 planeType pointAndNormal;                 point (0 0 0);                 normal (0 1 0);                 interpolate true;             }         );     } /* ---------------------------------------------- */ - Run by executing XiFoam - No cutplanes are produced with 1 CAD time intervals - change writeInterval to 1e-5 (relevant physical time) and run again. - Now cut-planes are produced.
Additional Information:
System Description
Attached Files:

Notes
(0012496) henry    2022-02-18 16:36	Resolved by commit 842a6021f7311fb728763fe2ece1cf6ab39c23f7

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3799	[OpenFOAM] Bug	minor	always	2022-02-04 14:24	2022-02-04 15:08
Reporter:	michael.mueller-wrd	Platform:	GNU/Linux
Assigned To:	henry	OS:	centOS
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:	chtMultiRegionFoam crashes with nEcorr > 1 and multiple fluid regions
Description:	CHT simulation crashes when using dev version's new feature of sub-iterating over thermal system in chtMultiRegionFoam solver (nEcorr > 1) and more than one fluid region is included. First time step will start as usual, but crashes when additional sub-iteration will be done for fluid region(s). stderr lists sth like: Foam::sigSegv::sigHandler(int) Foam::multiply(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/lib64/libc.so.6" ... Identical cases without corresponding entry for new feature runs as expected.
Tags:
Steps To Reproduce:	- Test with heatTransfer tutorials "heatExchanger" and/or "shellAndTubeHeatExchanger". - Include line for new feature in system/fvSolution: PIMPLE {     nOuterCorrectors 1;     nEcorr 2; } - Run case
Additional Information:
System Description
Attached Files:

Notes
(0012466) henry    2022-02-04 15:08	Resolved by commit 66600b5497b99bd3762238c4af5448120e173974

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3798	[OpenFOAM] Bug	minor	always	2022-02-03 20:37	2022-02-03 21:10
Reporter:	joegi	Platform:
Assigned To:	henry	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	Inconsistent renaming of patch type after renumberMesh or decomposePar
Description:	When using the following boundary condition, cylinder {         type solidBodyMotionDisplacement;         solidBodyMotionFunction sixDoFMotion;         CofG ( 0 0 0 );         translationRotation table ( ... ); The patch type is automatically renamed to,     cylinder     {         type solidBodyMotionDisplacement;         value uniform (0 0 0);         solidBodyMotionFunction sixDoFMotion;         sixDoFMotionCoeffs         {             type solidBodyMotionDisplacement;             solidBodyMotionFunction sixDoFMotion;             CofG ( 0 0 0 );             translationRotation table ( ... );         }     } } This happens after executing the commands renumberMesh or decomposePar. The renamed patch type gives an error and is not possible to run the simulation. Particularly annoying when trying to run in parallel.
Tags:
Steps To Reproduce:	Just run the the script as follows, sh run_moveDynamicMesh.sh
Additional Information:
Attached Files:	case.tar.gz (7,841 bytes) 2022-02-03 20:37 https://bugs.openfoam.org/file_download.php?file_id=3286&type=bug

Notes
(0012464) joegi    2022-02-03 20:39	I forgot to mention, before running the simulation (modeDynamicMesh or the solver) you need to execute renumberMesh or decomposePar
(0012465) henry    2022-02-03 21:10	Resolved in OpenFOAM-9 by commit f2cabcd7ab8fb26455a8d53295c99bc721f9e01a Resolved in OpenFOAM-dev by commit 68cb2aef555cbb3fd6d2468892c00198923486c9

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3776	[OpenFOAM] Bug	major	always	2022-01-07 14:43	2022-01-28 16:37
Reporter:	rJansen	Platform:	Ubuntu 18.04
Assigned To:	henry	OS:
Priority:	high	OS Version:
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	Negative normal components of UPrime2Mean in tutorial channel395
Description:	When the tutorial incompressible/pimpleFoam/LES/channel395 is ran and the field UPrime2Mean is analyzed, it can be seen that UPrime2Mean.xx gives negative values, whereas this should not be possible. Additionally, the axial profile of UPrime2Mean.xx is very different from the same tutorial in OpenFOAM v8.
Tags:
Steps To Reproduce:	Run the tutorial incompressible/pimpleFoam/LES/channel395
Additional Information:
Attached Files:

Notes
(0012363) henry    2022-01-07 21:18	Resolved in OpenFOAM-9 by commit 4979f347297f7b0bd6eaa15e5710f36e0e08a996 Resolved in OpenFOAM-dev by commit 1ae52882748922f4e02c92ba52301c416954e426

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3794	[OpenFOAM] Contribution	text	N/A	2022-01-26 16:45	2022-01-27 11:45
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:	Corrected "Shells -> Feature edges" in snappyHexMesh lib + a few additional options to annotated snappyHexMeshDict
Description:	Proposed fixes in this contribution:   1. 'triSurfaceMesh' has a few more optional settings that were not yet mentioned elsewhere in the annotated dictionaries, so the already documented entries in "etc/caseDicts/annotated/snappyHexMeshDict" were revised to be consistent with the remaining dictionary file and added a couple more sometimes useful settings that are available, as mentioned in 'triSurfaceMesh's description: https://cpp.openfoam.org/v9/classFoam_1_1triSurfaceMesh.html#details   2. There were several parts of the feature edge code that references to "shells" that were meant to be updated to "features" or "feature edges", likely due to copy-paste-adapt of code from shells to the feature edges. Attached are the following files: - "snappy_comments_and_dict_options_v1.patch" as a reference of the proposed changes. - "snappy_comments_and_dict_options_v1.tar.gz" - this provides the following files which were modified, relative to the recent commit e90293af9f0 in OpenFOAM-dev:     - etc/caseDicts/annotated/snappyHexMeshDict     - src/mesh/snappyHexMesh/meshRefinement/meshRefinementRefine.C     - src/mesh/snappyHexMesh/refinementFeatures/refinementFeatures.C     - src/mesh/snappyHexMesh/refinementFeatures/refinementFeatures.H - also attached these files themselves, just in case it's useful this way.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	snappyHexMeshDict (17,499 bytes) 2022-01-26 16:45 https://bugs.openfoam.org/file_download.php?file_id=3275&type=bug meshRefinementRefine.C (73,224 bytes) 2022-01-26 16:45 https://bugs.openfoam.org/file_download.php?file_id=3276&type=bug refinementFeatures.C (23,352 bytes) 2022-01-26 16:45 https://bugs.openfoam.org/file_download.php?file_id=3277&type=bug refinementFeatures.H (6,284 bytes) 2022-01-26 16:45 https://bugs.openfoam.org/file_download.php?file_id=3278&type=bug snappy_comments_and_dict_options_v1.patch (7,665 bytes) 2022-01-26 16:45 https://bugs.openfoam.org/file_download.php?file_id=3279&type=bug snappy_comments_and_dict_options_v1.tar.gz (23,817 bytes) 2022-01-26 16:45 https://bugs.openfoam.org/file_download.php?file_id=3280&type=bug

Notes
(0012443) henry    2022-01-26 21:38	Is this a functionality change or purely documentation correction?
(0012444) wyldckat    2022-01-27 10:08	It's purely documentation correction/addition. The added documentation to "snappyHexMeshDict" does not solve the issue #3788, I've checked.
(0012445) henry    2022-01-27 10:18	OK, thanks for the clarification, I just wanted to check what testing would need to be done after applying the changes. I will push the changes today.
(0012446) henry    2022-01-27 11:45	Resolved by commits bc32409e6b9cd7bbb478a6c2b9ac2fe5c0ff5fb1 and 4b914573ebba242c8490457f1efc87801168eb12

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3787	[OpenFOAM] Bug	minor	sometimes	2022-01-20 12:13	2022-01-20 15:39
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:	'lnInclude' for 'solidSpecie' is not updated automatically
Description:	This is a somewhat rare issue, given that it's rare to have folders without a 'Make' folder that are common to several other libraries and need the 'lnInclude' folder. In the folder 'src/thermophysicalModels', if we update the symbolic link folders, it does not process the folder 'solidSpecie', e.g.:   src   cd thermophysicalModels   wmakeLnIncludeAll -update   wmakeLnIncludeAll: running wmakeLnInclude       searching . for 'Make' directories   wmakeLnInclude: linking include files to ./basic/lnInclude   wmakeLnInclude: linking include files to ./chemistryModel/lnInclude   wmakeLnInclude: linking include files to ./reactionThermo/lnInclude   wmakeLnInclude: linking include files to ./laminarFlameSpeed/lnInclude   wmakeLnInclude: linking include files to ./thermophysicalProperties/lnInclude   wmakeLnInclude: linking include files to ./barotropicCompressibilityModel/lnInclude   wmakeLnInclude: linking include files to ./solidThermo/lnInclude   wmakeLnInclude: linking include files to ./specie/lnInclude The simplest fix would be to add this line to 'src/thermophysicalModels/Allwmake':    wmakeLnInclude -update solidSpecie before all other 'wmake' calls. Other alternatives I can think of: 1- Either would require to either create a dummy library folder 'Make' with 'LIB=' inside it, at the risk of breaking something else. 2- Upgrading 'wmakeLnIncludeAll' to account for these special kinds of shared folders. 3- Have a new kind of template/header library, e.g. 'Make/files' with just a marker keyword 'INCLIB', mostly just to allow us to have a simple update to 'wmakeLnIncludeAll'.
Tags:
Steps To Reproduce:	Running these commands will reproduce the issue:   src   cd thermophysicalModels   rm solidSpecie/lnInclude/tabulatedSolidTransport*   wclean solidThermo   ./Allwmake -update Results in something like this:   ..../OpenFOAM/OpenFOAM-dev/src/thermophysicalModels/solidSpecie/lnInclude/forSolids.H:44:10: fatal error: tabulatedSolidTransport.H: No such file or directory    #include "tabulatedSolidTransport.H"             ^~~~~~~~~~~~~~~~~~~~~~~~~~~   compilation terminated. This was because 'tabulatedSolidTransport*' files were not added in the first commit, along with when 'solidSpecie' was introduced.
Additional Information:
Attached Files:

Notes
(0012416) henry    2022-01-20 14:15	Try with src cd thermophysicalModels rm solidSpecie/lnInclude/tabulatedSolidTransport* wclean solidThermo wcleanLnIncludeAll ./Allwmake -update We find that Allwmake -update is not entirely reliable and sometimes does not update the lnInclude directories or .dep files correctly and manual intervention is needed.
(0012418) henry    2022-01-20 14:33	> 1- Either would require to either create a dummy library folder 'Make' with 'LIB=' inside it, at the risk of breaking something else. Have you tried this?
(0012419) henry    2022-01-20 15:39	Resolved by commit db45df2e6e7c57d4903bd30f978485edfb537b22

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3786	[OpenFOAM] Bug	minor	always	2022-01-18 07:19	2022-01-18 10:53
Reporter:	cgoessni	Platform:	amd64
Assigned To:	henry	OS:	CentOS
Priority:	normal	OS Version:	7
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	mapFields does not handle userTime correctly
Description:	When I run mapFields with userTime engine, it would not handle the times correctly. 1. It would display the time in seconds instead of CA 2. It would not pick up the latest time from the source directory, but the earliest [clemens@acer: kivaTest.2] $ mapFields -consistent ../kivaTest.1 /*---------------------------------------------------------------------------*\   ========= |   \\ / F ield | OpenFOAM: The Open Source CFD Toolbox    \\ / O peration | Website: https://openfoam.org     \\ / A nd | Version: dev      \\/ M anipulation | \*---------------------------------------------------------------------------*/ Build : dev Exec : mapFields -consistent ../kivaTest.1 Date : Jan 18 2022 Time : 08:14:22 Host : "fvkmb176" PID : 123790 I/O : uncollated Case : /home/clemens/OpenFOAM/goessnitzer-dev/run/kivaTest.2 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 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Source: "/home/clemens/OpenFOAM/goessnitzer-dev/run" "kivaTest.1" Target: "/home/clemens/OpenFOAM/goessnitzer-dev/run" "kivaTest.2" Create databases as time Selecting userTime engine Selecting userTime engine Source time: -0.02 Target time: 0.06 Create meshes Source mesh size: 27544 Target mesh size: 27544 Consistently creating and mapping fields for time -180     interpolating alphat     interpolating nut     interpolating fu     interpolating b     interpolating Su     interpolating p     interpolating T     interpolating k     interpolating epsilon     interpolating Tu     interpolating Xi     interpolating ft     interpolating U End
Tags:
Steps To Reproduce:	1. Create two kivaTest tutorials 1,2 2. copy -180 to 540 in tutorial kivaTest.1 3. move -180 to 540 in tutorial kivaTest.2 4. prepare the mesh for both tutorials 5. run "mapFields -consistent ../kivaTest.1" Expected outcome: 1. display time correctly 2. pick-up latest time of the source directory
Additional Information:
System Description
Attached Files:

Notes
(0012415) henry    2022-01-18 10:53	Resolved by commit ded017b76203e80df16d884e61c6fdbfbaba2531

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3784	[OpenFOAM] Bug	major	always	2022-01-15 08:18	2022-01-16 13:31
Reporter:	cgoessni	Platform:	amd64
Assigned To:	henry	OS:	Debian
Priority:	normal	OS Version:	stable
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	decomposePar does not work with engineTime for negative times
Description:	Whenever a case with userTIme engine is decomposed, it would not work if the start time is negative Time = -0.02CAD ****** Processor 0: field transfer Selecting userTime engine --> FOAM FATAL ERROR: Cannot find file "points" in directory "polyMesh" in times "-180" down to constant     From function virtual Foam::IOobject Foam::fileOperation::findInstance(const Foam::IOobject&, Foam::scalar, const Foam::word&) const     in file global/fileOperations/fileOperation/fileOperation.C at line 865. FOAM exiting The line that I marked with ****** indicates that the time conversion is somehow not down. When the start time is positive, it would decompose the case, but still print the wrong time, e.g. if I change the start time to 540CAD in the kivaTest tutorial, it would still print Time = 0.06CAD but the time name in the processor directory is correct: [clemens@acer: kivaTest] $ ll processor0/ total 8.0K drwxr-xr-x 2 clemens clemens 4.0K Jan 15 09:18 540 drwxr-xr-x 3 clemens clemens 4.0K Jan 15 09:18 constant
Tags:
Steps To Reproduce:	Try to decompose $FOAM_TUTORIALS/combustion/XiFoam/RAS/kivaTest
Additional Information:
System Description
Attached Files:

Notes
(0012412) henry    2022-01-15 21:17	Try commit aab660450aae87b6276dcfa3ae105d32b5de7d7a
(0012413) cgoessni    2022-01-16 13:16	The problem is gone with the above commit. Thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3781	[OpenFOAM] Bug	minor	always	2022-01-13 13:07	2022-01-14 18:09
Reporter:	ivor.clifford	Platform:	GNU/Linux
Assigned To:	henry	OS:	Ubuntu
Priority:	low	OS Version:	15.04
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	Mismatch between user and physical time when adapting the time precision
Description:	I am developing a new solver in which I derive from Foam::Time and override the virtual functions Foam::TimeState::userTimeToTime, etc. While doing this, I noticed that OpenFOAM unexpectedly increases the write precision, which seems to be due to mismatches between user- and physical time in OpenFOAM's time classes. After some debugging, I think I found the issue. In Time.C:1287         // Tolerance used when testing time equivalence         const scalar timeTol =             max(min(pow(10.0, -precision_), 0.1*deltaT_), SMALL); Here the physical time is used to define the tolerance for increasing the time precision, but a few lines down (1302) this is compared against the user time. This mismatch causes the precision to unexpectedly increase. A second issue I noted is that, on line 1292, userDeltaT is determined using the function timeToUserTime. This is only correct if the user time is a linear function of the physical time. It would be better to calculate this as:     const scalar userDeltaT = timeToUserTime(value()) - timeToUserTime(value() - deltaT_);
Tags:
Steps To Reproduce:	This bug is not related to any specific usage of the code.
Additional Information:
System Description
Attached Files:	kivaTest_bug.tar.gz (1,073,276 bytes) 2022-01-13 15:54 https://bugs.openfoam.org/file_download.php?file_id=3258&type=bug

Notes
(0012381) henry    2022-01-13 13:55	I have completely rewritten the handling of user-time in OpenFOAM-dev, I think it would make sense for you to upgrade to OpenFOAM-dev before writing code relating to user-time to avoid having to rewrite it: commit 3ef3e96c3f217baaeaaebb7e4f94593354dff069 Author: Henry Weller <http://cfd.direct> Date: Tue Oct 19 09:09:01 2021 +0100     Time: Added run-time selectable userTime option          replacing the virtual functions overridden in engineTime.          Now the userTime conversion function in Time is specified in system/controlDict     such that the solver as well as all pre- and post-processing tools also operate     correctly with the chosen user-time.          For example the user-time and rpm in the tutorials/combustion/XiEngineFoam/kivaTest case are     now specified in system/controlDict:          userTime     {         type engine;         rpm 1500;     }          The default specification is real-time:          userTime     {         type real;     }          but this entry can be omitted as the real-time class is instantiated     automatically if the userTime entry is not present in system/controlDict.
(0012382) henry    2022-01-13 14:00	I can implement a correction to the code but I need a means to test it, can you provide a case which reproduces the problem?
(0012383) henry    2022-01-13 14:04    (Last edited: 2022-01-13 14:05)	> This is only correct if the user time is a linear function of the physical time. Are you planning to use a user time which is not a linear function of the physical time? The reason I ask is that while the user-time handling in Time does not assume a linear relationship there are a couple of pieces of code relating to user time which currently do and it was not clear if this would ever be an issue.
(0012384) ivor.clifford    2022-01-13 14:21	We will try to migrate to the dev version when convenient, thank you. I think this approach is an improvement. Looking at Time.C in OpenFOAM-dev, however, I think the issue still exists. To provide a test case, I could play with the engine solvers in an attempt to trigger the problem. Would this be sufficient? > Are you planning to use a user time which is not a linear function of the physical time? This is just an idea we are considering. In some cases, we have experimental measurements at arbitrary time intervals that we refer to as burnup steps. For these problems, it would be useful to monitor the evolution in terms of these burnup steps rather than physical time.
(0012385) henry    2022-01-13 15:42    (Last edited: 2022-01-13 15:59)	> Looking at Time.C in OpenFOAM-dev, however, I think the issue still exists. Correct, I wasn't suggesting the issue had been fixed in dev, only that the user-time mechanism is completely different and better. > To provide a test case, I could play with the engine solvers in an attempt to trigger the problem. Would this be sufficient? Yes Presumably             // User-time equivalent of deltaT             const scalar userDeltaT =                 timeToUserTime(value()) - timeToUserTime(value() - deltaT_);             // Tolerance used when testing time equivalence             const scalar timeTol =                 max(min(pow(10.0, -precision_), 0.1*userDeltaT), small); is sufficient to fix the problem? My feeling is a non-linear user-time to time relationship is not sensible and I did consider in the re-write in OpenFOAM-dev to fundamentally limit the conversion to being linear but I couldn't be sure that a non-linear relationship wouldn't be needed for some purpose. If this is needed then other parts of the code will need to be updated to support it.
(0012386) ivor.clifford    2022-01-13 15:54	Dear Henry, I have prepared a case to trigger the problem. This is simply a modified version of kivaTest where the engine speed is reduced to 1e-3 rpm. The large ratio of real deltaT to angular deltaTheta triggers the problem. If we run this case using XiEngineFoam, the time precision increases by 3 at each writeTime leading to a final time precision at the end of the simulation of 18, i.e. machine precision. > Presumably ... is sufficient to fix the problem? Your proposed fix would likely work, yes. > My feeling is a non-linear user-time to time relationship is not sensible There's no pressure from my side to support non-linear relationships. It's almost better to know upfront that we should not pursue this. Kind Regards Ivor
(0012387) henry    2022-01-13 16:02	Actually             // User-time equivalent of deltaT             const scalar userDeltaT =                 timeToUserTime(value()) - timeToUserTime(value() - deltaT_); is even needed to handle linear time conversion if there is an offset in the user-time to time conversion which is supported.
(0012410) henry    2022-01-14 16:30	I have isolated the issue and am testing a fix in OpenFOAM-9 and if all is well will make the corresponding change to OpenFOAM-dev.
(0012411) henry    2022-01-14 18:09	Resolved in OpenFOAM-9 by commit 6afbfbe27a63ce9c89d64788837d58338b932681 and eca6d201d3db996a06a8c3c30ea7e6aed36c2eec Resolved in OpenFOAM-dev by commit fca30da1fd8d8035e866c9d3023f7f5a2afb9647 and 76d8280c9642dc0b73c3abe4083070eec7010dbe

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3780	[OpenFOAM] Feature	minor	N/A	2022-01-13 06:19	2022-01-13 06:19
Reporter:	cgoessni	Platform:	amd64
Assigned To:		OS:	CentOS
Priority:	normal	OS Version:	7
Status:	new	Product Version:	9
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	only move unmapped fields if command line option is set
Description:	mapFields and mapFieldsPar would move unmapped target fields to $FIELD_NAME.unmapped. This makes automatisation difficult. Thus, add an option moveUnmapped and only if this option is set, mapFields{,Par} would move unmapped target fields. Patch attached.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	moveUnmapped.txt (10,397 bytes) 2022-01-13 06:19 https://bugs.openfoam.org/file_download.php?file_id=3257&type=bug

There are no notes attached to this issue.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3775	[OpenFOAM] Bug	crash	always	2022-01-07 06:13	2022-01-07 10:24
Reporter:	cgoessni	Platform:	amd64
Assigned To:	henry	OS:	Debian
Priority:	normal	OS Version:	stable
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	crash in Foam::basicSpecieMixture::correctMassFractions()
Description:	Due to a wrong check (max vs min), Foam::basicSpecieMixture::correctMassFractions() would crash without any error message due to a wrong check. Patch attached
Tags:
Steps To Reproduce:	Setup case for reactingFoam with cells which have a sum of zero for species mass fractions
Additional Information:	Same erroneous check is also present in -dev
System Description
Attached Files:	basicSpecieMixture.diff.txt (405 bytes) 2022-01-07 06:13 https://bugs.openfoam.org/file_download.php?file_id=3252&type=bug

Notes
(0012361) henry    2022-01-07 10:24	Resolved in OpenFOAM-9 by commit 0622e9bea8c866c627c456d25ff34cf83bf37afd Resolved in OpenFOAM-dev by commit 0b681597c4cccff1d0d0f93133a139dcc20e97bc

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3774	[OpenFOAM] Bug	minor	always	2022-01-05 17:48	2022-01-05 19:12
Reporter:	joegi	Platform:
Assigned To:	henry	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	waterChannel tutorial wrong fieldi
Description:	When running the tutorial tutorials/multiphase/interFoam/RAS/waterChannel The solver gives the following warning, surfaceFieldValue inletFlux write: --> FOAM Warning :     From function virtual bool Foam::functionObjects::fieldValues::surfaceFieldValue::write()     in file fieldValues/surfaceFieldValue/surfaceFieldValue.C at line 809     Requested field rhoPhi not found in database and not processed Also, no information is saved in the output files surfaceFieldValue.dat The right field keyword should be phi instead of rhoPhi in the definition of the function object inletFlux.
Tags:
Steps To Reproduce:	Just run the tutorial tutorials/multiphase/interFoam/RAS/waterChannel
Additional Information:
Attached Files:

Notes
(0012359) henry    2022-01-05 18:44	phi is the volumetric flux and so not appropriate for this purpose, the intension is to obtain the mass flux. rhoPhi is no longer cached so either phi could be multiplied by rho in the sampling or maybe it would be better to include the phase-fraction to obtain the volumetric flux of the water.
(0012360) henry    2022-01-05 19:12	Resolved in OpenFOAM-9 by commit 1b6d2212992cd67409b49bebad8961a9bb120994 Resolved in OpenFOAM-dev by commit ef9707eaa76cb274618116790e0dc4b70fdde7c8

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3772	[OpenFOAM] Bug	minor	always	2021-12-28 12:09	2021-12-28 15:17
Reporter:	niklas.wikstrom	Platform:	x86_64
Assigned To:	henry	OS:	fedora
Priority:	normal	OS Version:	35
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Foam::cp() (POSIX) always returns false for file copy
Description:	When using Foam::cp() to copy a file, the function always returns false. This appears to be a wrong behaviour, since it makes it more difficult to assert success. The error might(!) be that std::ifstream::rdbuf() does not set the eof() flag: srcStream.eof() returns 0 both before and after the << srcStream.rdbuf()
Tags:
Steps To Reproduce:	Build and run the attached application # ./testFiles someFile copiedFile
Additional Information:	Also tested on the current docker image release.
System Description
Attached Files:	testFiles.tgz (1,101 bytes) 2021-12-28 12:09 https://bugs.openfoam.org/file_download.php?file_id=3247&type=bug testFiles.C (2,237 bytes) 2021-12-28 14:31 https://bugs.openfoam.org/file_download.php?file_id=3248&type=bug

Notes
(0012351) henry    2021-12-28 13:18	What do you propose to resolve this issue?
(0012352) henry    2021-12-28 14:23	I looked into the options for error handling and there is nothing obvious with is system independent. When we move to C++17 we will replace the current implementation of cp with filesystem::copy_file which provides error handling but in the meantime I think the best we can do is remove the EOF test.
(0012353) niklas.wikstrom    2021-12-28 14:31	The attached variant is probably naive, but it is at least faster (and it can be "eof checked"). I suppose one can remove the check altoghether, since it is not used in recursive cp (same function) anyway. This is ofcourse a tiny issue, but I wanted to report it, since I stumbled on it for a while. Happy new year!
(0012354) henry    2021-12-28 15:17	Resolved by commit 9f6e8e5effac9804af850bbb67bef660713d9c40

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3769	[OpenFOAM] Bug	trivial	always	2021-12-27 22:07	2021-12-27 23:27
Reporter:	jheylmun	Platform:	GNU/Linux
Assigned To:	henry	OS:	Other
Priority:	low	OS Version:	(please specify)
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	CellCuts constructor with List<plane> cannot be used
Description:	Because the plane class does not have a null constructor, it is not possible to create a list of planes for construction of the cellCuts class.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012344) henry    2021-12-27 23:08	Use PtrList for classes without a null constructor
(0012346) jheylmun    2021-12-27 23:14	The cellCuts explicitly specifies a List so a PtrList cannot be used currently.
(0012347) henry    2021-12-27 23:18	> CellCuts constructor with List<plane> cannot be used Where is this needed in OpenFOAM? In what way is this a bug? I am unable to reproduce the problem, OpenFOAM-9 and OpenFOAM-dev compile fine without any error in CellCuts.
(0012348) jheylmun    2021-12-27 23:23	I know it is not necessary for any current implementations, however I was looking to use it for additional development where cutting by planes is preferred.
(0012349) henry    2021-12-27 23:27	Resolved by commit d1d7963cf84c775c44ae1200d1393b95f961bd4f

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3768	[OpenFOAM] Bug	minor	always	2021-12-27 21:26	2021-12-27 23:13
Reporter:	jheylmun	Platform:	GNU/Linux
Assigned To:	henry	OS:	Other
Priority:	low	OS Version:	(please specify)
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	surfaceSphericalTensorFields are not mapped
Description:	surfaceSymmTensorFields are mapped twice, and surfaceSphericalTensorFields are not mapped. lines 608-611 of fvMesh.C
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012345) henry    2021-12-27 23:13	Resolved by commit 811fb750ee21c6a51ba49725becb32aad22eb891

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3763	[OpenFOAM] Feature	minor	N/A	2021-12-08 15:05	2021-12-10 09:50
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:	dev
		Target Version:
Summary:	Enable binary support for VTK set writer
Description:	Following the recent changes to streamlines, adding binary support for VTK streamlines should now be trivial. Here is a simple patch where false -> writeFormat_ so that user can set it to binary if needed. Binary streamlines save a bit of space if there are many lines and/or long streams with multiple variables.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:	patch.diff (492 bytes) 2021-12-08 15:05 https://bugs.openfoam.org/file_download.php?file_id=3243&type=bug

Notes
(0012307) will    2021-12-10 09:50	Thanks for pointing this out. Easy fix. https://github.com/OpenFOAM/OpenFOAM-dev/commit/d8a56df156e647b1d05d09b61e49e82e7b641e4b

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3762	[OpenFOAM] Bug	crash	always	2021-12-07 20:39	2021-12-07 21:35
Reporter:	cgoessni	Platform:	amd64
Assigned To:	henry	OS:	Debian
Priority:	normal	OS Version:	stable
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	XiEngineFoam crashes with adjustTimeStep yes
Description:	XiEngineFoam crashes with adjustTimeStep set to yes. Using dynamicCode for coded setDeltaT at line 57 in "/home/clemens/OpenFOAM/clemens-9/run/kivaTest/system/controlDict/functions/setDeltaT" Courant Number mean: 0 max: 0 deltaT = 0 Crank angle = -180 CA-deg deltaZ = 0 #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigFpe::sigHandler(int) at ??:? #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" #3 Foam::fvMesh::movePoints(Foam::Field<Foam::Vector<double> > const&) at ??:? #4 Foam::layeredEngineMesh::move() at ??:? #5 ? in "/home/clemens/local/OpenFOAM-9/platforms/linux64GccDPInt32Opt/bin/XiEngineFoam" #6 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #7 ? in "/home/clemens/local/OpenFOAM-9/platforms/linux64GccDPInt32Opt/bin/XiEngineFoam" If I add the following Info output to setDeltaT.H if (adjustTimeStep) {     scalar maxDeltaTFact = maxCo/(CoNum + small);     scalar deltaTFact = min(min(maxDeltaTFact, 1.0 + 0.1*maxDeltaTFact), 1.2); Info<< "maxDeltaTFact " << maxDeltaTFact << endl; Info<< "deltaTFact " << deltaTFact << endl; Info<< "deltaTValue() " << runTime.deltaTValue() << endl; Info<< "maxDeltaT " << maxDeltaT << endl;     runTime.setDeltaT     (         min         (             deltaTFact*runTime.deltaTValue(),             maxDeltaT         )     );     Info<< "deltaT = " << runTime.deltaTValue() << endl; } I get the following output: Using dynamicCode for coded setDeltaT at line 57 in "/home/clemens/OpenFOAM/clemens-9/run/kivaTest/system/controlDict/functions/setDeltaT" Courant Number mean: 0 max: 0 maxDeltaTFact 9.0072e+14 deltaTFact 1.2 deltaTValue() 2.77778e-05 maxDeltaT 0.000111111 deltaT = 0 Crank angle = -180 CA-deg deltaZ = 0 #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigFpe::sigHandler(int) at ??:? #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" #3 Foam::fvMesh::movePoints(Foam::Field<Foam::Vector<double> > const&) at ??:? #4 Foam::layeredEngineMesh::move() at ??:? #5 ? in "/home/clemens/local/OpenFOAM-9/platforms/linux64GccDPInt32Opt/bin/XiEngineFoam" #6 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #7 ? in "/home/clemens/local/OpenFOAM-9/platforms/linux64GccDPInt32Opt/bin/XiEngineFoam" Floating point exception So for some reason, setDeltaT sets it to zero unconditionally.
Tags:
Steps To Reproduce:	Take the tutorial $FOAM_TUTORIALS/XiEngineFoam/kivaTest and set adjustTimeStep yes
Additional Information:	Fixed in -dev, is a backport possible?
Attached Files:	patch (311 bytes) 2021-12-07 21:09 https://bugs.openfoam.org/file_download.php?file_id=3242&type=bug

Notes
(0012294) cgoessni    2021-12-07 20:59	Correction: adjustableRunTime has to be set too for this issue to trigger. The function adjustDeltaT() in OpenFOAM/db/Time.C seems to fail if user time is in CA
(0012296) henry    2021-12-07 21:09	Try OpenFOAM-dev
(0012297) cgoessni    2021-12-07 21:09	Problem can be resolved with the attached patch.
(0012299) henry    2021-12-07 21:13	I am unable to reproduce the problem in OpenFOAM-dev, so I believe it is already fixed.
(0012300) cgoessni    2021-12-07 21:17	Yes, the re-write of the userTime framework has resolved this issue. I will apply the patch that I posted for -9 locally. Thanks for the quick reply. Then both 0003761 and this report can be closed.
(0012303) henry    2021-12-07 21:35	Resolved by commit 15b2a2f42cdfce7c79b974e9be24a3320a6ef790 There is no issue is OpenFOAM-dev

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3761	[OpenFOAM] Bug	major	always	2021-12-07 20:29	2021-12-07 21:35
Reporter:	cgoessni	Platform:	amd64
Assigned To:	henry	OS:	Debian
Priority:	normal	OS Version:	stable
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	XiEngineFoam does not write to disk with adjustTimeStep yes and positive startTime
Description:	XiEngineFoam does not write output folders if adjustTimeStep is set to yes and if the start time is positive. I suspect that runTime.write() does not account for the CA => s conversion when checking if a file name exists.
Tags:
Steps To Reproduce:	see attached setup which is taken from $FOAM_TUTORIALS/combustion/XiEngineFoam/kivaTest, start time positive and adjustTimeStep true
Additional Information:	This issue is not reproducible in -dev. Is it still possible to backport a fix?
System Description
Attached Files:	kivaTest.tgz (1,351,572 bytes) 2021-12-07 20:29 https://bugs.openfoam.org/file_download.php?file_id=3241&type=bug

Notes
(0012295) henry    2021-12-07 21:02	I have completely rewritten the handling of engine time in OpenFOAM-dev so not it is not possible to back-port it to OpenFOAM-9 but you could rename OpenFOAM-dev to OpenFOAM-9 if you need all of those changes.
(0012298) cgoessni    2021-12-07 21:12	This problem is also resolved in OpenFOAM-9 with the patch that I just posted for 0003762. Thanks for your quick reply and the re-write. I will try it once OpenFOAM 10 is released.
(0012301) henry    2021-12-07 21:23	It would make sense for you to use OpenFOAM-dev as the new handling of engine time is MUCH better.
(0012302) henry    2021-12-07 21:35	Resolved by commit 15b2a2f42cdfce7c79b974e9be24a3320a6ef790 There is no issue is OpenFOAM-dev

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3760	[OpenFOAM] Bug	block	always	2021-12-07 17:03	2021-12-07 17:18
Reporter:	cgoessni	Platform:	amd64
Assigned To:	henry	OS:	Debian
Priority:	low	OS Version:	stable
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	valveBank.h does not compile due to a syntax error
Description:	In engine/engineValve/valveBank.H, there is a syntax error that makes any code that includes that header fail to compile. The issue is still present in -dev on lines 58-60 https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/src/fvMeshMovers/engine/engineValve/valveBank.H#L68
Tags:
Steps To Reproduce:	Try to include valveBank.H
Additional Information:	fix in https://github.com/OpenFOAM/OpenFOAM-dev/pull/38 for -dev
System Description
Attached Files:

Notes
(0012292) cgoessni    2021-12-07 17:06	Correction: The error is in lines 68-70 of course.
(0012293) henry    2021-12-07 17:18	Resolved by commit 25b60616ac3c64abb269e6a40e632fa4b8c7a83f

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3361	[OpenFOAM] Bug	major	always	2019-10-07 11:12	2021-12-07 12:25
Reporter:	niklas.wikstrom	Platform:	x86_64
Assigned To:	henry	OS:	Fedora
Priority:	normal	OS Version:	29
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	snappyHexMesh region refinement contaminates entire geometry facet
Description:	A distance refinement region sometimes refines entire triSurface facet. This happens when a refinement region entry specifies a distance that crosses at least one of the facet's edges. The problem occurs in parallel or serial runs and with OpenFOAM versions 5 to dev (7). On a geometry that has this problem it is allways reproducable, but manually generating a similar geometry to reproduce the problem is difficult.
Tags:
Steps To Reproduce:	Extract attached snappyBugReportRoom.tgz, run blockMesh and snappyHexMesh.
Additional Information:	The image file, attached, shows the overly refined facet and visualizes the distance refinement geometry object (pink), pointed at by the yellow line.
System Description
Attached Files:	geomFacetRef.png (928,134 bytes) 2019-10-07 11:12 https://bugs.openfoam.org/file_download.php?file_id=2794&type=bug snappyBugReportRoom.tgz (4,846 bytes) 2019-10-07 11:12 https://bugs.openfoam.org/file_download.php?file_id=2795&type=bug snappyHexMeshM.C (46,072 bytes) 2019-10-08 09:08 https://bugs.openfoam.org/file_download.php?file_id=2796&type=bug

Notes
(0010802) niklas.wikstrom    2019-10-07 11:14	Forgot to add: This issue is caused by the call to surfaces.setMinLevelFields(shells); in snappyHexMesh.C. Removing the call fixes the issue, but introduces other refinement problems.
(0010803) wyldckat    2019-10-07 16:23	I've had this issue for years and never reported it because I wasn't aware of how much it affects others. In a custom version we have internally, we have an option for turning off the following lines: - Starting here: https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/mesh/snappyHexMesh/refinementSurfaces/refinementSurfaces.C#L440 - Ending here: https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/mesh/snappyHexMesh/refinementSurfaces/refinementSurfaces.C#L448 This has been a custom option for us here at our office, but I've never tested this further to see how this affects other geometries. @niklas.wikstrom: Perhaps by only commenting out the lines I've pointed out, instead of simply commenting 'setMinLevelFields', does it reduce the occurrence of the refinement problems you've seen? Or do the same issue occur?
(0010804) niklas.wikstrom    2019-10-08 05:18	Yes, It's been around, and I mostly have gotten around it through geometry refinements :-D Thanks a lot! I'll try the modification. /Niklas
(0010805) niklas.wikstrom    2019-10-08 09:08	It seems to work fine, although I overloaded the setMinLevelFields() in a modified snappyHexMesh.C, thus keeping the src tree intact. (Attaching my local version of snappyHexMesh.C, this is for v5, but minor changes to dev) Thank you again. /N
(0010806) henry    2019-10-08 14:40	This change could be put on an optional switch, what do you think would be an appropriate name for it? A better option would be to change the refinement approach so that it isn't so sensitive to the aspect ratio of the triangles (I am assuming the issue is with long thin triangles), any thoughts?
(0010808) wyldckat    2019-10-08 15:38	@henry: We defined the switch as 'triSurfacesLevelsOnly' in the 'castellatedMeshControls' dict. I have the very vague idea that the problem occurs when the triangle was large/long enough to overlap multiple refinement regions, resulting in being affected by the other refinement definitions. From what I can remember, there was no clear fix at the time when I saw and tried to fix this issue, only turning off that particular detection would do the trick.
(0010809) niklas.wikstrom    2019-10-08 15:54	Good with a switch in the dictionary. Note, however, that the facet in my example above does not have a large aspect ratio; just three or so, but the facet gets refined as soon as the distance ref reaches across its edge(s?). The switch name 'triSurfacesLevelsOnly' might need some explanation ;-) It would be interesting to know when the feature is needed, but I guess I'll figure it out if I run without it for a while. Thanks for helping!
(0010810) henry    2019-10-08 16:06	@niklas.wikstrom Do you have a better name in mind? Is this feature needed at all? Shall I simply remove it? If I add a switch what should the default be? If it is true how will people know that they need to set it to false?
(0010814) niklas.wikstrom    2019-10-08 16:57	Very vague suggestions below, since I do not know what else the thing affects. Name: shellLevelToFacets Default: false Will show faster if it's needed or not, set the default to false and wait for bug reports... Needed? I do not know, but I assume there was a good reason for it. Better keep it.
(0010816) henry    2019-10-08 17:25	The problem is that if it is needed and was put in for good reason it should be on by default for backward compatibility unless we know for sure that it actually generally not needed and then we need to know for what cases it is needed so that we can inform people of the change in default behavior.
(0010818) niklas.wikstrom    2019-10-08 20:37	I realise that. It is safer. I will run without the thing and if I find some inconsistency or find out what it is all about, I will report back. /N
(0010888) henry    2019-11-12 16:10	Is there any progress and/or recommendations on this or should I close the report?
(0010895) niklas.wikstrom    2019-11-13 14:34	Hello! I have not seen any issues with the feature turned off, but have not much statistics. However, I think it is a good idea to add the option "shellLayerToFaces" with default value "true" to snappyHexMesh. And then close the issue.
(0010896) henry    2019-11-13 14:39	How should I document this change? Can any particular recommendations be made? When should users consider changing this switch? If we don't say anything it will just be a hidden switch that no one knows about or knows how to use so there wouldn't be much point having it.
(0010897) wyldckat    2019-11-13 15:17	If I'm not mistaken, the description can be along these lines:    This option will allow tessellated surfaces (shells?) to inherit refinement levels from other overlapping features. If you see unwanted refinement spreading onto triangles, turn off this option. As a side note, I very vaguely remember seeing this happen when larger triangles were overlapping smaller features that I wanted to have refined and yet the large triangle centres would get caught on the overlapping heuristic.
(0010901) henry    2019-11-14 12:03	It is not clear for what cases this refinement condition is useful and given the difficulty in choosing a suitable name for the option, how to control it, what the default should be or when to recommend it should be switched on or off it makes sense to remove it for now and reinstate under an option if cases are found and reported which benefit from this option. commit a64d71929f0a51229ef6c5603af1d1ca21dad5f1 Author: Henry Weller <http://openfoam.org> Date: Thu Nov 14 11:51:13 2019 +0000     snappyHexMesh::refinementSurfaces: Removed problematic shell refinement transfer to surface                      // Find out if triangle inside shell with higher level                 // What level does shell want to refine fc to?                 //                 // Note: it is not clear for what cases this additional requirement                 // is beneficial but for triangulated surfaces with triangles that                 // span refinement regions it introduces unnecessary refinement so                 // it has been removed.                 //                 // This option can be reinstated under a switch if cases are                 // provided which demonstrate the benefit.                 /*                 labelList shellLevel;                 shells.findHigherLevel(ctrs, minLevelField, shellLevel);                      forAll(minLevelField, i)                 {                     minLevelField[i] = max(minLevelField[i], shellLevel[i]);                 }                 */
(0012291) henry    2021-12-07 12:25	commit 5d93da3aed0d03b38081717e29cfd506eba294a9 (HEAD -> master, origin/master, origin/HEAD) Author: Henry Weller <http://cfd.direct> Date: Tue Dec 7 12:17:52 2021 +0000     snappyHexMesh: Added castellatedMeshControls:extendedRefinementSpan option          The code relating to extending refinement to the span of the facet/triangles     intersected by the refinement distance referred to in report          https://bugs.openfoam.org/view.php?id=3361          and temporarily removed may now be selected by the optional     castellatedMeshControls:extendedRefinementSpan entry in snappyHexMeshDict. It     in not clear if this control is generally beneficial and very few users have     reported a preference and too few example cases have been provided to make a     balanced judgement so it has been decided to reinstate the previous default     behaviour and default extendedRefinementSpan to true.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3759	[ThirdParty] Bug	major	always	2021-11-30 06:53	2021-12-01 16:15
Reporter:	sjohn2	Platform:	Linux
Assigned To:	chris	OS:	Ubuntu
Priority:	high	OS Version:	21.10 (impish)
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Problem with openfoam V9 installation on Ubuntu 21.10
Description:	I have downloaded the latest version for Ubuntu for my newest Ryzen processor and I have issues installing OpenFoam V9 The problem is with the Third Party software and the log files are attached Is there additional libraries I need to install for this to work?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:	logAllwmake (1,315 bytes) 2021-11-30 06:53 https://bugs.openfoam.org/file_download.php?file_id=3238&type=bug logmakeParaView (287,444 bytes) 2021-11-30 06:53 https://bugs.openfoam.org/file_download.php?file_id=3239&type=bug log.makeParaView (310,755 bytes) 2021-11-30 09:36 https://bugs.openfoam.org/file_download.php?file_id=3240&type=bug

Notes
(0012286) wyldckat    2021-11-30 08:48	There are no clear error messages in the log for ParaView. Please run with the redirection of the error output into standard output, e.g.:   ./makeParaView > log.makeParaView 2>&1
(0012287) sjohn2    2021-11-30 09:36	Please see attached the updated file. Also to add, I followed the installation procedure the openfoam.org website.
(0012288) wyldckat    2021-11-30 10:21	OK, so the error was this: In file included from ........../OPENFOAM/V9/ThirdParty-9/build/linux64Gcc/ParaView-5.6.3/Wrapping/ClientServer/vtkMathClientServer.cxx:5: ........../OPENFOAM/V9/ThirdParty-9/ParaView-5.6.3/VTK/Common/Core/vtkMath.h: In static member function ‘static T vtkMath::ClampValue(const T&, const T&, const T&)’: ........../OPENFOAM/V9/ThirdParty-9/ParaView-5.6.3/VTK/Common/Core/vtkMath.h:1514:15: error: ‘clamp’ is not a member of ‘std’  1514 | return std::clamp(value, min, max);       | ^~~~~ Given that there are Deb packages provided for OpenFOAM 9 on Ubuntu 21.10: https://openfoam.org/news/v9-patch/ - means that it was compiled somehow... @Chris and @Will: I don't know which one of you are handling the deb package generation nowadays, but given the error above, was ParaView built with GCC 10 for the package paraviewopenfoam56, on Ubuntu 21.10? Or perhaps is a commit missing in the repository for it: https://github.com/OpenFOAM/ThirdParty-9/
(0012290) chris    2021-12-01 16:14	Fixed in dev and v9 by commits: dev: https://github.com/OpenFOAM/ThirdParty-dev/commit/8376b2 v9: https://github.com/OpenFOAM/ThirdParty-9/commit/c2955c

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3755	[OpenFOAM] Bug	minor	always	2021-11-24 08:30	2021-11-25 10:10
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:	MaxwellStefanFourier, crash if calling j() or divj() for default specie
Description:	In MaxwellStefanFourier, if calling j() (or divj) for default specie the code will crash because jexp_ has not been allocated. This problem is not severe as j() is not needed to obtain the simulation results. However, calling j() might be interesting for eg. post-processing, in which case if looping over all species, the code will crash.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0012270) henry    2021-11-24 11:19	The default specie is not solved for so divj() should not be needed and it is not clear how either divj() or j() should be calculated, it could be based on the balance from the solution of the equation system or assuming that the net diffusion is 0, i.e. from the -sum of all the other species. Either approach will be expensive for divj() and it is not clear it is needed but would be OK for j().
(0012271) tniemi    2021-11-24 11:32	Yes, I would say modifying divj() is unnecessary, or at least I have never routinely used it for anything outside of the solvers. I guess the -sum approach would be reasonable for j() and I think it would be consistent with q(). As said, this is not a big deal but it would be nice not to have to escape the default specie when checking diffusion fluxes.
(0012272) henry    2021-11-24 14:54	Try with commit e931ccada1152fd6ca527c11b2a5caa2dba91394
(0012275) tniemi    2021-11-25 08:38	Thanks! Seems to be working.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3754	[OpenFOAM] Contribution	minor	N/A	2021-11-20 14:36	2021-11-20 21:04
Reporter:	thf5000y2k	Platform:	GNU/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:
		Target Version:
Summary:	Rudundent expression in blockMesh causes performance lost
Description:	There's redundent expression in "/applications/utilities/mesh/generation/blockMesh/blockMesh.C". It leads a recomputation for blockMesh's cells, which could be avoid. https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/applications/utilities/mesh/generation/blockMesh/blockMesh.C - line276 const List<FixedList<label, 8>> blockCells = b.cells(); - line305 celli += b.cells().size(); The b.cells() in line 305 is same as that in line 276. It can be fixed by the statements below. - line276 const List<FixedList<label, 8>> blockCells = b.cells(); - line305 celli += blockCells.size();
Tags:
Steps To Reproduce:	Just look up the source code, then can easily find out. https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/applications/utilities/mesh/generation/blockMesh/blockMesh.C
Additional Information:
System Description
Attached Files:

Notes
(0012269) henry    2021-11-20 21:04	Resolved by commit c9b4fc75d4246f877d63d91f1bec504b71d26e7f

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3750	[OpenFOAM] Feature	text	always	2021-11-02 09:19	2021-11-02 11:57
Reporter:	peksa	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:	9
		Target Version:
Summary:	UniformTable2 header example text clarification.
Description:	Dear developers, I was trying to learn how to use UniformTable2 function feature in latest OpenFOAM-dev. I looked-up the source header (UniformTable2.H) for an example usage but quickly became puzzled by two aspects: 1) There is no pLow/pHigh/Tlow/Thigh keywords but they are replaced by low/high pairs. 2) How one should give a 2d matrix as an input for the "values" keyword? The present example is valid for 1d arrays only. 3) In case of two variables, which one corresponds the matrix row and column, respectively? I had to look into source code to ensure the behavior. Hence, I'd like to propose the following new header documentation: ------------------------     Example for the density of water between 1-3 bar (3 rows) and 280-350K (2 columns)     \verbatim     rho     {           type uniformTable;           low (1e5 280);           high (3e5 350);           values           3 2           (             (991 992)             (993 994)             (995 996)           );     }     \endverbatim ------------------------
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012264) henry    2021-11-02 11:57	Resolved in OpenFOAM-9 by commit 149c9bcc44ef86d6ab4102466046d6040a426fb8 Resolved in OpenFOAM-dev by commit 2d1c97f4fa8abef5143b4a8deec3d91f0beca807

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3748	[OpenFOAM] Bug	tweak	always	2021-10-29 09:23	2021-10-29 10:49
Reporter:	mboesi	Platform:	Unix
Assigned To:	henry	OS:	Ubuntu
Priority:	normal	OS Version:	18.04
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	Significant MPI overhead when solving chemistry if mechanism reduction is not active
Description:	The active species are synced between the different MPI processors at the end of the solve method in TDACChemistryModel:     if (Pstream::parRun())     {         List<bool> active(composition.active());         Pstream::listCombineGather(active, orEqOp<bool>());         Pstream::listCombineScatter(active);         forAll(active, i)         {             if (active[i])             {                 composition.setActive(i);             }         }     } If the mechanism reduction is not active, the active species should never change and, thus, the sync should not be required. I've done some code profiling in parallel mode which showed that typically more than 30% of the computational costs arise from that MPI communication. I'm still running some tests on this. To prevent this excessive and, in cases without mechanism reduction, unnecessary MPI communication, the synchronization of the active species should only be done when mechanism reduction is actvite: OF9: if (Pstream::parRun() && reduced) OFdev if (Pstream::parRun() && mechRedActive_)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:

Notes
(0012261) henry    2021-10-29 10:49	Resolved in OpenFOAM-9 by commit bafd78b3f46220b574bc6792b5a495bfca32da30 Resolved in OpenFOAM-dev by commit f376c1b08792892d225729e40925f6d3ff804035

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3746	[OpenFOAM] Bug	minor	always	2021-10-23 23:15	2021-10-27 23:50
Reporter:	noZeroDays	Platform:
Assigned To:	henry	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	keyword coordinateSystem is undefined in dictionary
Description:	Using an example of fieldCoordinatesSystemTransform doesn't work as shown below;     fieldCoordinateSystemTransform1     {         type fieldCoordinateSystemTransform;         libs ("libfieldFunctionObjects.so");         enabled true;         fields         (             U         );         coordinateSystem         {             origin (0 0 0.005);             coordinateRotation             {                 type axesRotation;                 e1 (1 0.15 0);                 e3 (0 0 -1);             }         }     } Running: pimpleFoam -postProcess I get: keyword coordinateSystem is undefined in dictionary "/tmp/test/system/controlDict/functions/fieldCoordinateSystemTransform1/coordinateSystem" Similarly, using a coordinates system with another function object such as forces, raises the error reported here: https://bugs.openfoam.org/view.php?id=2454
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0012256) noZeroDays    2021-10-23 23:17	The example of fieldCoordinatesSystemTransform was taken from: /opt/openfoam9/src/functionObjects/field/fieldCoordinateSystemTransform/fieldCoordinateSystemTransform.H
(0012257) henry    2021-10-24 11:36	fieldCoordinateSystemTransform was considerably out of date due to lack of use, try this in OpenFOAM-dev: commit cdefd715213942a792e54cdb496d82ded01058de (HEAD -> master, origin/master, origin/HEAD) Author: Henry Weller <http://cfd.direct> Date: Sun Oct 24 11:33:56 2021 +0100     fieldCoordinateSystemTransform: Updated coordinateSystem construction and documentation          Resolves bug-report http://bugs.openfoam.org/view.php?id=3746

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3744	[OpenFOAM] Bug	minor	always	2021-10-22 18:42	2021-10-27 23:50
Reporter:	millszg	Platform:	GNU/Linux
Assigned To:	henry	OS:	Ubuntu
Priority:	normal	OS Version:	15.04
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Unable to use codedFunction2 for the binary diffusion terms in the thermophysical transport models
Description:	When attempting to use a codedFunction2 for the binary diffusion terms in the thermophysical transport model, the code is unable to compile because the dictionary key which contains a dash (i.e. H2-H) is used in the name of the generated functions. I am new to using codedFunction2, so I'm not sure if it is possible to specify the name to use for the generated function, but if not, its likely not possible to use codedFunction2 in the current implementation. Currently I have implemented changes in the code to use an underscore instead of a dash in the binary diffusion term keys. This allows for codedFunction2 to be used as the generated names no longer have an illegal character in them, but I have not tested to make sure it doesn't break other parts of the code.
Tags:
Steps To Reproduce:	I believe this will occur anytime codedFunction2 is used for a binary diffusion term in the thermophysicalTransport file. Specifically for me, using the following in thermophysicalTransport with reactingFoam produced errors relating to the function name (which contained H2-H) when the dynamic code was being compiled: simulationType laminar; laminar {     model FickianFourier;     mixtureDiffusionCoefficients no;    D    {        H2-H         {         type coded;         code         #{             return x * sqrt(x) / y * (0.00300504 + x * (5.57725e-06 + x * (-6.00278e-09 + x * (3.45469e-12 + x * (-7.73951e-16)))));         #};     } } When I updated the code in
Additional Information:	By changing lines 116 and 117 in Fickian.C from: const word nameij(species[i] + '-' + species[j]); const word nameji(species[j] + '-' + species[i]); to: const word nameij(species[i] + '_' + species[j]); const word nameji(species[j] + '_' + species[i]); and updating the binary diffusion keys in thermophysicalTransport to use underscores as well, the dynamic code was able to compile and reactingFoam was able to run without issues.
System Description
Attached Files:

Notes
(0012258) henry    2021-10-24 11:41	Try this in OpenFOAM-dev: commit ad28cb49b553efb43f036b424bd8b5d0c0022c7c (HEAD -> master, origin/master, origin/HEAD) Author: Henry Weller <http://cfd.direct> Date: Sun Oct 24 11:38:55 2021 +0100     codedBase: Added support for '-' in entry names          by mapping '-' to '_' in the generation of the code name.          Resolves bug-report https://bugs.openfoam.org/view.php?id=3744

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3747	[OpenFOAM] Bug	minor	always	2021-10-27 15:07	2021-10-27 23:49
Reporter:	hussam	Platform:	GNU/Linux
Assigned To:	henry	OS:	CentOS
Priority:	normal	OS Version:	7
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	constAnIso works rather than constAnIsoSolid
Description:	Using constAnIsoSolid for transport in solids triggers a dynamicCode compilation and ends with the following error message. But if one uses constAnIso (old keyword) everything works fine. --> FOAM FATAL ERROR: Compilation and linkage of solidThermo type thermoType {     type heSolidThermo;     mixture pureMixture;     transport constAnIsoSolid;     thermo eConst;     equationOfState rhoConst;     specie specie;     energy sensibleInternalEnergy; } failed. Valid solidThermo types are: type mixture transport thermo equationOfState specie energy heSolidThermo pureMixture constAnIso eConst rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture constAnIso eIcoTabulated rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture constAnIso ePolynomial rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture constAnIso ePower rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture constIsoSolid eConst rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture constIsoSolid eIcoTabulated rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture constIsoSolid ePolynomial rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture constIsoSolid ePower rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture exponentialSolid eConst rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture exponentialSolid eIcoTabulated rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture exponentialSolid ePolynomial rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture exponentialSolid ePower rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture polynomialSolid eConst rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture polynomialSolid eIcoTabulated rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture polynomialSolid ePolynomial rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture polynomialSolid ePower rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture tabulatedSolid eConst rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture tabulatedSolid eIcoTabulated rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture tabulatedSolid ePolynomial rhoConst specie sensibleInternalEnergy heSolidThermo pureMixture tabulatedSolid ePower rhoConst specie sensibleInternalEnergy
Tags:
Steps To Reproduce:	Use coolingSphere tutorial and use the physicalProperties file in the attachments to replace the physicalProperties of the region "solid"
Additional Information:	Every thing works fine by using the old keyword "constAnIso"
System Description
Attached Files:	physicalProperties (1,578 bytes) 2021-10-27 15:07 https://bugs.openfoam.org/file_download.php?file_id=3233&type=bug

Notes
(0012259) henry    2021-10-27 16:33    (Last edited: 2021-10-27 16:49)	Try OpenFOAM-dev commit 40e072670efe02b09c8a37334766c2e7a77d0413 OpenFOAM-9 commit 0e7658d0993197a2df1ed494c0afbe8c50a2970b
(0012260) hussam    2021-10-27 21:03	confirming: issue solved using dev commit above.. thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3743	[OpenFOAM] Bug	minor	always	2021-10-22 18:25	2021-10-22 23:03
Reporter:	millszg	Platform:	GNU/Linux
Assigned To:	henry	OS:	Ubuntu
Priority:	normal	OS Version:	15.04
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	Possible error in unityLewisFourier::j
Description:	In member function j of unityLewisFourier on line 129 this->thermo().alpha() is used directly for the diffusion coefficient of the mixture. Because Fickian inherits from unityLewisFourier and calls BasicThermophysicalTransportModel::j to calculate the species mass flux, it will also use alpha instead of its calculated diffusion coefficients. I am still learning the new code and might be missing something, but I think that replacing this->thermo().alpha() with this->DEff(Yi) will ensure that the correct diffusion coefficients are used for both the Fickian and unityLewis models.
Tags:
Steps To Reproduce:	Will occur anytime the Fickian thermophysical transport model is used for species transport.
Additional Information:
System Description
Attached Files:

Notes
(0012252) henry    2021-10-22 18:39	> replacing this->thermo().alpha() with this->DEff(Yi) Where are you proposing this replacement?
(0012253) millszg    2021-10-22 18:46	Line 129 in unityLewisFourier.C: -fvc::interpolate(this->thermo().alpha()*this->alpha()) would become: -fvc::interpolate(this->DEff(Yi)*this->alpha())
(0012254) henry    2021-10-22 22:36	Yes, you are correct. It might make more sense to create a more general base-class which both unityLewisFourier and FickianFourier inherit to avoid the apparently inconsistent treatment of j and q.
(0012255) henry    2021-10-22 23:03	Resolved in OpenFOAM-9 by commit 046fce5c18c35d671aa417883a6fda97e3075e5c Resolved in OpenFOAM-dev by commit c515e74e008c9e4348f85c39aa3647a325ae8d04

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3736	[OpenFOAM] Bug	minor	N/A	2021-10-05 21:00	2021-10-19 11:04
Reporter:	felipe	Platform:	UBUNTU 20.04
Assigned To:	chris	OS:	Windows
Priority:	normal	OS Version:	10
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Issue launching paraFoam
Description:	paraFoam doesn't lauch anything and I get the following message: felipe@VSAV418PROY:~/OpenFOAM/felipe-9/run/cavity$ paraFoam & [2] 288 felipe@VSAV418PROY:~/OpenFOAM/felipe-9/run/cavity$ Created temporary 'cavity.OpenFOAM' /opt/paraviewopenfoam56/lib/paraview: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
Tags:
Steps To Reproduce:	I've just installed OpenFOAM following the instructions from this page: https://openfoam.org/download/9-ubuntu/ Then, as I was following the instructions from the tutorial on this page: https://cfd.direct/openfoam/user-guide/v9-cavity/#x5-110002.1.2 , on step 2.1.2, the bug occurred after writing " paraFoam & "
Additional Information:	I'm a complete newb on Ubuntu and OpenFOAM, perhaps I've made an obvious mistake...
Attached Files:

Notes
(0012214) wyldckat    2021-10-06 16:08	OK, this one was not a easy fix and what I'm going to describe now is just working around the real issue: it seems to be WSL's v1 fault and has been for over 2 years, the odd thing is that it only revealed itself more recently in Ubuntu, apparently due to the linker libraries... Sources for this fix: - https://askubuntu.com/questions/1034313/ubuntu-18-4-libqt5core-so-5-cannot-open-shared-object-file-no-such-file-or-dir - https://github.com/microsoft/WSL/issues/3023 - https://github.com/YosysHQ/nextpnr/issues/444 - https://stackoverflow.com/questions/63627955/cant-load-shared-library-libqt5core-so-5 - https://discourse.paraview.org/t/build-paraview-inside-windows-subsystem-for-linux-wsl/6439/15 The workaround is as follows: 1. Install VcXsrv, instead of Xming. It's a lot more recent and it has a lot more options: https://sourceforge.net/projects/vcxsrv/files/vcxsrv/     - I used the installer "vcxsrv-64.1.20.9.0.installer.exe" 2. Then start 'XLaunch' that was installed with VcXsrv and configure the "Extra settings" window as explained here: https://discourse.paraview.org/t/build-paraview-inside-windows-subsystem-for-linux-wsl/6439/16 - namely:    a. Unselect the Native opengl    b. Select the "Disable access control" option. 3. Now comes a somewhat annoying workaround, which may limit Qt5's usability in your WSL-Ubuntu installation, which is to run the following command:     sudo strip --remove-section=.note.ABI-tag /usr/./lib/x86_64-linux-gnu/libQt5Core.so.5     - This will remove the bit that breaks WSL's mask in pretending to be a valid Linux Kernel, but may make a few other applications get confused with the missing note/tag.     - You can reinstall this library by running:          sudo apt install --reinstall libqt5core5a 4. The rest is as per instructions given here: https://openfoam.org/download/windows/ - with the exception of replacing Xming with VcXsrv.
(0012215) wyldckat    2021-10-06 16:15	A somewhat better workaround without damaging Qt5's default installation on Ubuntu, is to run the following commands:    sudo cp /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 /opt/paraviewopenfoam56/mesa/lib/    sudo strip --remove-section=.note.ABI-tag /opt/paraviewopenfoam56/mesa/lib/libQt5Core.so.5
(0012216) wyldckat    2021-10-06 16:16	@Chris With these findings, the changes I propose for this page: https://openfoam.org/download/windows/ - are as follows: 1. Replace Xming with VcXsrv, since it's a lot more recent and it has a lot more options: https://sourceforge.net/projects/vcxsrv/files/vcxsrv/ 2. Have the users run the following workaround or provide the Qt5 library already modified in the Deb package with these commands?    sudo cp /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 /opt/paraviewopenfoam56/mesa/lib/    sudo strip --remove-section=.note.ABI-tag /opt/paraviewopenfoam56/mesa/lib/libQt5Core.so.5
(0012217) felipe    2021-10-07 17:10	Thanks a lot! FYI, the first suggestion didn't work out, but I reinstalled libqt5core5a as you instructed, then tried the second workaround and this time it worked great.
(0012218) chris    2021-10-07 19:46	@wyldckat @felipe Thanks for working through this issue. Just confirming the suggestion to change the windows installation page at: https://openfoam.org/download/windows/ 1) Use VcXsrv instead of Xming, configure settings as described above 2) IF you get the error message: /opt/paraviewopenfoam56/lib/paraview: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory then run sudo cp /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 /opt/paraviewopenfoam56/mesa/lib/ sudo strip --remove-section=.note.ABI-tag /opt/paraviewopenfoam56/mesa/lib/libQt5Core.so.5
(0012219) chris    2021-10-07 22:37	@wyldckat Let me know if the note above is what you suggest here
(0012220) wyldckat    2021-10-08 10:58	@Chris: Yes, that's exactly it! I've only confirmed this for Ubuntu 20.04, I have no idea if this is still an issue on Ubuntu versions 20.10 and 21.04/10. An additional quick suggestion/note as well: is it possible to have an automatic link that links people to the latest OpenFOAM version? It would be useful for this Windows page, given that it's rarely updated (given it was still at OpenFOAM 8 the other day).
(0012221) chris    2021-10-08 12:00	@wyldckat We have always had this link: https://openfoam.org/latest But here, I suspect you mean a link to the latest version packed for Ubuntu. Is that correct?
(0012222) wyldckat    2021-10-08 12:12	@Chris: Yes, I'm referring to the Ubuntu package, if possible. If not, having a link to the latest one would already be a nice feature. The other alternative would be to have a dummy deb package that always points to the latest stable package... and mention that on the Windows page.
(0012223) chris    2021-10-08 13:40	@wyldckat OK, added this temporary redirect (so it can be modified) https://openfoam.org/download/latest-ubuntu Before I change the Windows install page, I need to check: + In Enabling Graphical Applications, does the user still need to do set the DISPLAY environment variable? + I assume the changes are for Ubuntu 20.04? (We should not maintain instructions for different versions of Ubuntu)
(0012224) wyldckat    2021-10-08 15:34	@Chris > + In Enabling Graphical Applications, does the user still need to do set the DISPLAY environment variable? Yes, it's still necessary. > + I assume the changes are for Ubuntu 20.04? (We should not maintain instructions for different versions of Ubuntu) This is something that occurs due to WSL v1, namely the subsystem that pretends that it's a Linux Kernel, so it has been affecting several Linux Distributions since 2019. Ubuntu 22.04 is the next major version that will possibly be supported on WSL v1... As for WSL v2, it still needs VcXsrv and the settings aforementioned, but it's a whole other ball game when in comes to installation and setting up... I'll open another report regarding WSL v2.
(0012227) chris    2021-10-11 09:37	@wyldckat I am trying to update the instructions on installing on Windows. I don't have access to Windows so am operating blind. So I need to run some questions by you. The first big issue is the version of WSL. The instructions direct the reader to https://docs.microsoft.com/en-gb/windows/wsl/install As usual, the MS documentation is unclear, confusing, incomplete, circularly referencing, etc. Basically garbage. Under the WSL install command it says: "This command will enable the required optional components, download the latest Linux kernel, set WSL 2 as your default, and install a Linux distribution for you (Ubuntu by default, see below to change this)." This seems to indicate that the user will get WSL v2. You seem to indicate they need to use WSL v1. What do we say here in our instructions? When they install WSL v1, is Ubuntu 20.04 the default? (MS docs say nothing about version of Ubuntu).
(0012228) chris    2021-10-11 09:53	@wyldckat I have made edits you mentioned: https://openfoam.org/download/windows/ I think we just need to clarify the WSL installation
(0012233) wyldckat    2021-10-12 17:50	@Chris Quick side note: "pavaview" typo in the "Problem running ParaView" section, namely it's "para" and not "pava" ;) I might as well write the WSL v2 report here, instead of opening a new one. WSL acts as if it was a form of virtualization software: - v1 would pretend that it was a Linux kernel, so it was similar to using chroot on Linux, while using its own virtual filesystem. - v2 uses VM technology to instead use a real Linux Kernel, hence minimizing compatibility issues to a minimum. This means that both versions don't care if the end-user wants Ubuntu, Fedora, OpenSUSE or any other Linux distribution. Now, the annoying part is that WSL v2 also has it's flaws, namely that it's not as straight forward as v1 was. Which leads us to two user scenarios: A- In a clean Windows install, namely the user is installing WSL for the first time, it should work as described in the official documentation. Therefore:   1. VcXsrv is needed as described.   2. The hack for "libQt5Core.so.5" associated to WSL v1 is no longer needed.   3. The following line:       echo "export DISPLAY=:0" >> ${HOME}/.bashrc     now becomes:       echo 'export DISPLAY=$(awk \'/nameserver / {print $2; exit}\' /etc/resolv.conf 2>/dev/null):0' >> ${HOME}/.bashrc     Why? It's now a legitimate VM, therefore it needs its own virtual network connection.     - An alternative to get the up-to-date guest IP address is to use instead this command, in case "resolv.conf" was somehow disabled:       echo 'export DISPLAY=$(ip route | awk \'/^default/{print $3; exit}\'):0' >> ${HOME}/.bashrc So, if it's a clean install, following the official instructions should work. Source on the ways to set "DISPLAY": https://stackoverflow.com/questions/61110603/how-to-set-up-working-x11-forwarding-on-wsl2 The scenario B will be in my next comment.
(0012234) wyldckat    2021-10-12 18:02	Scenario B - If the user already has WSL v1 installed, things get a little bit trickier... Nonetheless, here are the steps I had to do in order to upgrade Ubuntu 20.04 installation from WSL v1 to v2: 1. Follow the official instructions for upgrading from v1 to v2: https://docs.microsoft.com/en-gb/windows/wsl/install-manual 2. After rebooting the Windows machine, upgrade the Ubuntu installation with the following commands from a command line:     wsl -l -v     wsl --set-version Ubuntu-20.04 2   where "Ubuntu-20.04" is the name of the distribution installed... the user might have more than one Ubuntu version installed or simply have the one named "Ubuntu" from the MS Store, which provides the latest Ubuntu LTS version (20.04 at the moment). 3. Regarding firewall, to allow the VM to communicate the X protocol via virtual network, is a pain to explain it right now... there are already a few instructions online, such as the following: https://github.com/cascadium/wsl-windows-toolbar-launcher#firewall-rules
(0012239) chris    2021-10-18 14:23	@wyldckat Apologies for the delay on this. I have updated the page: https://openfoam.org/download/windows/ Let me know if you think this is OK assuming we ignore: + disabling of resolv.conf + scenario B: upgrade from WSL v1 to WSL v2 (scenario B)
(0012240) wyldckat    2021-10-18 15:00	@Chris No problem for the delay... at least I don't think so... The page now looks perfectly fine, it covers the majority of the issues. Anything beyond this is up to the end user to sort out on their own... and/or pointing them to this report will also help them sorting it out on their own.
(0012242) chris    2021-10-19 10:59	@wyldckat Thanks for your response and your hard work on this. I think we are OK to close the thread.
(0012243) chris    2021-10-19 11:04	Windows installation page updated, based on discussion: https://openfoam.org/download/windows/ There may be 1-2 minor additions which can be dealt with when needed. At the end of the day, Microsoft are a $1 trillion company so they should be funding the support of OpenFOAM on their OS: https://openfoam.org/supporters/

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3740	[OpenFOAM] Bug	major	always	2021-10-18 14:43	2021-10-18 16:03
Reporter:	peksa	Platform:	GNU/Linux
Assigned To:		OS:	Ubuntu
Priority:	normal	OS Version:	15.04
Status:	new	Product Version:	dev
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Misleading pressure difference calculation in activePressureForceBaffleVelocityFvPatchVectorField.C
Description:	Dear developers, In the boundary condition "activePressureForceBaffleVelocityFvPatchVectorField" a choice for opening a wall/cyclic baffle can be chosen to depend on either force or pressure difference. However, the pressure difference is calculated as an explicit loop over patch faces with no weighting, leading to wrong behavior. See the problematic code snippet below: -------------------------------------------------------------------------             forAll(cyclicFaceCells, facei)             {                 valueDiff += p[cyclicFaceCells[facei]];             }             forAll(nbrFaceCells, facei)             {                 valueDiff -= p[nbrFaceCells[facei]];             }             Info<< "Pressure difference = " << valueDiff << endl;         }         if ((mag(valueDiff) > mag(minThresholdValue_)) || baffleActivated_)         {              ....         } ------------------------------------------------------------------------- One should use the same valueDiff definition as for the force but then divide the summed scalar by area to get a weighted difference:             valueDiff = valueDiff/gSum(patch().magSf()); An example fix is presented earlier on ESI version: https://develop.openfoam.com/Development/openfoam/-/commit/da6675803b167e7c51c1d2da4d6a0d95e297e1c1
Tags:
Steps To Reproduce:	See source code.
Additional Information:
System Description
Attached Files:	activePressureForceBaffleVelocityFvPatchVectorField.patch (2,444 bytes) 2021-10-18 16:03 https://bugs.openfoam.org/file_download.php?file_id=3232&type=bug

Notes
(0012241) peksa    2021-10-18 16:03	Something like this should work and showed sane performance in my initial simple test case.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3739	[OpenFOAM] Bug	minor	always	2021-10-13 17:17	2021-10-14 14:38
Reporter:	niklas.wikstrom	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:	9
		Target Version:
Summary:	Dimension error in functionObjects/field/comfort.C
Description:	In comfort.C there is a warningInFunction when radiative temperature is out of norm bounds and when the warning message is composed a dimensionedScalar is subtracted by a scalar. Simply change "Trad - 273.15" to "Trad.value() - 273.15" to fix this bug.
Tags:
Steps To Reproduce:	cd $FOAM_TUTORIALS/heatTransfer/buoyantSimpleFoam/comfortHotRoom foamDictionary -entry internalField -set "uniform 315" 0/T buoyantSimpleFoam -postProcess -time 0
Additional Information:
Attached Files:

Notes
(0012238) henry    2021-10-14 14:38	Resolved in OpenFOAM-9 by commit ae0e09e28d5722c8e437bc346203fa34a877cb94 Resolved in OpenFOAM-dev by commit 45c8a4695a194728c5e2a806289cc5ef222671aa

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3737	[OpenFOAM] Bug	minor	always	2021-10-08 01:07	2021-10-12 12:33
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:	compressibleInterFoam reads fvConstraints for limitTemperature but is not applied
Description:	compressibleInterFoam reads in fvConstraints for limitTemperature but does not seem to apply the constraint. -------------------fvConstraints read in from log---------------------- No fvModels present Creating fvConstraints from "system/fvConstraints" Selecting finite volume constraint type limitTemperature     Name: limitTair     - selecting all cells     - selected 1360 cell(s) with volume 1075 Selecting finite volume constraint type limitTemperature     Name: limitTwater     - selecting all cells     - selected 1360 cell(s) with volume 1075 Courant Number mean: 0 max: 0 Constructing face velocity Uf --------------------Constraint not used from log----------------------- ... --> FOAM Warning :     From function void Foam::fvConstraints::checkApplied() const     in file cfdTools/general/fvConstraints/fvConstraints.C at line 124     Constraint limitTair defined for field e.air but never used --> FOAM Warning :     From function void Foam::fvConstraints::checkApplied() const     in file cfdTools/general/fvConstraints/fvConstraints.C at line 124     Constraint limitTwater defined for field e.water but never used DILUPBiCGStab: Solving for T, Initial residual = 0.276052, Final residual = 3.78243e-14, No Iterations 1 -------------------------------------------------------------------------------
Tags:
Steps To Reproduce:	Add fvConstraints limitTemperature to a compressibleInterFoam tutorial. I did this with sloshingTank2D. Here are the fvConstraints added: ------------------fvConstraints---------------------- limitTair {     type limitTemperature;     selectionMode all;     min 310;     max 500;     phase air; } limitTwater {     type limitTemperature;     selectionMode all;     min 310;     max 500;     phase water; } -------------------- I tried temperatures below and above the temperature of the case but it doesn't seem to matter.
Additional Information:	dev-af3769dc4e89 is my version. This functionality is useful for cases where guesses for T0 are negative. This is not always the best approach to limit temperature, but can be helpful during case start-up. Please let me know if you need more information.
System Description
Attached Files:	log.compressibleInterFoam (99,421 bytes) 2021-10-08 01:07 https://bugs.openfoam.org/file_download.php?file_id=3228&type=bug

Notes
(0012225) henry    2021-10-09 22:26	The current limitTemperature fvConstraint does not work with compressibleInterFoam as this solver is unique in that it solves the mixture temperature equation rather than an energy equation and consequently will need either special treatment in limitTemperature or a special fvConstraint. Would you like to fund the implementation of this new fvConstraint?
(0012226) jfp6    2021-10-09 23:21	Ok, that makes sense now. This must be why the limitTemperature functions correctly for multiphaseEulerFoam. I would consider funding this; we are currently Silver level supporters but I am assuming this would be beyond the scope of that funding. Do you have a rough idea of how many hours would need to be funded to accomplish something like this?
(0012232) henry    2021-10-12 12:33	Resolved by commit fb53b915b2439f67fb88f6d46c671bbd18f70cb6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3735	[OpenFOAM] Bug	text	always	2021-10-05 08:41	2021-10-06 08:27
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:	9
		Target Version:
Summary:	eConstThermo, hConstThermo , minor error in doc
Description:	In both eConstThermo and hConstThermo the documentation says Tref | Reference temperature [K] (defaults to 0) However, in the code Tref defaults to Tstd.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0012211) tniemi    2021-10-06 07:39	To add, actually the units for Cp and Cv are also wrong in the header documentation. They are J/kg/K not J/kmol/K.
(0012212) tniemi    2021-10-06 07:44	And I think the same also applies for h and e powerThermos. I mean the unit for c0 should be J/kg/K
(0012213) henry    2021-10-06 08:27	Resolved in OpenFOAM-9 by commit 8cd2ea29e64f515f29a29a2d6564cbd28b926f69 Resolved in OpenFOAM-dev by commit 4e445a8decc23062c289c036ad53af1c8ef91953

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3734	[OpenFOAM] Bug	minor	random	2021-09-28 16:14	2021-09-30 13:30
Reporter:	jherb	Platform:	amd64
Assigned To:		OS:	Debian
Priority:	none	OS Version:	10
Status:	new	Product Version:	dev
Product Build:		Resolution:	open
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	rhoSimpleFoam running parallel sometimes crashes if configuration files (e.g. fvSolution) is modifed during runtime
Description:	This was tested with OpenFOAM versions 8 and dev (98686ae7604a5603f501893e2e20a8038638ec52). The following compilers were used to compile OpenFOAM: gcc 8.2.0 and 8.3.0, icx (Intel(R) oneAPI DPC++ Compiler 2021.1.2 (2020.10.0.1214)). The operating systems Debian 10 and Centos (centos-linux-release-8.3-1.2011.el8.noarch) were used. On all these systems, rhoSimpleFoam crashes sporadically, if configuration files (e.g. controlDict, fvSolution; ...) are changed during runtime. The crash seems to happen more often if OpenFOAM is compiled in debug configuration, but also happens in the optimized configuration. OpenMPI versions: 2.1.1 and 4.1.0
Tags:
Steps To Reproduce:	E.g source $FOAM_SRC/../etc/bashrc WM_COMPILER=Icx WM_COMPILE_OPTION=Debug Use the tutorial $FOAM_TUTORIALS/compressible/rhoSimpleFoam/squareBend Modify controlDict (probably not necessary): --- /home/jenkins/.jenkins/workspace/of_dev_pipe/OpenFOAM-dev/tutorials/compressible/rhoSimpleFoam/squareBend/system/controlDict 2021-09-23 23:37:05.000000000 +0200 +++ system/controlDict 2021-09-28 16:41:02.101949800 +0200 @@ -46,5 +46,15 @@  runTimeModifiable true; +DebugSwitches +{ + objectRegistry 1; +} + +OptimisationSwitches +{ + fileHandler collated; +} + Start rhoSimpleFoam: mpirun -n 8 rhoSimpleFoam -parallel In a second shell, modify/force re-read of a config file, e.g. by while true; do sleep 0.1 ; touch system/fvSolution ; done The output before/after the crash (Release Version): [3] objectRegistry::readModifiedObjects() : region0 : Considering reading object thermophysicalTransport [7] objectRegistry::readModifiedObjects() : region0 : Considering reading object Cp [7] objectRegistry::readModifiedObjects() : region0 : Considering reading object Residuals<tensor> [7] objectRegistry::readModifiedObjects() : region0 : Considering reading object thermophysicalTransport [0] #0 [0] objectRegistry::readModifiedObjects() : region0 : Considering reading object Foam::error::printStack(Foam::Ostream&) at ??:? [0] #1 Foam::sigSegv::sigHandler(int) at ??:? [0] #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" [0] #3 Foam::OSstream::write(Foam::word const&) at ??:? [0] #4 Foam::operator<<(Foam::Ostream&, Foam::word const&) at ??:? [0] #5 Foam::objectRegistry::readModifiedObjects() at ??:? [0] #6 Foam::objectRegistry::readIfModified() at ??:? [0] #7 Foam::objectRegistry::readModifiedObjects() at ??:? [0] #8 Foam::Time::loop() at ??:? [0] #9 ? in "/home/jenkins/.jenkins/workspace/of_dev_pipe/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/rhoSimpleFoam" [0] #10 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" [0] #11 ? in "/home/jenkins/.jenkins/workspace/of_dev_pipe/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/rhoSimpleFoam" [ciu-linux2019:39857] *** Process received signal *** [ciu-linux2019:39857] Signal: Segmentation fault (11) [ciu-linux2019:39857] Signal code: (-6) [ciu-linux2019:39857] Failing at address: 0x3a9f00009bb1 [ciu-linux2019:39857] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x37840)[0x7fd752d46840] [ciu-linux2019:39857] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7fd752d467bb] [ciu-linux2019:39857] [ 2] /lib/x86_64-linux-gnu/libc.so.6(+0x37840)[0x7fd752d46840] [ciu-linux2019:39857] [ 3] /home/jenkins/.jenkins/workspace/of_dev_pipe/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam8OSstream5writeERKNS_4wordE+0x4)[0x7fd7535f1234] [ciu-linux2019:39857] [ 4] /home/jenkins/.jenkins/workspace/of_dev_pipe/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4FoamlsERNS_7OstreamERKNS_4wordE+0xa)[0x7fd7535d2a8a] [ciu-linux2019:39857] [ 5] /home/jenkins/.jenkins/workspace/of_dev_pipe/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam14objectRegistry19readModifiedObjectsEv+0xa7)[0x7fd753654217] [ciu-linux2019:39857] [ 6] /home/jenkins/.jenkins/workspace/of_dev_pipe/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam14objectRegistry14readIfModifiedEv+0x9)[0x7fd7536542b9] [ciu-linux2019:39857] [ 7] /home/jenkins/.jenkins/workspace/of_dev_pipe/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam14objectRegistry19readModifiedObjectsEv+0x45)[0x7fd7536541b5] [ciu-linux2019:39857] [ 8] /home/jenkins/.jenkins/workspace/of_dev_pipe/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam4Time4loopEv+0xdd)[0x7fd753682a7d] [ciu-linux2019:39857] [ 9] rhoSimpleFoam(+0x2da13)[0x564d1c40ea13] [ciu-linux2019:39857] [10] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7fd752d3309b] [ciu-linux2019:39857] [11] rhoSimpleFoam(+0x3038a)[0x564d1c41138a] [ciu-linux2019:39857] *** End of error message *** -------------------------------------------------------------------------- mpirun noticed that process rank 0 with PID 0 on node ciu-linux2019 exited on signal 11 (Segmentation fault). -------------------------------------------------------------------------- The output for a debug build (without objectRegistry debug output): regIOobject::readIfModified() :     Re-reading object fvSolution from file "/GRS/sys/data/user/hej/OpenFOAM/hej-dev/run/squareBend/system/fvSolution" [0] #0 Foam::error::printStack(Foam::Ostream&) at /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/src/OSspecific/POSIX/printStack.C:218 [0] #1 Foam::sigSegv::sigHandler(int) at /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/src/OSspecific/POSIX/signals/sigSegv.C:54 [0] #2 ? in "/lib64/libc.so.6" [0] #3 Foam::objectRegistry::readModifiedObjects() at /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/db/objectRegistry/objectRegistry.C:516 [0] #4 Foam::objectRegistry::readIfModified() at /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/db/objectRegistry/objectRegistry.C:524 [0] #5 Foam::objectRegistry::readModifiedObjects() at /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/db/objectRegistry/objectRegistry.C:507 [0] #6 Foam::Time::readModifiedObjects() at /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/db/Time/TimeIO.C:247 [0] #7 Foam::Time::run() const at /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/db/Time/Time.C:838 [0] #8 Foam::Time::loop() at /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/db/Time/Time.C:865 [0] #9 Foam::simpleControl::loop(Foam::Time&) at /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/src/finiteVolume/cfdTools/general/solutionControl/simpleControl/simpleControl.C:87 [0] #10 ? at /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/applications/solvers/compressible/rhoSimpleFoam/rhoSimpleFoam.C:61 [0] #11 __libc_start_main in "/lib64/libc.so.6" [0] #12 ? at ??:? [manitu1:3732249] *** Process received signal *** [manitu1:3732249] Signal: Segmentation fault (11) [manitu1:3732249] Signal code: (-6) [manitu1:3732249] Failing at address: 0x36e00038f319 [manitu1:3732249] [ 0] /lib64/libc.so.6(+0x37880)[0x7f536e283880] [manitu1:3732249] [ 1] /lib64/libc.so.6(gsignal+0x10f)[0x7f536e2837ff] [manitu1:3732249] [ 2] /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/platforms/linux64IcxDPInt32Debug/lib/libOpenFOAM.so(_ZN4Foam7sigSegv10sigHandlerEi+0xb6)[0x7f53700e3c36] [manitu1:3732249] [ 3] /lib64/libc.so.6(+0x37880)[0x7f536e283880] [manitu1:3732249] [ 4] /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/platforms/linux64IcxDPInt32Debug/lib/libOpenFOAM.so(_ZN4Foam14objectRegistry19readModifiedObjectsEv+0xd6)[0x7f536fe165a6] [manitu1:3732249] [ 5] /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/platforms/linux64IcxDPInt32Debug/lib/libOpenFOAM.so(_ZN4Foam14objectRegistry14readIfModifiedEv+0x15)[0x7f536fe165e5] [manitu1:3732249] [ 6] /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/platforms/linux64IcxDPInt32Debug/lib/libOpenFOAM.so(_ZN4Foam14objectRegistry19readModifiedObjectsEv+0xe2)[0x7f536fe165b2] [manitu1:3732249] [ 7] /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/platforms/linux64IcxDPInt32Debug/lib/libOpenFOAM.so(_ZN4Foam4Time19readModifiedObjectsEv+0x107)[0x7f536fe41f77] [manitu1:3732249] [ 8] /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/platforms/linux64IcxDPInt32Debug/lib/libOpenFOAM.so(_ZNK4Foam4Time3runEv+0xd5)[0x7f536fe3da95] [manitu1:3732249] [ 9] /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/platforms/linux64IcxDPInt32Debug/lib/libOpenFOAM.so(_ZN4Foam4Time4loopEv+0x20)[0x7f536fe3db50] [manitu1:3732249] [10] /GRS/sys/work/user/hej/OpenFOAM/OpenFOAM-dev/platforms/linux64IcxDPInt32Debug/lib/libfiniteVolume.so(_ZN4Foam13simpleControl4loopERNS_4TimeE+0x5f)[0x7f5372c5df9f] [manitu1:3732249] [11] rhoSimpleFoam[0x459b0b] [manitu1:3732249] [12] /lib64/libc.so.6(__libc_start_main+0xf3)[0x7f536e26f7b3] [manitu1:3732249] [13] rhoSimpleFoam[0x4563de] [manitu1:3732249] *** End of error message *** -------------------------------------------------------------------------- Primary job terminated normally, but 1 process returned a non-zero exit code. Per user-direction, the job has been aborted. -------------------------------------------------------------------------- -------------------------------------------------------------------------- mpirun noticed that process rank 0 with PID 0 on node manitu1 exited on signal 11 (Segmentation fault). --------------------------------------------------------------------------
Additional Information:
System Description
Attached Files:

Notes
(0012204) henry    2021-09-28 16:21	I am unable to reproduce this behaviour.
(0012205) jherb    2021-09-28 16:37	Which versions (OpenFOAM, compiler, MPI) are you using? Which configuration? In non-parallel mode it looks like the crash is not happening.
(0012206) henry    2021-09-28 16:45	OpenFOAM-dev, gcc-10.1.1, OpenMPI-2.1.1
(0012207) jherb    2021-09-28 17:28	Sorry, but there seems to be no official gcc-10.1.1: https://ftp.gnu.org/gnu/gcc/ Only gcc-10.1.0 Is this a distrubtion specific compiler? Which distribution are you using?
(0012208) henry    2021-09-28 17:39    (Last edited: 2021-09-28 17:40)	OpenSuSE Tumbleweed gcc --version gcc (SUSE Linux) 10.1.1 20200507 [revision dd38686d9c810cecbaa80bb82ed91caaa58ad635] Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(0012209) jherb    2021-09-28 22:01	I was able to reproduce this error on a AWS EC2 instance (t3.micro), using the official ubuntu/images/hvm-ssd/ubuntu-hirsute-21.04-amd64-server-20210928-9b889f11-a864-4343-9340-1b2042b8cd6c AMI and a fresh installation of OpenFOAM 9 following this instructions: https://openfoam.org/download/9-ubuntu/ Time = 9 GAMG: Solving for Ux, Initial residual = 0.02368, Final residual = 0.0012146, No Iterations 1 GAMG: Solving for Uy, Initial residual = 0.0320432, Final residual = 0.00210963, No Iterations 1 GAMG: Solving for Uz, Initial residual = 0.384409, Final residual = 0.0177306, No Iterations 1 GAMG: Solving for e, Initial residual = 0.180589, Final residual = 0.00958168, No Iterations 1 GAMG: Solving for p, Initial residual = 0.0857398, Final residual = 0.00562322, No Iterations 3 time step continuity errors : sum local = 108.246, global = -52.7635, cumulative = -750.706 GAMG: Solving for epsilon, Initial residual = 0.0271821, Final residual = 0.00177123, No Iterations 1 GAMG: Solving for k, Initial residual = 0.0710536, Final residual = 0.00435529, No Iterations 1 ExecutionTime = 12.27 s ClockTime = 13 s regIOobject::readIfModified() :     Re-reading object fvSolution from file "/home/ubuntu/OpenFOAM/ubuntu-9/run/squareBend/system/fvSolution" [0] #0 Foam::error::printStack(Foam::Ostream&) at ??:? [0] #1 Foam::sigSegv::sigHandler(int) at ??:? [0] #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" [0] #3 Foam::objectRegistry::readModifiedObjects() at ??:? [0] #4 Foam::objectRegistry::readIfModified() at ??:? [0] #5 Foam::objectRegistry::readModifiedObjects() at ??:? [0] #6 Foam::Time::loop() at ??:? [0] #7 ? in "/opt/openfoam9/platforms/linux64GccDPInt32Opt/bin/rhoSimpleFoam" [0] #8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" [0] #9 ? in "/opt/openfoam9/platforms/linux64GccDPInt32Opt/bin/rhoSimpleFoam" -------------------------------------------------------------------------- Primary job terminated normally, but 1 process returned a non-zero exit code. Per user-direction, the job has been aborted. -------------------------------------------------------------------------- -------------------------------------------------------------------------- mpirun noticed that process rank 0 with PID 0 on node ip-172-31-14-153 exited on signal 11 (Segmentation fault). These are the changes, I applied to the squareBend tutorial: /opt/openfoam9/tutorials/compressible/rhoSimpleFoam$ diff -uBbwr squareBend $FOAM_RUN/squareBend diff -uBbwr squareBend/system/blockMeshDict /home/ubuntu/OpenFOAM/ubuntu-9/run/squareBend/system/blockMeshDict --- squareBend/system/blockMeshDict 2021-09-03 07:57:04.000000000 +0000 +++ /home/ubuntu/OpenFOAM/ubuntu-9/run/squareBend/system/blockMeshDict 2021-09-28 20:53:36.842827919 +0000 @@ -50,7 +50,7 @@  blocks  (      hex (0 1 11 10 2 3 13 12) inlet ( 20 20 20) simpleGrading (1 1 1) - hex (4 5 15 14 6 7 17 16) outlet (200 20 20) simpleGrading (1 1 1) + hex (4 5 15 14 6 7 17 16) outlet (800 20 20) simpleGrading (1 1 1)      hex (1 8 18 11 3 9 19 13) bend1 ( 30 20 20) simpleGrading (1 1 1)      hex (5 9 19 15 7 8 18 17) bend2 ( 30 20 20) simpleGrading (1 1 1) diff -uBbwr squareBend/system/controlDict /home/ubuntu/OpenFOAM/ubuntu-9/run/squareBend/system/controlDict --- squareBend/system/controlDict 2021-09-03 07:57:04.000000000 +0000 +++ /home/ubuntu/OpenFOAM/ubuntu-9/run/squareBend/system/controlDict 2021-09-28 20:54:33.082838092 +0000 @@ -46,5 +46,10 @@  runTimeModifiable true; +OptimisationSwitches +{ + fileHandler collated; +} +  // ************************************************************************* // diff -uBbwr squareBend/system/decomposeParDict /home/ubuntu/OpenFOAM/ubuntu-9/run/squareBend/system/decomposeParDict --- squareBend/system/decomposeParDict 2021-09-03 07:57:04.000000000 +0000 +++ /home/ubuntu/OpenFOAM/ubuntu-9/run/squareBend/system/decomposeParDict 2021-09-28 20:50:14.266791212 +0000 @@ -14,13 +14,13 @@  }  // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // -numberOfSubdomains 8; +numberOfSubdomains 2; -method hierarchical; +method simple;  simpleCoeffs  { - n (8 1 1); + n (2 1 1);  }  hierarchicalCoeffs Here is the full bash history starting from the fresh AMI:     1 sudo sh -c "wget -O - https://dl.openfoam.org/gpg.key | apt-key add -"     2 sudo add-apt-repository http://dl.openfoam.org/ubuntu     3 sudo apt-get update     4 sudo apt-get -y install openfoam9     5 source /opt/openfoam9/etc/bashrc     6 mkdir -p $FOAM_RUN     7 run     8 cp -r $FOAM_TUTORIALS/compressible/rhoSimpleFoam/squareBand .     9 tut    10 cd compressible/rhoSimpleFoam/    11 cp -r squareBend $FOAM_RUN/    12 run    13 cd squareBend/    14 blockMesh    15 vim system/decomposeParDict    16 decomposePar    17 vim system/decomposeParDict    18 decomposePar    19 mpirun -n 2 rhoSimpleFoam -parallel    20 mpirun -n 2 --host localhost:2 rhoSimpleFoam -parallel    21 vim system/blockMeshDict    22 blockMesh    23 rm -rf processor*    24 vim system/controlDict    25 l    26 decomposePar    27 mpirun -n 2 --host localhost:2 rhoSimpleFoam -parallel    28 ls    29 rm -rf processors2/ constant/polyMesh/    30 ls    31 tut    32 cd compressible/rhoSimpleFoam/    33 diff -uBbwr squareBend $FOAM_RUN/squareBend    34 history And this is the command in the second ssh shell: while true ; do sleep 0.1 ; touch system/fvSolution ; echo -n '.' ; done
(0012210) henry    2021-09-30 13:29	I am unable to reproduce this problem. Could you analyse it and propose a patch to fix the issue you see? Alternatively we would need funding to work on it further for you.

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3733	[OpenFOAM] Bug	minor	always	2021-09-20 13:50	2021-09-20 19:16
Reporter:	hussam	Platform:	GNU/Linux
Assigned To:	henry	OS:	CentOS
Priority:	normal	OS Version:
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	transport model can't be turned on/off on the fly
Description:	While running a simulation, the turbulence/transport model can't be turned on/off on the fly. Usually this should be done by changing the value of "turbulence" in momentumTransport/turbulenceProperties file. this behaviour was obsereved for (kOmegaSST, kEpsilon)
Tags:
Steps To Reproduce:	Any tutorial with turbulence modeling (at least RAS). I've observed this at least for: -OpenFOAM-dev/tutorials/heatTransfer/chtMultiRegionFoam/reverseBurner -OpenFOAM-dev/tutorials/incompressible/simpleFoam/motorBike
Additional Information:
Attached Files:

Notes
(0012200) henry    2021-09-20 14:22	> While running a simulation, the turbulence/transport model can't be turned on/off on the fly. Correct, we have never attempted to support this and it has not been requested before.
(0012201) hussam    2021-09-20 17:52	Using commit d7133914fc13f1006fc95079580503eb3e221cf0 solves the problem. Thanks!
(0012202) henry    2021-09-20 19:16	Resolved in OpenFOAM-9 by commit 055b575f99f01579d4e1dc4b69de79a083aa765e Resolved in OpenFOAM-dev by commit d7133914fc13f1006fc95079580503eb3e221cf0

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3728	[OpenFOAM] Bug	major	always	2021-09-15 22:25	2021-09-16 21:54
Reporter:	hussam	Platform:	GNU/Linux
Assigned To:	henry	OS:	Ubuntu
Priority:	high	OS Version:	15.04
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	If multiple meanVelocityForce entries are specified in cellZones only the first entry will be considered..
Description:	if there are multiple entries of type meanVelocityForce on different cellZones within a region, only the first entry will be handled. All further entries will be neglected, at least according to the log file.
Tags:
Steps To Reproduce:	Use the tutorial channel395 and replace fvConstraints and controlDict with the files in attachments. Additionally use attached topoSetDict to create the cellZones. for automated workflow you can use the attached Allrun and Allclean. By checking log.pimpleFoam it turned out the only first entry will be considered:   .. smoothSolver: Solving for Uz, Initial residual = 0.760481, Final residual = 8.02892e-06, No Iterations 4 Pressure gradient source: uncorrected Ubar = 0.177755, pressure gradient = 0.514522 GAMG: Solving for p, Initial residual = 0.181495, Final residual = 0.00635363, No Iterations 3 ..
Additional Information:	the problem occured by openfoam 9 and openfoam dev. Same problem does not appear for openfoam 7 or openfoam 8. same output using openfoam 8 : .. smoothSolver: Solving for Uz, Initial residual = 0.0589522, Final residual = 9.65879e-06, No Iterations 3 Pressure gradient source: uncorrected Ubar = 0.13368, pressure gradient = 0.336155 Pressure gradient source: uncorrected Ubar = 0.133691, pressure gradient = -0.000968907 GAMG: Solving for p, Initial residual = 0.657319, Final residual = 0.0327464, No Iterations 2 ..
System Description
Attached Files:	topoSetDict (1,175 bytes) 2021-09-15 22:25 https://bugs.openfoam.org/file_download.php?file_id=3221&type=bug controlDict (1,040 bytes) 2021-09-15 22:25 https://bugs.openfoam.org/file_download.php?file_id=3222&type=bug fvConstraints (965 bytes) 2021-09-15 22:25 https://bugs.openfoam.org/file_download.php?file_id=3223&type=bug Allrun (368 bytes) 2021-09-15 22:25 https://bugs.openfoam.org/file_download.php?file_id=3224&type=bug Allclean (177 bytes) 2021-09-15 22:25 https://bugs.openfoam.org/file_download.php?file_id=3225&type=bug

Notes
(0012192) tniemi    2021-09-16 19:45	It seems that in fvConstraintsTemplates.C, there is a check constrained =                 constrained || constraint.constrain(field); in both eqn and field constrain-functions. If constrained is true, the "constraint.constrain(field)" is never evaluated. The first U-constraint sets constrained to true for field U and then the second call to constrain the same field will not be evaluated.
(0012193) henry    2021-09-16 21:54	Thanks for investigating Timo Resolved in OpenFOAM-9 by commit f8d11b03103d5472d856c91903c230c1e7f07848 Resolved in OpenFOAM-dev by commit 102149135e74805e24ed144217a8fdb75752bb90

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3727	[OpenFOAM] Bug	minor	always	2021-09-14 08:17	2021-09-14 09:29
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:
		Target Version:
Summary:	meshtools/coordinateSystem: Missing copy constructor preventing reuse of coordinateSystems
Description:	I tried to use the constant/coordinateSystem-file to specify a single, simple coordinate system which was used in multiple porous regions. However, I noticed that this only worked for the first porous region and when the second one is created one gets --> FOAM FATAL ERROR: object of type N4Foam18coordinateRotationE is not allocated I traced the issue to coordinateSystem-class, which has R_ as autoPtr but does not have a custom copy constructor. Thus when calling the clone-function, the default copy constructor is used which transfers the ownership of R_ and clears the original pointer. The next clone will produce a coordinateSystem with null R_. Adding coordinateSystem(const coordinateSystem &obj) :         name_(obj.name_),         origin_(obj.origin_),         R_(obj.R_->clone())         {} seemed to solve the issue.
Tags:
Steps To Reproduce:	With tutorials/incompressible/pisoFoam/laminar/porousBlockage try to define another porosity source which uses "coordinateSystem porousBlockage;" leads to --> FOAM FATAL ERROR: object of type N4Foam18coordinateRotationE is not allocated
Additional Information:
Attached Files:

Notes
(0012186) henry    2021-09-14 09:02	Thanks for the report, I am working on this now. coordinateSystem will need an operator= as well as the copy constructor
(0012187) henry    2021-09-14 09:29	Resolved by commit 3e157225676659a40589446f927e2eeed39c4e16

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3724	[OpenFOAM] Bug	minor	always	2021-09-01 21:34	2021-09-03 19:36
Reporter:	peksa	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:
		Target Version:
Summary:	IOobject construction may hang
Description:	Dear developers, The following issue description is directly related to my earlier issue on mapFieldsPar hanging (0003722), in which I hastily proposed a solution that seemed to fix a symptom but not the fundamental reason. After using the recent mapFieldsPar resolution in commit 458e9281e163a355f724ee82cc6a4ec89fb6a65d I noticed that it actually failed to find the right sourceTime instance in parallel case, i.e. the time instance is not looked from the processor directories but only from the main case. My earlier test didn't yield this undesired behavior. This drove me to look into the original implementation and quite quickly I found out that the initial undesired hanging behavior is rising when constructing a Time object. In order to investigate whether this is a general issue in object reconstruction, I have modified the test utility Test-IOField.C for you to reproduce the issue. Actually, Test-IOField is not functional at the moment because it includes IOobject::objectPath(bool) functions without the boolean argument. After fixing this issue (see script) one can compile it and build an example to reproduce the IO hanging. When running the example in parallel, it should hang while reading one of the io objects. I debugged the issue deeper into code and here it appears while IOField object is constructed, and when the headerOk() function is called, which further inquires filePath() function from regIOobject and even further from the IOobject classes. IOobject::filePath seems to be the source of problems here. Furthermore, I did similar debugging for the initial mapFieldsPar problem and the hanging happened in the same place. I haven't been able to come up with a solution yet but wanted to report my findings here. Let me know if you need some extra information.
Tags:
Steps To Reproduce:	Run the attached shell script which compiles Test-IOField.C and tries to run an example case with it in parallel. Run should hang and not complete.
Additional Information:
System Description
Attached Files:	buildIOCase.sh (610 bytes) 2021-09-01 21:34 https://bugs.openfoam.org/file_download.php?file_id=3219&type=bug buildMapFieldsParDebugCase.sh (1,774 bytes) 2021-09-02 19:22 https://bugs.openfoam.org/file_download.php?file_id=3220&type=bug

Notes
(0012177) henry    2021-09-01 21:46	mapFieldsPar is basically broken in several ways which is why I reinstated mapFields. It would make sense to avoid using mapFieldsPar until we can secure funding to rewrite it.
(0012178) peksa    2021-09-02 06:25	I agree with you in terms of mapFieldsPar. I wonder if other parallel utilities may be influenced by this issue as well.
(0012179) henry    2021-09-02 07:57	I have updated Test-IOField: commit 3554f2140e4dbcd547b39867c7e4760bbb8377e2 (HEAD -> master, origin/master, origin/HEAD) Author: Henry Weller <http://cfd.direct> Date: Thu Sep 2 07:55:49 2021 +0100     Test-IOField: Updated and improved to use typeIOobject We are not aware of any other parallel utilities which do not work correctly, do you know of any?
(0012180) peksa    2021-09-02 18:39	Hey thanks for pointing out the correct usage of typeIOobject in this context. Now the test is executed succesfully. I have tried to understand why the initial mapFieldsPar createTimes.H implementation lead to the hanging behaviour but I have not been able to reproduce the IOobject induced issue outside of that case yet. In addition, I tested some other parallel utilities having similar features and they all worked correctly as expected.
(0012181) peksa    2021-09-02 19:22	Ok, I literally by a mistake got the initial mapFieldsPar working by changing the "startFrom" entry to "latestTime" instead of "startTime". So if you revert to commit d002a4de500c96542d89160d7539e03ed9f1eef4 (before the latest mapFieldsPar fix) and run again the attached shell script which again does parallel mapping between cavity cases but now with latestTime entry instead of startTime=0. I have no idea why this works but what I quickly see is that Time object initiation has setControl() and setTime() functions which depend on the setting. The fix I proposed earlier has an issue that it cannot read the time values under processor folders while the older implementation with this entry change does things correctly. Weird but as you said, there are other problems as well...
(0012182) henry    2021-09-02 19:47	Try this: commit e6fdd180e8dc73e6914073908f159e58d622bd1d (HEAD -> master, origin/master, origin/HEAD) Author: Henry Weller <http://cfd.direct> Date: Thu Sep 2 19:45:14 2021 +0100     mapFieldsPar: Corrected handling of argList and reverted change to createTimes.H
(0012183) peksa    2021-09-03 06:29	Tested the commit and everything seems to work now. Thanks!

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3722	[OpenFOAM] Bug	minor	always	2021-08-29 16:29	2021-08-30 10:36
Reporter:	peksa	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:	9
		Target Version:
Summary:	mapFieldsPar hangs due to issue at createTimes.H
Description:	Dear developers, I have noticed that sometimes when executing the mapFieldsPar utility in parallel, it hangs before the actual interpolation operation starts. I have attached a simple test case which I have built with the OpenFOAM-dev (7b7fa5a9af93d3a8a733f3cbda72b3daf03cf3ce). The problem seems to arise at createTimes.H on line 9 where the runTimeSource Time object is created. I tested to change the definition such that instead of using the argument list, I build the Time object as "Time runTimeSource(Time::controlDictName, rootDirSource, caseDirSource);" which seemed to cure the issue (similar to the serial mapFields counter part). Hence, as a fix I propose to change the createTimes.H implementation similar to mapFields serial version.
Tags:
Steps To Reproduce:	Run the attached shell script in any directory. The script copies the cavity case, runs it and tries to map it in parallel onto another copied case.
Additional Information:
System Description
Attached Files:	buildMapFieldsParDebugCase.sh (1,585 bytes) 2021-08-29 16:29 https://bugs.openfoam.org/file_download.php?file_id=3216&type=bug

Notes
(0012175) henry    2021-08-30 10:36	Thanks for the detailed report, steps to reproduce and proposed fix. Resolved in OpenFOAM-9 by commit 458e9281e163a355f724ee82cc6a4ec89fb6a65d Resolved in OpenFOAM-dev by commit e6d7b7aa3f71cd28affe62d947091ce92f1b0025

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3719	[OpenFOAM] Bug	minor	always	2021-08-25 14:05	2021-08-26 11:23
Reporter:	evamaria	Platform:	Unix
Assigned To:	will	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	Composition properties missing
Description:	The particleTracks cloudFunction does not write composition properties, which was done in the previous version (8) and seems to be relevant for reactingMultiphaseClouds. This problem occurs in the $FOAM_TUTORIALS/combustion/reactingFoam/Lagrangian/verticalChannelSteady/. When the Allrun script is used for simulation only the properties (active, age, Cp, d, dTarget, nParticle, origId, origProcId, positions, rho, T, tTurb, typeId, U, Uturb) are written to Time/lagrangian/cloudTracks and f.ex. YH2O(l) is missing.
Tags:
Steps To Reproduce:	Copy $FOAM_TUTORIALS/combustion/reactingFoam/Lagrangian/verticalChannelSteady/ case. Use Allrun. Check folder 500/lagrangian/cloudTracks/ .
Additional Information:
System Description
Attached Files:

Notes
(0012167) will    2021-08-26 11:23	Thanks for the report. Fixed in version 9 and in dev. https://github.com/OpenFOAM/OpenFOAM-9/commit/87b67d07a01da974efebf39954d9ad7583fa7556 https://github.com/OpenFOAM/OpenFOAM-dev/commit/e52567a4cfaf1f8d95b3b6877b7c96565d1d4c91

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3717	[OpenFOAM] Patch	minor	always	2021-08-24 17:50	2021-08-25 12:02
Reporter:	mboesi	Platform:	Unix
Assigned To:	henry	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	Dynamic compilation of TDACChemistryModel fails
Description:	The running the TDACChemistryModel fails when using thermo-physics not pre-defined in the chemistryModel. The issue is related to a missing symbol. I've checked the problem and found out that the pre-processor instruction in the basicChemistryModelTemplate.C has a typo and, therefore, the standardChemistryModel and the chemistryReduction- and chemistryTabulationMethods are not compiled. The instruction reads: "#if ${method}CppTest == TDACChemistryModelCppTest" but should be "#if ${method}ChemistryModelCppTest == TDACChemistryModelCppTest". I've attached a corrected version of the file and a test case based on the DLR_A_LTS case.
Tags:
Steps To Reproduce:	Select a non
Additional Information:
System Description
Attached Files:	DLR_A_LTSTest.tar.xz (21,916 bytes) 2021-08-24 17:50 https://bugs.openfoam.org/file_download.php?file_id=3210&type=bug basicChemistryModelTemplate.C (6,148 bytes) 2021-08-24 17:50 https://bugs.openfoam.org/file_download.php?file_id=3211&type=bug

Notes
(0012163) henry    2021-08-25 11:25	I can't reproduce the problem with the case you have provided, I get a string of errors from the thermo relating to incorrect input: [0] [0] [0] --> FOAM FATAL IO ERROR: [0] keyword muCoeffs<8> is undefined in dictionary "/home/dm2/henry/Downloads/DLR_A_LTSTest/constant/thermophysicalProperties/H2/transport" [0] [0] file: /home/dm2/henry/Downloads/DLR_A_LTSTest/constant/thermophysicalProperties/H2/transport from line 809 to line 810. [0] [0] From function const Foam::entry& Foam::dictionary::lookupEntry(const Foam::word&, bool, bool) const [0] in file db/dictionary/dictionary.C at line 811. . . .
(0012165) henry    2021-08-25 12:02	Resolved in OpenFOAM-9 by commit 7b57b4747f7583bad0fed179581a191f542709e4 Resolved in OpenFOAM-dev by commit 9b8aa48a7ed3d1f5e9f61c83c41d8b0e828a6af8

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3716	[OpenFOAM] Bug	minor	sometimes	2021-08-24 16:59	2021-08-25 11:56
Reporter:	tniemi	Platform:
Assigned To:	will	OS:
Priority:	low	OS Version:
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Segmentation fault instead of proper IO ERROR
Description:	I noticed that in recent dev versions I'm getting segmentation faults from places which normally should produce meaningful error messages. I managed to pinpoint the issue to this commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/4398f57c5e88f21b78d5d7edf66f733a8d13ad8f
Tags:
Steps To Reproduce:	For example, if I take tutorials/combustion/reactingFoam/Lagrangian/verticalChannel and change "operation average;" to "operation averaged;", in OF9 I get --> FOAM FATAL IO ERROR: averaged is not in enumeration: 16 ( CoV areaAverage areaIntegrate areaNormalAverage areaNormalIntegrate average max maxMag min minMag none orientedSum sum sumDirection sumDirectionBalance sumMag ) However, currently in dev I only get --> FOAM FATAL IO ERROR: #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigSegv::sigHandler(int) at ??:? #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" #3 ? in "/lib/x86_64-linux-gnu/libc.so.6" Segmentation fault (core dumped) or --> FOAM FATAL IO ERROR: #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigSegv::sigHandler(int) at ??:? #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" #3 Foam::error::message() const at ??:? #4 Foam::operator<<(Foam::Ostream&, Foam::IOerror const&) at ??:? #5 ? at functionObjectList.C:? #6 Foam::functionObjectList::timeToNextWrite() at ??:? #7 Foam::Time::adjustDeltaT() at ??:? #8 ? in "/opt/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/reactingFoam" #9 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #10 ? in "/opt/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/reactingFoam" Segmentation fault (core dumped)
Additional Information:
Attached Files:

Notes
(0012161) tniemi    2021-08-24 17:24	"operation average;" refers to surfaceFieldValue in controlDict
(0012162) tniemi    2021-08-25 06:19	Restoring the removed "error(const error&)" copy constructor seems to help with the issue.
(0012164) will    2021-08-25 11:56	Yes, the pointer handling of the error class' string-stream got messed up. I don't see any reason for the string-stream being a pointer, so I've now made it an actual object. Even simpler. No copy constructors, no destructors. https://github.com/OpenFOAM/OpenFOAM-dev/commit/32cfad7002c2b677114adadff76fdcf295533f80

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3712	[OpenFOAM] Bug	minor	sometimes	2021-08-13 22:25	2021-08-18 14:41
Reporter:	peksa	Platform:	Linux
Assigned To:	will	OS:	Centos
Priority:	normal	OS Version:	7
Status:	resolved	Product Version:	dev
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	dev
		Target Version:
Summary:	Infinite loop in lagrangian move function due to stuck parcels
Description:	I have experienced that sometimes my lagrangian spray simulations (reactingFoam / old sprayFoam) hang during the lagrangian computation step. In particular, this seems to take place when Foam::particle::trackToFace() function yields a warning ""Particle #" << origId_ << " got stuck at " << position()". Typically this kind of stuck parcel near the domain boundary tells that your simulation may have other issues but I believe the solver should not result in an infinite loop behavior but at least result in an error after some time of unsuccesfull iteration. To shed some more light on the topic, I utilised recent OpenFOAM-dev (git-rev 41b73ec5788a29f4d1928482c635db6cbe7d8dfe) to debug and present this issue by building a simple spray case (see link below). The case is not the "most proper" from CFD quality stand point in terms ofmesh, injector is close to the boundary and flow solver / numerics setup is just exemplary. The objective is to just achieve a reproducible example. This example case results in a hanging situation after a few time steps. I have debugged this to make a conclusion that there is no break-up in the while loop of the Foam::MomentumParcel<ParcelType>::move() function because p.stepFactor() yields a constant number below unity. stepFactor is not achieving unity due to a stucking parcel indicated by the p.trackToFace() function, which also updates the stepFactor. To me this is not a bug per'se because it appears probably only due to an ill-conditioned CFD setup. However, I'd like to propose that we could add a maximum number of iteration to the while loop (e.g. 10000) after which an error is introduced and solver exits properly.
Tags:
Steps To Reproduce:	Download a ready case (~100MB with an existing time step data for a restart to minimize run-time) https://1drv.ms/u/s!AnmySzLmJFhRgohF-qySTppCRcWEzA?e=6JJmoc Extract the spray_hanging_issue_tracker.tar.gz run by executing "reactingFoam" (will start from the latest time folder which is included). Lagrangian solver "hangs" in few time steps.
Additional Information:
System Description
Attached Files:

Notes
(0012160) will    2021-08-18 14:41	I agree that it would be better to exit with an error than to hang. The problem with counters is that for them to work properly, they have to be stored as data on the particle. Otherwise any infinite loop situation which crosses a processor boundary won't be broken, as the counter will be reset on each crossing. Adding particle data has a performance penalty. Is it worth making correct cases less efficient in order to improve the failure modes of incorrect cases? Also, the number is completely arbitrary. You suggest 10000, but if we are doing steady tracking or creating long streamlines, is that enough? If not, what is? So, no, I don't see a convincing argument for adding a counter. What I can do is catch the failure modes demonstrated in this case so that they error, rather than hang. This case fails for two reasons... Firstly, because a parcel hits a wall for which no patch interaction has been specified. This is not valid. I have added a error to stop the code if this situation is detected. Secondly, if I add a rebound interaction, the case fails because it is diverging. The velocity increases to 10^15-ish, and the CFL limiter then sets a step fraction which is below round off error. As such, the particle never evolves. I have limited the CFL limiter so that this does not happen. Now in your case, Lagrangian spits a lot of "stuck" warnings, but completes without failure, and it is the subsequent finite volume solution that then fails. With these changes I consider the issue demonstrated by your case to be resolved. https://github.com/OpenFOAM/OpenFOAM-dev/commit/08d6791d81d4ab7d7b54933006417cf52f9e1558

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3715	[OpenFOAM] Bug	trivial	always	2021-08-17 08:41	2021-08-17 08:52
Reporter:	tniemi	Platform:
Assigned To:	henry	OS:
Priority:	normal	OS Version:
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Debug flag in mapFields
Description:	In mapFields/Make/options (https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/applications/utilities/preProcessing/mapFields/Make/options), there is a -ggdb3 debug flag which probably should not be there.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:

Notes
(0012158) henry    2021-08-17 08:52	Resolved by commit 4d97c3046946d9e9ecc18ec115af563c6a5794d6

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3711	[OpenFOAM] Bug	minor	always	2021-08-13 19:53	2021-08-16 11:26
Reporter:	jheylmun	Platform:	GNU/Linux
Assigned To:	henry	OS:	Other
Priority:	normal	OS Version:	(please specify)
Status:	resolved	Product Version:	9
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	9
		Target Version:
Summary:	heheuPsiThermo does not update Cp and Cv
Description:	the heheuPsiThermo does not update Cp and Cv values which results is 0 for both fields since they are only calculated in the correct function
Tags:
Steps To Reproduce:	add functions {     CpCv     {         type writeObjects;         libs ("libutilityFunctionObjects.so");         objects (Cp Cv);     } } to OpenFOAM-9/tutorials/combustion/XiFoam/RAS/moriyoshiHomogeneous//controlDict and run case
Additional Information:
System Description
Attached Files:

Notes
(0012150) henry    2021-08-16 11:26	Thanks for the bug-report Resolved in OpenFOAM-9 by commit 0a36666bfadb6595330b575b3a5747cbe631cfdb Resolved in OpenFOAM-dev by 64e94cfa6654dcb7dd0f8f89954040c13adc231a

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3650	[OpenFOAM] Bug	minor	always	2021-03-29 22:47	2021-07-13 15:28
Reporter:	jherb	Platform:	GNU/Linux
Assigned To:	chris	OS:	OpenSuSE
Priority:	normal	OS Version:	12.3
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Documentation on website for csv files has not been updated
Description:	The documentation about using of csv files in boundary conditions has not been updated. For OpenFOAM 8 at https://cfd.direct/openfoam/user-guide/v8-boundaries/#x25-1770005.2 it is still given: inlet {     type uniformFixedValue;     uniformValue     {         type csvFile;         nHeaderLine 4; // number of header lines         refColumn 0; // time column index         componentColumns (1); // data column index         separator ","; // optional (defaults to ",")         mergeSeparators no; // merge multiple separators         file "dataTable.csv";    } } This should probably read like: inlet {     type uniformFixedValue;     uniformValue     {         type tableFile;         format csv;         nHeaderLine 4; // number of header lines         refColumn 0; // time column index         componentColumns (1); // data column index         separator ","; // optional (defaults to ",")         mergeSeparators no; // merge multiple separators         file "dataTable.csv";    } }
Tags:
Steps To Reproduce:
Additional Information:	See also https://github.com/OpenFOAM/OpenFOAM-dev/commit/7ab73932cf5b791f09001fb07ad8ce385e70234f
System Description
Attached Files:

Notes
(0012001) henry    2021-04-19 12:49	Correct, the OpenFOAM-8 online documentation has not been updated yet, would you like to contribute to OpenFOAM maintenance for this kind of work? See https://openfoam.org/news/funding-2021/ If not you can access the latest docs from your installation using foamInfo function1 or you could generate the latest Doxygen documentation yourself.
(0012012) chris    2021-05-01 12:48	The update has been processed. It should appear in 24 hours on the website, once page caching expires https://cfd.direct/openfoam/user-guide/v8-boundaries/

Powered by MantisBT
Copyright © 2000 - 2024 MantisBT Team
Contact administrator for assistance

View Issue Details
ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
99	[OpenFOAM] Bug	feature	N/A	2010-12-05 21:24	2021-07-13 15:27
Reporter:	albertop	Platform:	Linux
Assigned To:	henry	OS:	OpenSuse
Priority:	normal	OS Version:	11.3
Status:	resolved	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:
		Target Version:
Summary:	Dynamic Smagorinsky model with local coefficient values
Description:	The current implementation of the dynamic Smagorinsky model in OpenFOAM uses a domain-averaged coefficient to compute the SGS stress tensor. This is not appropriate, since it removes the major advantage of the Smagorinsky model, which should tend to the correct limit near walls, and should be able to describe backscattering (negative SGS viscosities). I replaced the domain average with a local face average to compute the coefficients: cI=<K*m>_face/<m*m>_face, and cD=<L.M>_face/<M.M>_face, where <...>_face is fvc::average(...). Additionally, to stabilize the numerical procedure, the SGS viscosity is limited so that it cannot become negative and smaller than -nu (laminar viscosity).
Tags:
Steps To Reproduce:	N/A
Additional Information:	- I called the model dynLocalAverageSmagorinsky to distinguish it from the currently implemented dynSmagorinsky, but it is actually the same model, with the differences explained above. - The header contains my copyright statement, since the code is in my GitHub repository ( git://github.com/AlbertoPa/dynLocalAverageSmagorinsky.git ). If you include the code in OpenFOAM, consider the copyright transferred to OpenCFD, and replace the header.