APPLICATION ERROR #804

Profile not found.

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.
Previous non-fatal errors occurred. Page contents follow.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4081 [OpenFOAM] Bug major always 2024-05-17 11:26 2024-05-17 13:30
Reporter: maHein 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: sixDoF Constrain 'plane' depends on magnitude of normal vector
Description: When performing a 6 DoE simulation with the plane sixDoFRigidBodyMotionConstraint, the motion of the body does not get correctly constrained if the magnitude of the plane normal is unequal to 1.
Tags:
Steps To Reproduce: Run the Allrun script in the case provided:

A falling sphere with gravity acting in negative x-direction and the surrounding flow in positive x-direction. Due to the plane constraint with normal vector in x-direction, the sphere should not fall. However, if the normal vector is (2 0 0), the shpere will still fall. Only if it is set to (1 0 0), the sphere motion is constrained correctly.
Additional Information: A simple normalization of the normal vector should suffice to resolve this issue.
System Description
Attached Files: sphere_xplane_constraint.zip (26,639 bytes) 2024-05-17 11:26
https://bugs.openfoam.org/file_download.php?file_id=3525&type=bug
Notes
(0013245)
henry   
2024-05-17 13:30   
We could undertake this development for you but will need to secure funding particularly given that the sixDoFRigidBodyMotion is deprecated and superseded by the more general and flexible multi-body rigidBodyMotion system.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4035 [OpenFOAM] Bug crash always 2023-11-16 14:30 2024-05-15 16:37
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:
4078 [OpenFOAM] Contribution minor always 2024-05-15 08:32 2024-05-15 08:32
Reporter: cgoessni Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version: dev  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: mergeMeshes is missing "timeSelector::addOptions()"
Description: mergeMeshes seems to be able to select a time (https://github.com/OpenFOAM/OpenFOAM-dev/blob/d21e75ac740b0d242e85141d7a531e71073b3fc5/applications/utilities/mesh/manipulation/mergeMeshes/mergeMeshes.C#L132), but it is missing a "timeSelector::addOptions()" call to make this feature fully functional. Without this call,

$ mergeMeshes -time 5 ...

would yield an error since -time is not a recognised command line option. The attached diff would resolve that, and works for our applications.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: mergeMeshes_diff.txt (571 bytes) 2024-05-15 08:32
https://bugs.openfoam.org/file_download.php?file_id=3522&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4071 [OpenFOAM] Bug major always 2024-04-12 09:35 2024-04-23 08:41
Reporter: nguyenhung97 Platform: GNU/Linux  
Assigned To: will OS: Ubuntu  
Priority: high OS Version: 22.04.3 LTS  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    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.
(0013233)
will   
2024-04-23 08:41   
Fixed by https://github.com/OpenFOAM/OpenFOAM-dev/commit/7fbd730f2aa68da3b8fd973e06de6d5edaa99588


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4073 [OpenFOAM] Bug minor always 2024-04-22 08:58 2024-04-22 13:40
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: JohnsonJackson -boundary conditions not working in dev
Description: In current dev the JohnsonJackson-boundary conditions, ie.
https://github.com/OpenFOAM/OpenFOAM-dev/tree/master/applications/modules/multiphaseEuler/momentumTransportModels/derivedFvPatchFields

refuse to restart, because the dimensionend scalars are written to disk such that the name of the scalar is duplicated an

restitutionCoefficient restitutionCoefficient [0 0 0 0 0 0 0] 0.8

This used to work, but in the latest dev this syntax is no longer tolerated.

To fix this, either the entries could be changed to write the values, ie.
writeEntry(os, "restitutionCoefficient", restitutionCoefficient_.value());
writeEntry(os, "specularityCoefficient", specularityCoefficient_.value());

or I have attached a patch where the dimensionedScalars are converted to scalars as they are dimLess and they are always used through .value() anyways.

Tags:
Steps To Reproduce: In tutorials/multiphaseEuler/fluidisedBed set it to
startFrom latestTime;
stopAt writeNow;

and try to run twice. The second run will refuse.
Additional Information: I tried to search for other uses of reading/writing of dimensionedScalars in BCs, but to my surprise didn't seem to find other examples.
Attached Files: patch.diff (8,487 bytes) 2024-04-22 08:58
https://bugs.openfoam.org/file_download.php?file_id=3504&type=bug
patch2.diff (3,185 bytes) 2024-04-22 10:21
https://bugs.openfoam.org/file_download.php?file_id=3505&type=bug
Notes
(0013231)
tniemi   
2024-04-22 10:21   
Alternative fix would be to change the constructors used to read the coefficients. This would allow backward compatibility as it accepts both ways, ie. without repeating the name or by repeating the name.
(0013232)
henry   
2024-04-22 13:40   
Resolved by commit 6a3c7ab502f963220ff8000a43be9b4afdc1d4dd


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:
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