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

Correct, we have never attempted to support this and it has not been requested before.
(0012201)
hussam   
2021-09-20 17:52   
Using commit d7133914fc13f1006fc95079580503eb3e221cf0 solves the problem. Thanks!
(0012202)
henry   
2021-09-20 19:16   
Resolved in OpenFOAM-9 by commit 055b575f99f01579d4e1dc4b69de79a083aa765e
Resolved in OpenFOAM-dev by commit d7133914fc13f1006fc95079580503eb3e221cf0


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3730 [OpenFOAM] Bug minor always 2021-09-17 14:49 2021-09-17 19:43
Reporter: noZeroDays Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: foamVersion constructs the wrong path
Description: On Ubuntu, OpenFOAM is typically installed in /opt/ directory.
However, when you invoke the foamVersion function on bash with an argument, it tries to construct a path to that version but the path is wrong, e.g:

$ foamVersion 8
bash: /opt/OpenFOAM-8/etc/bashrc: No such file or directory
Changed to OpenFOAM-8

notice that the path should be: /opt/openfoam8/etc/bashrc
Moreover, if you try to run invoke foamVersion again after it fails you will get:

foamVersion: command not found

Thanks,

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012194)
henry   
2021-09-17 15:33   
foamVersion wasn't designed for /opt installations and never tested for that purpose. Can you propose a version which works for the current purpose and also suits your requirements?
(0012195)
noZeroDays   
2021-09-17 18:48   
Should the following version be sufficient?

foamVersion ()
{
    if [ "$1" ]; then
        foamInstDir=$FOAM_INST_DIR;
        . $WM_PROJECT_DIR/etc/config.sh/unset;
        . ${WM_PROJECT_DIR//[0-9]*/$1}/etc/bashrc; # replace the previous version number with the argument
        cd $WM_PROJECT_DIR;
        echo "Changed to OpenFOAM-$1" 1>&2;
    else
        echo "OpenFOAM-$WM_PROJECT_VERSION" 1>&2;
    fi
}
(0012196)
henry   
2021-09-17 19:21   
While that will work for you it won't work for anyone with an OpenFOAM installation built from sources, i.e. anyone with an installation for which the current foamVersion was created.
(0012197)
noZeroDays   
2021-09-17 19:43   
Should we check if the path is valid before sourcing its bashrc file?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3728 [OpenFOAM] Bug major always 2021-09-15 22:25 2021-09-16 21:54
Reporter: hussam Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: high OS Version: 15.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 9  
    Target Version:  
Summary: If multiple meanVelocityForce entries are specified in cellZones only the first entry will be considered..
Description: if there are multiple entries of type meanVelocityForce on different cellZones within a region, only the first entry will be handled. All further entries will be neglected, at least according to the log file.
Tags:
Steps To Reproduce: Use the tutorial channel395 and replace fvConstraints and controlDict with the files in attachments. Additionally use attached topoSetDict to create the cellZones. for automated workflow you can use the attached Allrun and Allclean. By checking log.pimpleFoam it turned out the only first entry will be considered:
 
..
smoothSolver: Solving for Uz, Initial residual = 0.760481, Final residual = 8.02892e-06, No Iterations 4
Pressure gradient source: uncorrected Ubar = 0.177755, pressure gradient = 0.514522
GAMG: Solving for p, Initial residual = 0.181495, Final residual = 0.00635363, No Iterations 3

..
Additional Information: the problem occured by openfoam 9 and openfoam dev. Same problem does not appear for openfoam 7 or openfoam 8.
same output using openfoam 8 :

..
smoothSolver: Solving for Uz, Initial residual = 0.0589522, Final residual = 9.65879e-06, No Iterations 3
Pressure gradient source: uncorrected Ubar = 0.13368, pressure gradient = 0.336155
Pressure gradient source: uncorrected Ubar = 0.133691, pressure gradient = -0.000968907
GAMG: Solving for p, Initial residual = 0.657319, Final residual = 0.0327464, No Iterations 2
..
System Description
Attached Files: topoSetDict (1,175 bytes) 2021-09-15 22:25
https://bugs.openfoam.org/file_download.php?file_id=3221&type=bug
controlDict (1,040 bytes) 2021-09-15 22:25
https://bugs.openfoam.org/file_download.php?file_id=3222&type=bug
fvConstraints (965 bytes) 2021-09-15 22:25
https://bugs.openfoam.org/file_download.php?file_id=3223&type=bug
Allrun (368 bytes) 2021-09-15 22:25
https://bugs.openfoam.org/file_download.php?file_id=3224&type=bug
Allclean (177 bytes) 2021-09-15 22:25
https://bugs.openfoam.org/file_download.php?file_id=3225&type=bug
Notes
(0012192)
tniemi   
2021-09-16 19:45   
It seems that in fvConstraintsTemplates.C, there is a check

constrained =
                constrained || constraint.constrain(field);

in both eqn and field constrain-functions.

If constrained is true, the "constraint.constrain(field)" is never evaluated. The first U-constraint sets constrained to true for field U and then the second call to constrain the same field will not be evaluated.
(0012193)
henry   
2021-09-16 21:54   
Thanks for investigating Timo

Resolved in OpenFOAM-9 by commit f8d11b03103d5472d856c91903c230c1e7f07848
Resolved in OpenFOAM-dev by commit 102149135e74805e24ed144217a8fdb75752bb90


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3727 [OpenFOAM] Bug minor always 2021-09-14 08:17 2021-09-14 09:29
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: meshtools/coordinateSystem: Missing copy constructor preventing reuse of coordinateSystems
Description: I tried to use the constant/coordinateSystem-file to specify a single, simple coordinate system which was used in multiple porous regions. However, I noticed that this only worked for the first porous region and when the second one is created one gets

--> FOAM FATAL ERROR:
object of type N4Foam18coordinateRotationE is not allocated

I traced the issue to coordinateSystem-class, which has R_ as autoPtr but does not have a custom copy constructor. Thus when calling the clone-function, the default copy constructor is used which transfers the ownership of R_ and clears the original pointer. The next clone will produce a coordinateSystem with null R_.

Adding
coordinateSystem(const coordinateSystem &obj)
:
        name_(obj.name_),
        origin_(obj.origin_),
        R_(obj.R_->clone())
        {}

seemed to solve the issue.
Tags:
Steps To Reproduce: With tutorials/incompressible/pisoFoam/laminar/porousBlockage try to define another porosity source which uses "coordinateSystem porousBlockage;"

leads to
--> FOAM FATAL ERROR:
object of type N4Foam18coordinateRotationE is not allocated
Additional Information:
Attached Files:
Notes
(0012186)
henry   
2021-09-14 09:02   
Thanks for the report, I am working on this now. coordinateSystem will need an operator= as well as the copy constructor
(0012187)
henry   
2021-09-14 09:29   
Resolved by commit 3e157225676659a40589446f927e2eeed39c4e16


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3724 [OpenFOAM] Bug minor always 2021-09-01 21:34 2021-09-03 19:36
Reporter: peksa Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 15.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: IOobject construction may hang
Description: Dear developers,

The following issue description is directly related to my earlier issue on mapFieldsPar hanging (0003722),
in which I hastily proposed a solution that seemed to fix a symptom but not the fundamental reason.

After using the recent mapFieldsPar resolution in commit 458e9281e163a355f724ee82cc6a4ec89fb6a65d
I noticed that it actually failed to find the right sourceTime instance in parallel case, i.e. the
time instance is not looked from the processor directories but only from the main case. My earlier
test didn't yield this undesired behavior.

This drove me to look into the original implementation and quite quickly I found out that the initial
undesired hanging behavior is rising when constructing a Time object.

In order to investigate whether this is a general issue in object reconstruction,
I have modified the test utility Test-IOField.C for you to reproduce the issue.

Actually, Test-IOField is not functional at the moment because
it includes IOobject::objectPath(bool) functions without the boolean argument. After fixing this
issue (see script) one can compile it and build an example to reproduce the IO hanging.

When running the example in parallel, it should hang while reading one of the io objects.
I debugged the issue deeper into code and here it appears while IOField object is constructed,
and when the headerOk() function is called, which further inquires filePath() function from
regIOobject and even further from the IOobject classes. IOobject::filePath seems to be the source
of problems here. Furthermore, I did similar debugging for the initial mapFieldsPar problem and
the hanging happened in the same place.

I haven't been able to come up with a solution yet but wanted to report my findings here.

Let me know if you need some extra information.
Tags:
Steps To Reproduce: Run the attached shell script which compiles Test-IOField.C and tries to run an example case with it in parallel. Run should hang and not complete.
Additional Information:
System Description
Attached Files: buildIOCase.sh (610 bytes) 2021-09-01 21:34
https://bugs.openfoam.org/file_download.php?file_id=3219&type=bug
buildMapFieldsParDebugCase.sh (1,774 bytes) 2021-09-02 19:22
https://bugs.openfoam.org/file_download.php?file_id=3220&type=bug
Notes
(0012177)
henry   
2021-09-01 21:46   
mapFieldsPar is basically broken in several ways which is why I reinstated mapFields. It would make sense to avoid using mapFieldsPar until we can secure funding to rewrite it.
(0012178)
peksa   
2021-09-02 06:25   
I agree with you in terms of mapFieldsPar. I wonder if other parallel utilities may be influenced by this issue as well.
(0012179)
henry   
2021-09-02 07:57   
I have updated Test-IOField:

commit 3554f2140e4dbcd547b39867c7e4760bbb8377e2 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Thu Sep 2 07:55:49 2021 +0100

    Test-IOField: Updated and improved to use typeIOobject

We are not aware of any other parallel utilities which do not work correctly, do you know of any?
(0012180)
peksa   
2021-09-02 18:39   
Hey thanks for pointing out the correct usage of typeIOobject in this context. Now the test is executed succesfully.

I have tried to understand why the initial mapFieldsPar createTimes.H implementation lead to the hanging behaviour but I have not been able to reproduce the IOobject induced issue outside of that case yet. In addition, I tested some other parallel utilities having similar features and they all worked correctly as expected.
(0012181)
peksa   
2021-09-02 19:22   
Ok, I literally by a mistake got the initial mapFieldsPar working by changing the "startFrom" entry to "latestTime" instead of "startTime". So if you revert to commit d002a4de500c96542d89160d7539e03ed9f1eef4 (before the latest mapFieldsPar fix) and run again the attached shell script which again does parallel mapping between cavity cases but now with latestTime entry instead of startTime=0.

I have no idea why this works but what I quickly see is that Time object initiation has setControl() and setTime() functions which depend on the setting. The fix I proposed earlier has an issue that it cannot read the time values under processor folders while the older implementation with this entry change does things correctly. Weird but as you said, there are other problems as well...
(0012182)
henry   
2021-09-02 19:47   
Try this:

commit e6fdd180e8dc73e6914073908f159e58d622bd1d (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Thu Sep 2 19:45:14 2021 +0100

    mapFieldsPar: Corrected handling of argList and reverted change to createTimes.H
(0012183)
peksa   
2021-09-03 06:29   
Tested the commit and everything seems to work now. Thanks!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3722 [OpenFOAM] Bug minor always 2021-08-29 16:29 2021-08-30 10:36
Reporter: peksa Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 15.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 9  
    Target Version:  
Summary: mapFieldsPar hangs due to issue at createTimes.H
Description: Dear developers,

I have noticed that sometimes when executing the mapFieldsPar utility in parallel, it hangs before the actual interpolation operation starts.
I have attached a simple test case which I have built with the OpenFOAM-dev (7b7fa5a9af93d3a8a733f3cbda72b3daf03cf3ce).

The problem seems to arise at createTimes.H on line 9 where the runTimeSource Time object is created.
I tested to change the definition such that instead of using the argument list, I build the Time
object as "Time runTimeSource(Time::controlDictName, rootDirSource, caseDirSource);" which seemed to
cure the issue (similar to the serial mapFields counter part).

Hence, as a fix I propose to change the createTimes.H implementation similar to mapFields serial version.
Tags:
Steps To Reproduce: Run the attached shell script in any directory. The script copies the cavity case, runs it and tries to map it in parallel onto another copied case.

Additional Information:
System Description
Attached Files: buildMapFieldsParDebugCase.sh (1,585 bytes) 2021-08-29 16:29
https://bugs.openfoam.org/file_download.php?file_id=3216&type=bug
Notes
(0012175)
henry   
2021-08-30 10:36   
Thanks for the detailed report, steps to reproduce and proposed fix.

Resolved in OpenFOAM-9 by commit 458e9281e163a355f724ee82cc6a4ec89fb6a65d
Resolved in OpenFOAM-dev by commit e6d7b7aa3f71cd28affe62d947091ce92f1b0025


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3719 [OpenFOAM] Bug minor always 2021-08-25 14:05 2021-08-26 11:23
Reporter: evamaria Platform: Unix  
Assigned To: will OS: Other  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: 9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 9  
    Target Version:  
Summary: Composition properties missing
Description: The particleTracks cloudFunction does not write composition properties, which was done in the previous version (8) and seems to be relevant for reactingMultiphaseClouds.

This problem occurs in the $FOAM_TUTORIALS/combustion/reactingFoam/Lagrangian/verticalChannelSteady/. When the Allrun script is used for simulation only the properties (active, age, Cp, d, dTarget, nParticle, origId, origProcId, positions, rho, T, tTurb, typeId, U, Uturb) are written to Time/lagrangian/cloudTracks and f.ex. YH2O(l) is missing.
Tags:
Steps To Reproduce: Copy $FOAM_TUTORIALS/combustion/reactingFoam/Lagrangian/verticalChannelSteady/ case.
Use Allrun.
Check folder 500/lagrangian/cloudTracks/ .
Additional Information:
System Description
Attached Files:
Notes
(0012167)
will   
2021-08-26 11:23   
Thanks for the report. Fixed in version 9 and in dev.

https://github.com/OpenFOAM/OpenFOAM-9/commit/87b67d07a01da974efebf39954d9ad7583fa7556
https://github.com/OpenFOAM/OpenFOAM-dev/commit/e52567a4cfaf1f8d95b3b6877b7c96565d1d4c91


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3717 [OpenFOAM] Patch minor always 2021-08-24 17:50 2021-08-25 12:02
Reporter: mboesi Platform: Unix  
Assigned To: henry OS: Other  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: 9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 9  
    Target Version:  
Summary: Dynamic compilation of TDACChemistryModel fails
Description: The running the TDACChemistryModel fails when using thermo-physics not pre-defined in the chemistryModel. The issue is related to a missing symbol.
I've checked the problem and found out that the pre-processor instruction in the basicChemistryModelTemplate.C has a typo and, therefore, the standardChemistryModel and the chemistryReduction- and chemistryTabulationMethods are not compiled.
The instruction reads:
"#if ${method}CppTest == TDACChemistryModelCppTest" but should be "#if ${method}ChemistryModelCppTest == TDACChemistryModelCppTest".

I've attached a corrected version of the file and a test case based on the DLR_A_LTS case.
Tags:
Steps To Reproduce: Select a non
Additional Information:
System Description
Attached Files: DLR_A_LTSTest.tar.xz (21,916 bytes) 2021-08-24 17:50
https://bugs.openfoam.org/file_download.php?file_id=3210&type=bug
basicChemistryModelTemplate.C (6,148 bytes) 2021-08-24 17:50
https://bugs.openfoam.org/file_download.php?file_id=3211&type=bug
Notes
(0012163)
henry   
2021-08-25 11:25   
I can't reproduce the problem with the case you have provided, I get a string of errors from the thermo relating to incorrect input:

[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] keyword muCoeffs<8> is undefined in dictionary "/home/dm2/henry/Downloads/DLR_A_LTSTest/constant/thermophysicalProperties/H2/transport"
[0]
[0] file: /home/dm2/henry/Downloads/DLR_A_LTSTest/constant/thermophysicalProperties/H2/transport from line 809 to line 810.
[0]
[0] From function const Foam::entry& Foam::dictionary::lookupEntry(const Foam::word&, bool, bool) const
[0] in file db/dictionary/dictionary.C at line 811.
.
.
.
(0012165)
henry   
2021-08-25 12:02   
Resolved in OpenFOAM-9 by commit 7b57b4747f7583bad0fed179581a191f542709e4
Resolved in OpenFOAM-dev by commit 9b8aa48a7ed3d1f5e9f61c83c41d8b0e828a6af8


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3716 [OpenFOAM] Bug minor sometimes 2021-08-24 16:59 2021-08-25 11:56
Reporter: tniemi Platform:  
Assigned To: will OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Segmentation fault instead of proper IO ERROR
Description: I noticed that in recent dev versions I'm getting segmentation faults from places which normally should produce meaningful error messages. I managed to pinpoint the issue to this commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/4398f57c5e88f21b78d5d7edf66f733a8d13ad8f

Tags:
Steps To Reproduce: For example, if I take tutorials/combustion/reactingFoam/Lagrangian/verticalChannel and change "operation average;" to "operation averaged;", in OF9 I get

--> FOAM FATAL IO ERROR:
averaged is not in enumeration:
16
(
CoV
areaAverage
areaIntegrate
areaNormalAverage
areaNormalIntegrate
average
max
maxMag
min
minMag
none
orientedSum
sum
sumDirection
sumDirectionBalance
sumMag
)

However, currently in dev I only get

--> FOAM FATAL IO ERROR:
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 ? in "/lib/x86_64-linux-gnu/libc.so.6"
Segmentation fault (core dumped)

or

--> FOAM FATAL IO ERROR:
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::error::message() const at ??:?
#4 Foam::operator<<(Foam::Ostream&, Foam::IOerror const&) at ??:?
#5 ? at functionObjectList.C:?
#6 Foam::functionObjectList::timeToNextWrite() at ??:?
#7 Foam::Time::adjustDeltaT() at ??:?
#8 ? in "/opt/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/reactingFoam"
#9 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10 ? in "/opt/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/bin/reactingFoam"
Segmentation fault (core dumped)
Additional Information:
Attached Files:
Notes
(0012161)
tniemi   
2021-08-24 17:24   
"operation average;" refers to surfaceFieldValue in controlDict
(0012162)
tniemi   
2021-08-25 06:19   
Restoring the removed "error(const error&)" copy constructor seems to help with the issue.
(0012164)
will   
2021-08-25 11:56   
Yes, the pointer handling of the error class' string-stream got messed up. I don't see any reason for the string-stream being a pointer, so I've now made it an actual object. Even simpler. No copy constructors, no destructors.

https://github.com/OpenFOAM/OpenFOAM-dev/commit/32cfad7002c2b677114adadff76fdcf295533f80


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3712 [OpenFOAM] Bug minor sometimes 2021-08-13 22:25 2021-08-18 14:41
Reporter: peksa Platform: Linux  
Assigned To: will OS: Centos  
Priority: normal OS Version: 7  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Infinite loop in lagrangian move function due to stuck parcels
Description: I have experienced that sometimes my lagrangian spray simulations (reactingFoam / old sprayFoam) hang during the lagrangian computation step.

In particular, this seems to take place when Foam::particle::trackToFace() function yields a warning ""Particle #" << origId_ << " got stuck at " << position()". Typically this kind of stuck parcel near the domain boundary tells that your simulation may have other issues but I believe the solver should not result in an infinite loop behavior but at least result in an error after some time of unsuccesfull iteration.

To shed some more light on the topic, I utilised recent OpenFOAM-dev (git-rev 41b73ec5788a29f4d1928482c635db6cbe7d8dfe) to debug and present this issue by building a simple spray case (see link below). The case is not the "most proper" from CFD quality stand point in terms ofmesh, injector is close to the boundary and flow solver / numerics setup is just exemplary. The objective is to just achieve a reproducible example. This example case results in a hanging situation after a few time steps.

I have debugged this to make a conclusion that there is no break-up in the while loop of the Foam::MomentumParcel<ParcelType>::move() function because p.stepFactor() yields a constant number below unity. stepFactor is not achieving unity due to a stucking parcel indicated by the p.trackToFace() function, which also updates the stepFactor.

To me this is not a bug per'se because it appears probably only due to an ill-conditioned CFD setup. However, I'd like to propose that we could add a maximum number of iteration to the while loop (e.g. 10000) after which an error is introduced and solver exits properly.

Tags:
Steps To Reproduce: Download a ready case (~100MB with an existing time step data for a restart to minimize run-time)
https://1drv.ms/u/s!AnmySzLmJFhRgohF-qySTppCRcWEzA?e=6JJmoc

Extract the spray_hanging_issue_tracker.tar.gz

run by executing "reactingFoam" (will start from the latest time folder which is included).

Lagrangian solver "hangs" in few time steps.
Additional Information:
System Description
Attached Files:
Notes
(0012160)
will   
2021-08-18 14:41   
I agree that it would be better to exit with an error than to hang.

The problem with counters is that for them to work properly, they have to be stored as data on the particle. Otherwise any infinite loop situation which crosses a processor boundary won't be broken, as the counter will be reset on each crossing. Adding particle data has a performance penalty. Is it worth making correct cases less efficient in order to improve the failure modes of incorrect cases?

Also, the number is completely arbitrary. You suggest 10000, but if we are doing steady tracking or creating long streamlines, is that enough? If not, what is?

So, no, I don't see a convincing argument for adding a counter.

What I can do is catch the failure modes demonstrated in this case so that they error, rather than hang. This case fails for two reasons...

Firstly, because a parcel hits a wall for which no patch interaction has been specified. This is not valid. I have added a error to stop the code if this situation is detected.

Secondly, if I add a rebound interaction, the case fails because it is diverging. The velocity increases to 10^15-ish, and the CFL limiter then sets a step fraction which is below round off error. As such, the particle never evolves. I have limited the CFL limiter so that this does not happen. Now in your case, Lagrangian spits a lot of "stuck" warnings, but completes without failure, and it is the subsequent finite volume solution that then fails.

With these changes I consider the issue demonstrated by your case to be resolved.

https://github.com/OpenFOAM/OpenFOAM-dev/commit/08d6791d81d4ab7d7b54933006417cf52f9e1558


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

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012158)
henry   
2021-08-17 08:52   
Resolved by commit 4d97c3046946d9e9ecc18ec115af563c6a5794d6


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

        objects (Cp Cv);
    }
}
to OpenFOAM-9/tutorials/combustion/XiFoam/RAS/moriyoshiHomogeneous//controlDict and run case
Additional Information:
System Description
Attached Files:
Notes
(0012150)
henry   
2021-08-16 11:26   
Thanks for the bug-report
Resolved in OpenFOAM-9 by commit 0a36666bfadb6595330b575b3a5747cbe631cfdb
Resolved in OpenFOAM-dev by 64e94cfa6654dcb7dd0f8f89954040c13adc231a


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3650 [OpenFOAM] Bug minor always 2021-03-29 22:47 2021-07-13 15:28
Reporter: jherb Platform: GNU/Linux  
Assigned To: chris OS: OpenSuSE  
Priority: normal OS Version: 12.3  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Documentation on website for csv files has not been updated
Description: The documentation about using of csv files in boundary conditions has not been updated.

For OpenFOAM 8 at https://cfd.direct/openfoam/user-guide/v8-boundaries/#x25-1770005.2 it is still given:

inlet
{
    type uniformFixedValue;
    uniformValue
    {
        type csvFile;
        nHeaderLine 4; // number of header lines
        refColumn 0; // time column index
        componentColumns (1); // data column index
        separator ","; // optional (defaults to ",")
        mergeSeparators no; // merge multiple separators
        file "dataTable.csv";
   }
}

This should probably read like:

inlet
{
    type uniformFixedValue;
    uniformValue
    {
        type tableFile;
        format csv;
        nHeaderLine 4; // number of header lines
        refColumn 0; // time column index
        componentColumns (1); // data column index
        separator ","; // optional (defaults to ",")
        mergeSeparators no; // merge multiple separators
        file "dataTable.csv";
   }
}
Tags:
Steps To Reproduce:
Additional Information: See also https://github.com/OpenFOAM/OpenFOAM-dev/commit/7ab73932cf5b791f09001fb07ad8ce385e70234f
System Description
Attached Files:
Notes
(0012001)
henry   
2021-04-19 12:49   
Correct, the OpenFOAM-8 online documentation has not been updated yet, would you like to contribute to OpenFOAM maintenance for this kind of work?

See https://openfoam.org/news/funding-2021/

If not you can access the latest docs from your installation using

foamInfo function1

or you could generate the latest Doxygen documentation yourself.
(0012012)
chris   
2021-05-01 12:48   
The update has been processed. It should appear in 24 hours on the website, once page caching expires
https://cfd.direct/openfoam/user-guide/v8-boundaries/


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
99 [OpenFOAM] Bug feature N/A 2010-12-05 21:24 2021-07-13 15:27
Reporter: albertop Platform: Linux  
Assigned To: henry OS: OpenSuse  
Priority: normal OS Version: 11.3  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Dynamic Smagorinsky model with local coefficient values
Description: The current implementation of the dynamic Smagorinsky model in OpenFOAM uses a domain-averaged coefficient to compute the SGS stress tensor. This is not appropriate, since it removes the major advantage of the Smagorinsky model, which should tend to the correct limit near walls, and should be able to describe backscattering (negative SGS viscosities). I replaced the domain average with a local face average to compute the coefficients: cI=<K*m>_face/<m*m>_face, and cD=<L.M>_face/<M.M>_face, where <...>_face is fvc::average(...). Additionally, to stabilize the numerical procedure, the SGS viscosity is limited so that it cannot become negative and smaller than -nu (laminar viscosity).

Tags:
Steps To Reproduce: N/A
Additional Information: - I called the model dynLocalAverageSmagorinsky to distinguish it from the currently implemented dynSmagorinsky, but it is actually the same model, with the differences explained above.

- The header contains my copyright statement, since the code is in my GitHub repository ( git://github.com/AlbertoPa/dynLocalAverageSmagorinsky.git ). If you include the code in OpenFOAM, consider the copyright transferred to OpenCFD, and replace the header.
System Description
Attached Files: dynLocalAverageSmagorinsky.tar.gz (15,648 bytes) 2010-12-05 21:24
https://bugs.openfoam.org/file_download.php?file_id=42&type=bug
Notes
(0000156)
henry   
2010-12-05 21:42   
The dynamic Smagorinsky model dynSmagorinsky does what it is designed to do which is model the sub-grid turbulence in homogeneous turbulence. If you want to use a dynamic model with local averaging you can use locDynOneEqEddy but the averaging region is small and rather arbitrary and causes problem for complex flows. An alternative would be to use a form of Lagrangian averaging for the coefficients....
(0000158)
albertop   
2010-12-05 22:36   
I disagree. The dynamic Smagorinsky model, as implemented in OpenFOAM, does not reflect the original implementation. The current implementation uses a constant value of the coefficients in the whole computational domain, which is not what is done in the dynamic model, where Cs should properly tend to small values when approaching, for example, a wall, or where the flow laminarizes.

The current implementation in OpenFOAM is simply a traditional Smagorinsky model with Cs determined from the flow, but it loses one of the fundamental advantages of the dynamic procedure, which is being able to describe what happens near walls, or where the flow laminarizes, without any need of damping functions.

The original model of Germano relied on averaging along the homogeneous direction, since one existed in his channel flow, but Cs could change normally to walls. However the averaging was a justified workaround to avoid numerical difficulties.

Averaging on cell faces does not really introduce any major error, given the grid resolution required to perform LES, and it mitigates the chances of having a very small number in the division to compute Cs.

The implementation I attached has been widely tested on channel flows, and in much more complicated cases in chemical reactors for mixing applications, without observing numerical difficulties and with results in excellent agreement with PIV experiments.
(0000159)
henry   
2010-12-05 22:40   
Different averaging is appropriate for different purposes and the averaging in dynSmagorinsky is the most appropriate for the purpose for which it was written. Perhaps you would prefer that dynSmagorinsky were renamed but given that it is a name we created and not the name Germano or others used I am not sure what the problem is with it.
(0000160)
albertop   
2010-12-05 23:05   
In the literature, "dynamic Smagorinsky" identifies a model where the coefficient is computed locally and based on the flow conditions. Your implementation follows the dynamic procedure suggested by Germano, but then it throws away its advantages by averaging on the whole computational domain. I understand why this was done, however it confused quite some users, who believed to deal with the dynamic Smagorinsky model they find described in the literature and implemented in other codes.
(0000161)
henry   
2010-12-05 23:08   
There are many many forms of dynamic SGS models which use various form of averaging. The one under the name dynSmagorinsky uses the recommended and appropriate averaging for simulating homogeneous turbulence which is what we implemented it for. If you are not simulating homogeneous don't use it.
(0000162)
albertop   
2010-12-06 03:30   
Yes, I am aware there are various approaches to define the dynamic coefficient. However, I do not see the assumption of homogeneous turbulence clarified anywhere (you have to check the implementation to see it), and it is surely less general and more arbitrary than a local average, if implemented in a general code as OpenFOAM is.

To conclude, I based my implementation on what is usually done for LES on unstructured grids (S.E. Kim, Large Eddy Simulation Using an Unstructured Mesh Based Finite-Volume Solver, American Institute of Aeronautics and Astronautics, 34th Fluid Dynamics Conference and Exhibit, AIAA-2004-2548, June 2004), but allowing back-scattering. Their approach has been implemented in commercial codes, which additionally limit the coefficient to zero, and they also fix an upper limit for it. Both these assumptions are however arbitrary, and I did not include them. Clipping the effective viscosity might be rough, but it has a physical foundation, and successfully stabilizes the code.
(0000164)
henry   
2010-12-06 08:38   
I agree that the description in dynSmagorinsky is not sufficient and we will elaborate in the next version.
(0012083)
henry   
2021-07-13 15:27   
The dynSmagorinsky model has been removed as it is not generally useful or worth maintaining.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3014 [OpenFOAM] Bug crash always 2018-07-24 12:43 2021-07-13 15:22
Reporter: holger Platform: GNU/Linux  
Assigned To: henry OS: Lubuntu  
Priority: urgent OS Version: 16.04  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: PDRFoam tutorial case "flamePropagationWithObstacles" is crashing
Description: executing PDRMesh gives:
 --> FOAM Warning :
 39 From function Foam::mixedFvPatchField<Type>::mixedFvPatchField(const Foam::mixedFvPatchField<Type>&, const Foam::fvPatch&, const Foam::DimensionedField<Type, Foam::volMesh>&, const Foam::fvPatchFieldMapper&) [with Type = double]
 40 in file /home/ubuntu/OpenFOAM/OpenFOAM-6/src/finiteVolume/lnInclude/mixedFvPatchField.C at line 77
 41 On field subsetp patch outer patchField mixed : mapper does not map all values.
 42 To avoid this warning fully specify the mapping in derived patch fields.


PDRFoam finally crashes after Time = 0.0125725 after many warnings
Tags:
Steps To Reproduce: run the standard tutorial case, ./Allrun
Additional Information: same error with version 5.0 and dev
System Description
Attached Files: log.PDRFoam (1,153,931 bytes) 2018-07-24 12:43
https://bugs.openfoam.org/file_download.php?file_id=2489&type=bug
Notes
(0009871)
henry   
2018-07-24 12:53   
Currently we have no funding to maintain or develop PDRFoam and cannot spend time on this tutorial.

OpenFOAM must be funded:
https://openfoam.org/news/funding-2018/
This kind of prioritisation over features reported through the issue tracking system requires a silver support package:
https://openfoam.org/maintenance/
The cost is a small fraction of a single, annual, commercial CFD licence. It is a small fraction of the total cost of any serious, in-house CFD capability.

If we cannot secure any funding to maintain PDRFoam we will have to remove it altogether.
(0009872)
holger   
2018-07-24 13:10   
thank you for your answer. Is the same the case for the solver fireFOAM (the flameSpreadWaterSuppressionPanel crashes as well)?
(0009873)
henry   
2018-07-24 13:31   
Yes, we have no maintenance funding for fireFoam either. If you want to spend some time on these cases to resolve the issues and provide patches please go ahead.
(0009876)
henry   
2018-07-31 14:13   
Pending maintenance funding and/or contribution.
(0009950)
henry   
2018-08-13 14:51   
Resolved in OpenFOAM-6 by commit a2c8fc63d9a315382b2afeaa0eae53af476d65e1
Resolved in OpenFOAM-dev by commit commit c3c09229be64ace420bd7a01285cce1783217f99


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
66 [OpenFOAM] Bug major always 2010-10-26 08:16 2021-07-13 15:22
Reporter: user25 Platform: Linux  
Assigned To: user2 OS: Fedora  
Priority: normal OS Version: 12  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Temperature increases beyond inlet temperatures with reactions off
Description: Solved for only species transport, the CounterflowFlame2D tutorial file (in version 1.7.1) using reactingFoam.
Specified reactions off and turbulent reactions off in constant/chemistryProperties.
Temperatures at both inlets are 800K (as was given in the tutorial file). No other modificattion in the files.
As no reactions, one would expect temperatures to be below 800K as only species transport.
However, the temperature increased beyond 800 K (it went close to 840 K - log file is attached).
Why temperatures should increase if there is no heat generation due to reaction?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: log.rar (315,096 bytes) 2010-10-26 08:16
https://bugs.openfoam.org/file_download.php?file_id=24&type=bug
Notes
(0000094)
user2   
2010-10-26 17:08   
Our reactingFoam algorithm is an efficient, approximate method for turbulent reacting flow. However, in the laminar limit the approximation breaks down, leading to temperature inconsistencies.

In the laminar case, if you have a composition gradient, the only way to ensure that the diffusion does not give rise to temperature errors is by enforcing a Lewis no = 1 constraint, e.g. update the sensible enthalpy eqn to:

    fvScalarMatrix hsEqn
    (
        fvm::ddt(rho, hs)
      + mvConvection->fvmDiv(phi, hs)
// - fvm::laplacian(turbulence->alphaEff(), hs)
      - fvm::laplacian(turbulence->muEff(), hs) // unit lewis no.
     ==
        DpDt
      + chemistrySh
    );

This is an area that we would like to research and update in the future if we gain sponsorship to do so.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3693 [OpenFOAM] Bug minor always 2021-07-08 14:46 2021-07-09 16:11
Reporter: jkau Platform: Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 20.04.2  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: uniformFixedValue with vector fails after restart
Description: When using uniformFixedValue BC for a vector, after restart the solver exits with following error message:

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

This happens also after executing setFields for the vector entry or after decomposing the case.
Tags:
Steps To Reproduce: E.g. change the movingWall entry in the cavity tutorial from fixed to uniformFixeValue as below, change "startFrom" to "latestTime", start, stop and restart the computation.
    movingWall
    {
        type uniformFixedValue;
        value uniform (0 0 0);

        uniformValue
        {
            type scale;
            scale linearRamp;
                duration 1;
        value (1 0 0);

        }

    }
Additional Information:
System Description
Attached Files:
Notes
(0012080)
henry   
2021-07-09 16:11   
Resolved by commit 52ec3c0befb0e8d14c737a351ddb6a6c55938e13


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3692 [OpenFOAM] Bug minor always 2021-07-02 08:41 2021-07-02 15:14
Reporter: fede Platform: Linux  
Assigned To: will OS: Debian  
Priority: normal OS Version: 9  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: options "-dict" and "-case" do not work when used together in decomposePar
Description: If options "-case" and "-dict" are used at the same time when decomposePar is launched, the application does not find the dictionary file. This is due to a wrong definition of the variable dictPath for this very specific case. Please find attached a file with a proposal of modification to decomposePar.C to fix the issue.

Version tested: OpenFOAM-dev, commit 261d5ccd6.
Kind regards,

federico
Tags:
Steps To Reproduce: cd $FOAM_TUTORIALS/multiphase/interFoam/laminar/damBreak

blockMesh -case damBreak
setFields -case damBreak

Then, none of these commands works:

decomposePar -case damBreak -dict system/decomposeParDict

decomposePar -case damBreak -dict damBreak/system/decomposeParDict

decomposePar -case damBreak -dict system/
Additional Information:
System Description
Attached Files: decomposePar.C (46,374 bytes) 2021-07-02 08:41
https://bugs.openfoam.org/file_download.php?file_id=3174&type=bug
decomposePar-2.C (46,251 bytes) 2021-07-02 12:06
https://bugs.openfoam.org/file_download.php?file_id=3175&type=bug
Allrun.test (1,238 bytes) 2021-07-02 12:06
https://bugs.openfoam.org/file_download.php?file_id=3176&type=bug
Notes
(0012075)
will   
2021-07-02 09:49   
Your change assumes that the directory passed to `-case` is relative to the current working directory. If it is absolute, then `cwd()/caseName/dictPath` will be nonsense.

Also, I don't think we want `-dict` to be relative to `-case`. I think that's confusing, and that it would better for them both to be handled as paths that are either absolute or relative to the current working directory.

If we do that, then all that is needed is to add `dictPath.toAbsolute()` after the argument is read.
(0012076)
fede   
2021-07-02 12:06   
Hi Will,
thank you very much for your hint, very helpful.
Please find attached a modified version of the working code and a script to test it.
Kind regards,

Federico
(0012077)
will   
2021-07-02 12:27   
Thanks, but I'm afraid this affects more than just decomposePar. The logic needs to be centralised and made consistent across a bunch of applications. There is some of this implemented in `systemDict`, but it needs extending to handle `-case` and to do the `isDir` stuff correctly. I'm working on it now.
(0012078)
will   
2021-07-02 15:14   
Looking at the rest of the code, it seems to be standard that if -dict has a relative path then that path is taken to be from the case directory. If -dict is absolute, then it's just an absolute path. That wasn't my initial assumption, but it's fine as a convention as log as it's applied consistently.

So, I've enforced that everywhere. I've extended the systemDict stuff and it's now handling all -dict options in all executables. It should all be correct now.

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

Your test script won't work because it's assuming relative paths relative to the working directory, not the case directory. You don't need "damBreak" at the start of the relative paths (the ones without $workDir). If you remove these then it runs.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3691 [ThirdParty] Patch minor always 2021-06-30 12:27 2021-06-30 14:32
Reporter: handrake0724 Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: incorrect comment for libccmio
Description: files in the directory ThirdParty-dev/etc/wmakeFiels/libccmio:
   files
   options

still have old comment style.
It should be corrected to # instead of /* */ like bash script following OpenFOAM-dev commit 848ec1cd9726b4f4913a69e5611188027de7453a
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012074)
henry   
2021-06-30 14:32   
Resolved by commit f1f5413449bedade542b41d940d81cc22b4b49a8


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3690 [OpenFOAM] Bug minor always 2021-06-29 16:03 2021-06-29 17:43
Reporter: fede Platform: Linux  
Assigned To: henry OS: Debian  
Priority: normal OS Version: 9  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: engineTime-based solvers cannot run with the option -case
Description: The definition of the path of the engineGeometry file in engineTimeNew.C is not correct, if the solver has not launched in the $FOAM_CASE folder.

Please find attached a patched version of the file (see line 41 of the file) that fixes this issue.

Wish this helps.
Kind regards,

Federico
Tags:
Steps To Reproduce: cd $FOAM_TUTORIALS/combustion/coldEngineFoam

blockMesh -case freePiston
coldEngineFoam -case freePiston


OpenFOAM release used: OpenFOAM-dev, commit 10a6e7a46
Additional Information:
System Description
Attached Files: engineTimeNew.C (2,567 bytes) 2021-06-29 16:03
https://bugs.openfoam.org/file_download.php?file_id=3173&type=bug
Notes
(0012071)
henry   
2021-06-29 16:38   
Have you tested your proposed change in parallel?
(0012072)
fede   
2021-06-29 17:10   
you are right, I simply forgot. I fix the lines to make it work in serial and parallel and I send it back. Apologies
(0012073)
henry   
2021-06-29 17:43   
Resolved by commit fbfbe79bcd3212f80ebbdd0d8b337fef7d367616


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3689 [OpenFOAM] Bug minor always 2021-06-17 13:42 2021-06-19 12:14
Reporter: tiziano.maffei Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 20.04  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: postProcessing with surfaceFieldValue function
Description: Good morning,
I have found a bug in the lib libfieldFunctionObjects.so.

When I run a solver with the option to evaluate i.e the flowRatePacth specified in the functions dictionary in the file system/controlDict, I have noted the function is called two times
If regionType is defined as patch, this is not a big issue.

But, if I set the keyword regionType with the option sampledSurface and the subdictionary sampledSurfaceDict, I get an error message: "Either weightField or orientedWeightField can be supplied, but not both", even if I didn't specify any weightField and by default it should be "none".
Infact, in the first call the weightField is set as "none" but in the second call is set with the field defined in orientedWeighField (assigned to weightField after the first call, as indicated in the file surfaceFieldValue.C)

Thank you for your time

Tiziano
Tags:
Steps To Reproduce: In the example "tutorials/incompressible/pimpleFoam/RAS/TJunction", I have added in the functions dictionary of the system/controlDict

x1
{
    type surfaceFieldValue;
    functionObjectLibs ( "libfieldFunctionObjects.so" );
    writeControl timeStep;
    writeInterval 1;
    log true;
    writeFields false;
    regionType sampledSurface;
    sampledSurfaceDict
    {
        type cuttingPlane;
        planeType pointAndNormal;
        pointAndNormalDict
        {
            basePoint ( 0.055 0 0.01 );
            normalVector ( 1 0 0 );
        }
        source cells;
        interpolate true;
    }
    operation weightedSum;
    orientedWeightField phi;
    fields ( );
}


The output is:

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

Create mesh for time = 0


PIMPLE: No convergence criteria found


PIMPLE: Operating solver in transient mode with 1 outer corrector
PIMPLE: Operating solver in PISO mode


Reading field p

Reading field U

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting turbulence model type RAS
Selecting RAS turbulence model kEpsilon
RAS
{
    model kEpsilon;
    turbulence on;
    printCoeffs on;
    Cmu 0.09;
    C1 1.44;
    C2 1.92;
    C3 0;
    sigmak 1;
    sigmaEps 1.3;
}

No MRF models present

No fvModels present
No fvConstraints present
Courant Number mean: 0 max: 0

Starting time loop

surfaceFieldValue flowRatePatch(name=outlet1):
    total faces = 25
    total area = 0.0004


surfaceFieldValue flowRatePatch(name=outlet1):
    total faces = 25
    total area = 0.0004


surfaceFieldValue flowRateFaceZone(name=fz1):
    total faces = 31
    total area = 0.000496


surfaceFieldValue flowRateFaceZone(name=fz1):
    total faces = 31
    total area = 0.000496


surfaceFieldValue flowRatePatch(name=outlet2):
    total faces = 25
    total area = 0.0004


surfaceFieldValue flowRatePatch(name=outlet2):
    total faces = 25
    total area = 0.0004


surfaceFieldValue flowRateFaceZone(name=fz2):
    total faces = 31
    total area = 0.000496


surfaceFieldValue flowRateFaceZone(name=fz2):
    total faces = 31
    total area = 0.000496


surfaceFieldValue x1:
    total faces = 25
    total area = 0.0004
    weight field = phi


surfaceFieldValue x1:
    total faces = 25
    total area = 0.0004

--> FOAM FATAL IO ERROR:
Either weightField or orientedWeightField can be supplied, but not both

file: /home/tiziano/OpenFOAM/tiziano-dev/tutorials/incompressible/pimpleFoam/RAS/TJunction/system/controlDict/functions/x1 from line 90 to line 111.

    From function void Foam::functionObjects::fieldValues::surfaceFieldValue::initialise(const Foam::dictionary&)
    in file fieldValues/surfaceFieldValue/surfaceFieldValue.C at line 511.

Additional Information:
Attached Files:
Notes
(0012070)
henry   
2021-06-19 12:14   
Resolved by commit c8307122c67df4f2b156e61c7530604218923837


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3688 [OpenFOAM] Bug minor always 2021-06-12 04:38 2021-06-15 10:16
Reporter: rvadrabade Platform: Unix  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Is Foam::multiphaseMixture::surfaceTensionForce() depends on phase order in transportProperties?
Description: I am debugging multiphaseInterFoam solver to understand the underlying physics. However, it is observed that the order of phases in constant/transportProperties.phases affects the accurate calculation of surface tension force (Foam::multiphaseMixture::surfaceTensionForce()).
In spite of having contact angle boundary defined for air phase [alpha.air] with original tutorial, the if(isA<alphaContactAngleFvPatchScalarField>(gbf[patchi])) condition in Foam::multiphaseMixture::correctContactAngle() [ multiphaseMixture.C L:414] is always false.
Further, if the air phase defined first in constant/transportProperties.phases then Foam::multiphaseMixture::correctContactAngle() works as expected see attachment damBreak4phaseModifiedCase.
The effect of accurate calculation of surface tension force considering the contact angle might be very small. However, I would like to know if this behavior is as per the design of the multiphaseInterFoam solver and is as expected or there is scope for improvement?
Tags:
Steps To Reproduce: At first glance, it might be difficult to understand the issue. However, the following steps will be helpful to reproduce the mentioned behavior.
Steps for Original Case:

Download the attached folder
cd damBreak4phaseOriginalCase

Issue the following commands one by one in terminal (Ubuntu or WSL)

1. gdb multiphaseInterFoam
2. b multiphaseMixture.C:417 [say 'y' for prompt as breakpoint pending on future shared library]
3. run

Observe that the breakpoint will not hit even a single time.

Steps for Modified Case:

cd damBreak4phaseModifiedCase

Again, Issue the following commands one by one in terminal (Ubuntu or WSL)

1. gdb multiphaseInterFoam
2. b multiphaseMixture.C:417 [say 'y' for prompt as breakpoint pending on future shared library]
3. run

Observe that the application will surely break at the requested place.

Conclusion:

Only change in the damBreak4phaseModifiedCase is the order of phase [with contact angle i.e, air] in constant/transportProperties.phases which might affect the solver.
Hence, I see, as air phase is defined last in constant/transportProperties.phases the contact angle contribution is not well captured in surface tension force (even though it might be small).
Additional Information:
System Description
Attached Files: damBreak4phaseOriginalCase.zip (101,892 bytes) 2021-06-13 17:38
https://bugs.openfoam.org/file_download.php?file_id=3171&type=bug
damBreak4phaseModifiedCase.zip (102,548 bytes) 2021-06-13 17:38
https://bugs.openfoam.org/file_download.php?file_id=3172&type=bug
Notes
(0012067)
henry   
2021-06-14 10:46   
Try this commit in OpenFOAM-dev:

commit de76426d86f076e36332c3554753f7bf5cd377c2 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Mon Jun 14 10:42:16 2021 +0100

    multiphaseInterFoam: Added test for contact angle in both phases in interface pair
    
    to ensure that the contact angle specification is used irrespective of which
    phase it is specified in. An error is reported if both phases of the interface
    pair have a contact angle specification as the specifications might be
    inconsistent.
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3688
(0012068)
rvadrabade   
2021-06-15 04:38   
Hi Henry,
Fantastic. Thanks for resolution. soon, I will check and share my observations. As such from high level look, the added test is sufficient to ensure contact angle will be used irrespective of phase order. So, if you feel we can mark it as solved.

Also, currently, I see another similar scenario for compressibleMultiphaseInterFoam/multiphaseMixtureThermo/multiphaseMixtureThermo.C: Foam::multiphaseMixtureThermo::correctContactAngle. If possible, same resolution can be applied to other similar case, if multiple scenario found.

Thanks for your time and efforts.
(0012069)
henry   
2021-06-15 10:16   
Resolved by:
commit 7b7fa5a9af93d3a8a733f3cbda72b3daf03cf3ce
commit de76426d86f076e36332c3554753f7bf5cd377c2


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3684 [OpenFOAM] Bug minor always 2021-06-10 07:32 2021-06-10 08:44
Reporter: albertop Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Incorrect coefficients of polynomial in limiter
Description: The coefficents a_ and b_ in cubicGradientLimiter.H do not satisfy some of the conditions on the derivatives from the original reference.

Expanding the polynomial that defines r leads to a r^3 + b^2 + r, which is zero and has derivative equal to 1 for r = 0. However, the behavior for r= rt is incorrect (the value of the polynomial should be 1 and its derivative should be zero).

The correct values of the coefficients are:

a = -2/rt^3 + 1/rt^2
b = -1/(2*rt) - 3*a*rt/2

Originally found by Shannon Leakey ( https://www.cfd-online.com/Forums/openfoam-programming-development/236503-polynomial-celllimited-cubic-seems-dodgy.html ). I have verified the results reported in the CFD-online post and are correct.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012053)
henry   
2021-06-10 08:44   
Resolved by commit eea13a52b2e02d32f5cccf82e59bff53b38c18d3


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3682 [OpenFOAM] Contribution minor N/A 2021-06-07 11:55 2021-06-08 16:43
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Patch to fieldAverage: Add support for averaging internal fields
Description: Here is a simple patch, which adds support for averaging internal fields. This can be useful (= where I have used it) for eg. averaging the sources from Lagrangian parcels. Possibly for other internal fields/source terms as well.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch.diff (6,321 bytes) 2021-06-07 11:55
https://bugs.openfoam.org/file_download.php?file_id=3160&type=bug
Notes
(0012051)
henry   
2021-06-08 16:43   
Thanks for the patch

Resolved by commit d92434cad0ff72f5c24bd9a035db5d19accd5df6


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3680 [OpenFOAM] Bug trivial have not tried 2021-05-24 12:01 2021-05-24 12: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: variableTimeStep_ leftover in TDAC
Description: The variableTimeStep-flag was removed in this commit:

https://github.com/OpenFOAM/OpenFOAM-dev/commit/672afc917d45b8c1540a3943182c6aa3705bed9c

However, there is still bool variableTimeStep_ in TDACChemistryModel.H which is not used anywhere anymore and could be removed.

Related to TDACChemistryModel, currently all of its internal variables are set as private, which makes it difficult to inherit from it. Would it be possible to mark the member variables as protected similarly as in standardChemistryModel?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012043)
henry   
2021-05-24 12:28   
Resolved by commit e99737fd1b8af95ffe39e372f2621fb502f6b23f


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3675 [OpenFOAM] Bug minor sometimes 2021-05-17 18:24 2021-05-18 14:36
Reporter: oder Platform: Linux-5.5.16-100.fc30.x86_64  
Assigned To: henry OS: Fedora  
Priority: normal OS Version: 30  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: Undefined behavior in function Foam::ISstream::getLine
Description: The undefined behavior occurs at the following line
https://github.com/OpenFOAM/OpenFOAM-8/blob/6a90c5e21f9f73f21de679dd775e62a783fbd5c3/src/OpenFOAM/db/IOstreams/Sstreams/ISstream.C#L778

Just a few lines above (L774), a line is read from a file into Foam::string s. Foam::string is a specialization of class std::string. However, if the line was empty, string s is empty. Calling s.back() on an empty string leads to undefined behavior, as stated here:
https://en.cppreference.com/w/cpp/string/basic_string/back

I believe this is also present in the OpenFoam-dev version, although there was a global continuation flag added there, which, in case it is true, leads to the same behavior.


Tags:
Steps To Reproduce: In my instance there is no problem with a version compiled with optimization flags, however, when compiled with debugging flags (WM_COMPILE_OPTION=Debug in etc/bashrc) the program gets aborted. Thus, I marked the reproducibility to sometimes and severity as minor, although the undefined behavior is always there.

This part of code is used when reading the template file etc/codeTemplates/dynamicCode/codedFvOptionTemplate.C when creating the C++ source files with scalarCodedSource source term in system/fvOptions. The template file contains empty lines.
Additional Information: The solution I would propose is to insert the following line just above the while loop in line L778:
if (s.empty()) return *this;

If the line is empty there is nothing to concatenate and no line to continue anyway.

If required I can provide a simplified test case with which I was debugging the code.
System Description
Attached Files: issue-0003675-logs.tar.gz (3,723 bytes) 2021-05-18 10:21
https://bugs.openfoam.org/file_download.php?file_id=3151&type=bug
issue-0003675-gdb.txt (5,606 bytes) 2021-05-18 10:21
https://bugs.openfoam.org/file_download.php?file_id=3152&type=bug
issue-0003675-case.tar.gz (3,825 bytes) 2021-05-18 10:21
https://bugs.openfoam.org/file_download.php?file_id=3153&type=bug
log.buoyantSimpleFoam (13,035 bytes) 2021-05-18 14:24
https://bugs.openfoam.org/file_download.php?file_id=3154&type=bug
Notes
(0012027)
henry   
2021-05-17 18:29   
Can you provide a means to reproduce the problem?
(0012032)
oder   
2021-05-18 10:21   
I hope I did this correctly. Attached is the tarball with case files (issue-0003675-case.tar.gz) and a tarball with logs (issue-0003675-logs.tar.gz):

issue-0003675-logs/log.buoyantSimpleFoam.Debug ... Run with OF-8 from master branch, compiled with Debug flag. Gets aborted.
issue-0003675-logs/log.buoyantSimpleFoam.fix ... Run with OF-8 from master branch with proposed fix.
issue-0003675-logs/log.buoyantSimpleFoam.Opt ... Run with OF-8 from master branch, compiled with Opt flag. No problems.
issue-0003675-logs/log.buoyantSimpleFoam.system ... Run with our system version of OF-8. No problems.

I also attach the relevant output of the debugging session with gdb of OF-8 from master branch, compiled with debugging symbols (Debug flag).
(0012033)
henry   
2021-05-18 13:16   
I have been unable to reproduce the problem and so cannot test the fix in OpenFOAM-8:

commit 6d8538864cc3d80b285e2dbfa7c01097de9f0276 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Tue May 18 13:10:50 2021 +0100

    ISstream: Added test for empty string before parsing continuation lines
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3675

or OpenFOAM-dev:

commit 58afe5dccbc864afb41428a11b622d49d4c2c1f0 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Tue May 18 13:12:03 2021 +0100

    ISstream: Added test for empty string before parsing continuation lines
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3675

Could you test and report back?
(0012034)
oder   
2021-05-18 14:24   
I have tested it with OpenFOAM-8 and the fix works (log file attached).

As far as I have checked, in OpenFOAM-dev, getLine in this particular case is called with continuation == false, so s.back() is never called anyway. [1]

[1] https://github.com/OpenFOAM/OpenFOAM-dev/blob/40bc30c0f7f8394437737f5311b1d2960f3f8a06/src/OpenFOAM/db/dynamicLibrary/dynamicCode/dynamicCode.C#L130

Thank you!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3672 [OpenFOAM] Bug text always 2021-05-14 04:34 2021-05-14 10:11
Reporter: noZeroDays Platform:  
Assigned To: will OS:  
Priority: low OS Version:  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: noOrdering keyword is still present in some files of OpenFOAM 8 tutorials
Description: Hello,
If I am not mistaken, the allowed values for cyclicAMI transform in OpenFOAM 8 are:
* none
* rotational
* translational
* unspecified

However, when searching for the keyword 'noOrdering' in OpenFOAM8 tutorials, that keyword is still there, e.g:

grep -r "noOrdering" /opt/openfoam8

Will yield the following:

/opt/openfoam8/tutorials/multiphase/interFoam/RAS/mixerVesselAMI/system/createBafflesDict: ordering noOrdering;
/opt/openfoam8/tutorials/multiphase/interFoam/RAS/mixerVesselAMI/system/createBafflesDict: ordering noOrdering;
/opt/openfoam8/tutorials/compressible/rhoPimpleFoam/RAS/annularThermalMixer/system/createBafflesDict: ordering noOrdering;
/opt/openfoam8/tutorials/lagrangian/particleFoam/mixerVesselAMI2D/system/blockMeshDict.m4: ordering noOrdering;
/opt/openfoam8/tutorials/lagrangian/particleFoam/mixerVesselAMI2D/system/blockMeshDict.m4: ordering noOrdering;
/opt/openfoam8/tutorials/incompressible/pimpleFoam/RAS/oscillatingInletACMI2D/system/createBafflesDict: ordering noOrdering;
/opt/openfoam8/tutorials/incompressible/pimpleFoam/RAS/oscillatingInletACMI2D/system/createBafflesDict: ordering noOrdering;
/opt/openfoam8/tutorials/incompressible/pimpleFoam/RAS/oscillatingInletACMI2D/README: ordering noOrdering;
/opt/openfoam8/tutorials/incompressible/pimpleFoam/RAS/oscillatingInletACMI2D/README: ordering noOrdering;
/opt/openfoam8/tutorials/incompressible/pimpleFoam/RAS/oscillatingInletACMI2D/README: ordering noOrdering;
/opt/openfoam8/tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D/system/blockMeshDict.m4: ordering noOrdering;
/opt/openfoam8/tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D/system/blockMeshDict.m4: ordering noOrdering;
/opt/openfoam8/etc/templates/closedVolumeRotating/system/createBafflesDict: transform noOrdering;
/opt/openfoam8/etc/caseDicts/mesh/manipulation/AMI/createBafflesDict: transform noOrdering;
/opt/openfoam8/etc/caseDicts/mesh/manipulation/AMI/createPatchDict: transform noOrdering;

Thank you
Tags:
Steps To Reproduce: Search for 'noOrdering' in OpenFOAM8 tutorials, e.g: grep -r "noOrdering" /opt/openfoam8
Additional Information:
Attached Files:
Notes
(0012023)
noZeroDays   
2021-05-14 04:38   
Sorry, this is not only specific to the tutorials directory, but also in the file:
/opt/openfoam8/etc/caseDicts/mesh/manipulation/AMI/createPatchDict
(0012024)
will   
2021-05-14 10:11   
Resolved in version 8 and dev

https://github.com/OpenFOAM/OpenFOAM-8/commit/6a90c5e21f9f73f21de679dd775e62a783fbd5c3
https://github.com/OpenFOAM/OpenFOAM-dev/commit/0510053f6170883414e0c2a7f0b78cfb44d47b7e


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3666 [OpenFOAM] Patch trivial always 2021-04-26 16:20 2021-05-01 23:06
Reporter: lorenzotrevisan Platform: x86_64  
Assigned To: OS: Slackware  
Priority: low OS Version: 14.2  
Status: new Product Version: dev  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    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:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3669 [OpenFOAM] Bug minor sometimes 2021-04-29 15:33 2021-04-30 12:23
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: Regression in Time.C, first write time is wrong if not starting from 0 and not a restart
Description: Hi

We stumbled to odd behavior of sometimes not getting time directories as output if the starting folder was not 0 and it was not a normal restart, ie. no uniform/time file present which would contain the original beginTime.

Managed to bisect it to this commit:
https://github.com/OpenFOAM/OpenFOAM-dev/commit/bae95b1291c14fbc408a6f5533028ee8ab61f527

I think the problem is that beginTime_ is first initialized to 0 and setWriteInterval is called in readDict using this beginTime. Later on beginTime is set properly as
beginTime_ = timeDict.lookupOrDefault("beginTime", startTime_); to be equal to non-zero startTime. But after this restart() is not true, so the writeTimeIndex_ is not updated and the invalid value set in readDict remains. Thus the first write will be "value()-0", which can be quite a big value if value is large.

Tags:
Steps To Reproduce: Take cavity tutorial, change:
startTime 0->2 (and rename the 0-folder to 2)
endTime 0.5->5
writeControl timeStep->runTime-
writeInterval 20->0.1

First write will be 4.1, not 2.1 as it should
Additional Information:
Attached Files:
Notes
(0012009)
henry   
2021-04-29 15:48   
Shall I revert the commit?
(0012010)
tniemi   
2021-04-29 16:58   
No, I think the commit is mostly fine. It is just that the logic regarding the very first writeTimeIndex_ calculation is slightly changed which breaks this one type of startup. I can perhaps provide a patch, but it is too late for today.

It should be enough to just always update writeTimeIndex_ with beginTime=startTime if no other beginTime was found. I wonder is for instance the check for restart() in line 272 necessary? If the check would be removed, I think it would fix this issue. But not sure if it would break something else.
(0012011)
henry   
2021-04-30 12:23   
Resolved by commit 6d7703bfa3467767faa3202a2d7b07cfd6bffde4


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3664 [OpenFOAM] Bug tweak always 2021-04-15 09:26 2021-04-15 12:05
Reporter: sjohn2 Platform: GNU/Linux  
Assigned To: will OS: Ubuntu  
Priority: normal OS Version: 15.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Two issues with multiphaseEulerFoam solver
Description: In file

OpenFOAM-dev/applications/solvers/multiphase/multiphaseEulerFoam/interfacialCompositionModels/interfaceCompositionModels/saturated/saturated.C

saturated model is valid only for one species, as defined in the constructor 83, hence in functions Yf and YfPrime the else statements are not required
If more than one species is specified then solver will fail at the saturated contructor

In file

OpenFOAM-dev/applications/solvers/multiphase/multiphaseEulerFoam/phaseSystems/PhaseSystems/InterfaceCompositionPhaseChangePhaseSystem/InterfaceCompositionPhaseChangePhaseSystem.C

Line 406 - *(*dmidtfSps_[pair])[specie]*phase.Y(specie)

should be replaced by + *(*dmidtfSps_[pair])[specie]*phase.Y(specie), the negative sign is already accounted for in the declaration of
*(*dmidtfSps_[pair])[specie] = - phase.rho()*KD; (line 611)

Same procedure used for dmdtfs () and dmidts ()

All lines numbers are according to the dev version in the github account
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011997)
will   
2021-04-15 12:05   
You are right about the sign, though this method is actually never used, so it doesn't affect anything. Corrected by https://github.com/OpenFOAM/OpenFOAM-dev/commit/ed5341f7f2bfd4c548eca3f5cc217329e2620c2d.

The else statements in saturated.C are necessary. You're confusing the set of all species in a phase with the subset of species that are volatile and create a non-zero interfacial fraction in an adjacent phase.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3661 [OpenFOAM] Contribution minor always 2021-04-13 12:46 2021-04-14 12:11
Reporter: dmishura Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Slow file copy routine
Description: Byte to byte copying is very slow. Code form src/OSspecific/POSIX/POSIX.C:
        // Copy character data.
        char ch;
        while (srcStream.get(ch))
        {
            destStream.put(ch);
        }

It can be rewritten as following:
        // Copy character data.

        destStream << srcStream.rdbuf();

        // Final check.

Built and checked on Linux, observed speedup up to 10x

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011992)
henry   
2021-04-13 13:04   
Under what conditions is the performance of this function an issue?
(0011993)
dmishura   
2021-04-13 13:07   
Big model with precomputed initial fields. Decomposition will take longer time in this case.
(0011995)
henry   
2021-04-14 12:11   
Resolved by commit e5dd6117b26465c4293f7e9793ba068dec58a700


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3662 [OpenFOAM] Bug minor N/A 2021-04-14 01:26 2021-04-14 11:37
Reporter: lhp 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: typo in the mixture source file in compressibleInterFoam
Description: Line 64 should be phase2Name() instead of phase1Name():

https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/applications/solvers/multiphase/compressibleInterFoam/twoPhaseMixtureThermo/twoPhaseMixtureThermo.C
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011994)
henry   
2021-04-14 11:37   
Resolved by commit bf340f02e36eb3c98359c314ad2b809b04ccf00f


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3657 [OpenFOAM] Bug text always 2021-04-08 15:09 2021-04-08 15:18
Reporter: Tiberias_ Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: none OS Version: 20.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Typo in pitzDaily tutorial
Description: In file "f" object is called "v2" in file header.

https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/tutorials/incompressible/simpleFoam/pitzDaily/0/f
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011966)
henry   
2021-04-08 15:18   
Resolved by commit 66387d3aa59a9c3ddaf949dd9cbce35bfe0e54e9


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3651 [OpenFOAM] Bug minor always 2021-03-29 23:23 2021-03-30 11:30
Reporter: jherb Platform: GNU/Linux  
Assigned To: henry OS: OpenSuSE  
Priority: normal OS Version: 12.3  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    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:
3647 [OpenFOAM] Patch major always 2021-03-24 08:48 2021-03-24 11:11
Reporter: Juho 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: multiphaseEulerFoam: linearTsub diameterModel does not find the saturationModels
Description: linearTsub diameterModel still has the old style global saturation model lookup instead of the phase pair specific saturation models used currently. Thus, the saturationModel is not found and diameter is not updated during the simulations.

Modified linearTsubDiameter attached. Changes:
- Updated to use the current phase pair specific saturation models.
- Changed subcooling sign convention to to be compatible with the default parameters
- Added default values to the read function as well
- Print selected parameters to log
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: linearTsubDiameter.C (4,884 bytes) 2021-03-24 08:48
https://bugs.openfoam.org/file_download.php?file_id=3142&type=bug
linearTsubDiameter-2.C (4,684 bytes) 2021-03-24 09:43
https://bugs.openfoam.org/file_download.php?file_id=3143&type=bug
Notes
(0011951)
will   
2021-03-24 09:20   
Thanks for the patch, Juho. Small suggestion. Is it possible to use the phase system's lookup instead? It would save doing the name manipulations manually. E.g.:

    if (phase().fluid().foundSubModel<saturationModel>(pair))
    {
        const saturationModel& satModel =
            phase().fluid().lookupSubModel<saturationModel>(pair);

        ...
    }

I'd try it myself, but I don't have a test case with this model active. I assume you do.
(0011952)
Juho   
2021-03-24 09:43   
Updated file attached. Much neater this way.
(0011953)
will   
2021-03-24 11:11   
Thanks for that. Pushed as commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/42a558a1b0596896a244ce0489545421aa6260bf


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3645 [OpenFOAM] Bug minor N/A 2021-03-21 09:48 2021-03-21 10:18
Reporter: lhp Platform: Linux  
Assigned To: henry OS: Ubuntu  
Priority: low OS Version: 20.04.2 LTS  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: I believe that there is a typo in both molecular weight definitions, thus neglecting phase2 W()
Description: The aforementioned typo is found under the following file:

$FOAM_SOLVERS/multiphase/compressibleInterFoam/twoPhaseMixtureThermo/twoPhaseMixtureThermo.C

These are the corresponding lines of code, where I believe there should be alpha2()*thermo2_->W() instead:

381 Foam::tmp<Foam::volScalarField> Foam::twoPhaseMixtureThermo::W() const
382 {
383 return alpha1()*thermo1_->W() + alpha2()*thermo1_->W();
384 }
385
386
387 Foam::tmp<Foam::scalarField> Foam::twoPhaseMixtureThermo::W
388 (
389 const label patchi
390 ) const
391 {
392 return
393 alpha1().boundaryField()[patchi]*thermo1_->W(patchi)
394 + alpha2().boundaryField()[patchi]*thermo1_->W(patchi);
395 }

If this is the case for a fix, please have a look at the dev branch as well.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011948)
henry   
2021-03-21 10:13   
Resolved in OpenFOAM-8 by commit 8fc255467d794e0f6e6fcab4113472ae6f782c13
Resolved in OpenFOAM-dev by commit 8ec5eac35e6bc608a69f05e87d34a0ee1370d74c


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3642 [OpenFOAM] Bug major always 2021-03-15 02:47 2021-03-15 10:44
Reporter: CyprienR Platform: GNU/Linux Ubuntu 18.04  
Assigned To: henry OS: Linux  
Priority: high OS Version: Ubuntu 18.04  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: Sigma XX values for plateHole Case in UserGuide are not correct
Description: With OpenFoam 8, I followed the steps mentioned in the user guide for the stress analysis of a plate with hole:
https://cfd.direct/openfoam/user-guide/v8-plateHole/#x6-390002.2

I didn't change anything, I just:
- copied the case into my $FOAM_RUN
- Generated the mesh with blockMesh
- Run the solver with solidDisplacementFoam

The maximum sigma xx stress obtained for the time step 100 is 2.5e8 Pa.
The image from the user guide shows a maximum value of 3e4 Pa (30 kPa)

I tried to come back to an earlier value of OpenFoam and recalculated with OpenFoam v5
Results come as in the user guide with the v5

Seems like something has changed in the v8
Either the Case need to be updated or there is a bug somewhere in the solidDisplacementFoam Solver

Tags:
Steps To Reproduce: - copy the case into my $FOAM_RUN
- Generated the mesh with blockMesh
- Run the solver with solidDisplacementFoam
Additional Information:
System Description
Attached Files: plateHole op8.png (43,285 bytes) 2021-03-15 02:47
https://bugs.openfoam.org/file_download.php?file_id=3140&type=bug
plateHole op5.png (54,474 bytes) 2021-03-15 02:47
https://bugs.openfoam.org/file_download.php?file_id=3141&type=bug
Notes
(0011941)
henry   
2021-03-15 10:44   
Resolved in OpenFOAM-8 by commit 1c9b5879390b09ea0320e98800aca0974dfcdc41
Resolved in OpenFOAM-dev by commit 84103902acc3af7967672daf16ac185cf2089479


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3638 [OpenFOAM] Bug minor always 2021-03-07 11:26 2021-03-08 09:34
Reporter: gskillas Platform: GNU/Linux  
Assigned To: henry OS: OpenSUSE Leap  
Priority: normal OS Version: 15.2  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: snappyHexMesh fails to compile
Description: snappyHexMesh.C: In function ‘int main(int, char**)’:
snappyHexMesh.C:735:76: error: no matching function for call to ‘Foam::IOdictionary::IOdictionary(Foam::dictionary)’
     const IOdictionary meshDict(systemDict("snappyHexMeshDict", args, mesh));
                                                                            ^
In file included from /home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/Time.H:43:0,
                 from snappyHexMesh.C:33:
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:93:9: note: candidate: Foam::IOdictionary::IOdictionary(Foam::IOdictionary&&)
         IOdictionary(IOdictionary&&);
         ^~~~~~~~~~~~
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:93:9: note: no known conversion for argument 1 from ‘Foam::dictionary’ to ‘Foam::IOdictionary&&’
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:90:9: note: candidate: Foam::IOdictionary::IOdictionary(const Foam::IOdictionary&)
         IOdictionary(const IOdictionary&);
         ^~~~~~~~~~~~
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:90:9: note: no known conversion for argument 1 from ‘Foam::dictionary’ to ‘const Foam::IOdictionary&’
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:87:9: note: candidate: Foam::IOdictionary::IOdictionary(const Foam::IOobject&, Foam::Istream&)
         IOdictionary(const IOobject&, Istream&);
         ^~~~~~~~~~~~
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:87:9: note: candidate expects 2 arguments, 1 provided
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:84:9: note: candidate: Foam::IOdictionary::IOdictionary(const Foam::IOobject&, const Foam::dictionary&)
         IOdictionary(const IOobject&, const dictionary&);
         ^~~~~~~~~~~~
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:84:9: note: candidate expects 2 arguments, 1 provided
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:81:9: note: candidate: Foam::IOdictionary::IOdictionary(const Foam::IOobject&)
         IOdictionary(const IOobject&);
         ^~~~~~~~~~~~
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:81:9: note: no known conversion for argument 1 from ‘Foam::dictionary’ to ‘const Foam::IOobject&’
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:65:9: note: candidate: Foam::IOdictionary::IOdictionary(const Foam::IOobject&, const Foam::word&)
         IOdictionary(const IOobject& io, const word& wantedType);
         ^~~~~~~~~~~~
/home/cfd/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude/IOdictionary.H:65:9: note: candidate expects 2 arguments, 1 provided
make[2]: *** [/home/cfd/OpenFOAM/OpenFOAM-dev/wmake/rules/General/transform:26: /home/cfd/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/applications/utilities/mesh/generation/snappyHexMesh/snappyHexMesh.o] Error 1
make[1]: *** [/home/cfd/OpenFOAM/OpenFOAM-dev/wmake/makefiles/apps:39: generation] Error 2
make: *** [/home/cfd/OpenFOAM/OpenFOAM-dev/wmake/makefiles/apps:39: mesh] Error 2
cfd@chalki ~/OpenFOAM/OpenFOAM-dev > cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.2"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.2"
PRETTY_NAME="openSUSE Leap 15.2"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.2"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
cfd@chalki ~/OpenFOAM/OpenFOAM-dev > git pull
Already up to date.
Tags:
Steps To Reproduce: Both fail

> git pull
> ./Allwmake -update

> wcleanPlatform
> git pull
> ./Allwmake
Additional Information:
System Description
Attached Files:
Notes
(0011925)
henry   
2021-03-07 12:09   
I am unable to reproduce this problem, everything is compiling fine with gcc and clang. What gcc version are you using and which have you tried?
(0011926)
henry   
2021-03-07 12:12   
I tested and older gcc version and reproduced the problem, try with

commit a28fd5552f63757bb90cc8c03e779a96aaaa53a0 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Sun Mar 7 12:11:39 2021 +0000

    systemDict: Changed return to IOdictionary


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3636 [OpenFOAM] Bug tweak always 2021-03-05 08:09 2021-03-05 15:26
Reporter: peksa Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: low OS Version: 15.04  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Use of mesh.dynamic() may return false even if mesh.moving() returns true
Description: Dear developers,

First, this is not a bug as such, but I'm reporting the finding to prevent future bugs in mesh motion context.

I have been developing a rather specific solver which has actually a similar layout to engineMesh class and incorporates a simple mesh motion step, similar to 'layered' method in engine class. In other words, no dynamicMesh class is generated but movePoints() is called for the original mesh.

When such an approach is used together with e.g. recent pressure equation formulation where "fvc::correctRhoUf" is called, one finds that the correction is never reached because it is guarded by a if(mesh.dynamic()) condition which does not hold true in this rather specific case.

In order to reach better consistency and to avoid potential bugs related to e.g. engineFoam, one should incorporate mesh.moving() as a condition to such mesh motion checks.

Best regards,
-peksa
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: freePiston_mod.tar.gz (270,347 bytes) 2021-03-05 13:01
https://bugs.openfoam.org/file_download.php?file_id=3137&type=bug
Notes
(0011908)
henry   
2021-03-05 08:22   
It is not clear what code you want changed.
(0011909)
peksa   
2021-03-05 08:51   
fvc::correctRhoUf() function was the one from which I realised this discrepancy but probably it appears elsewhere as well. In other words, because mesh.dynamic() returns false, that rhoUf correction may not be executed even though mesh has actually moved by explicit movePoints() command outside dynamicMesh class.

Particular action: change mesh.dynamic() --> mesh.moving() in fvc::correctRhoUf()
(0011910)
henry   
2021-03-05 09:06   
> Particular action: change mesh.dynamic() --> mesh.moving() in fvc::correctRhoUf()

It is necessary to know that the mesh will move rather than it has moved which is why "mesh.dynamic() " is used here rather than "mesh.moving()" which is not true until the motion has occurred.
(0011911)
peksa   
2021-03-05 09:48   
That's a good point! Perhaps a combination (mesh.dynamic() || mesh.moving()) would be relevant? In the end this is a problem only if there is any implementation deforming the mesh outside dynamicMesh class. At the moment I don't see anything else than the engine class doing that so we're safe in that regard.
(0011912)
henry   
2021-03-05 10:00   
The purpose of the 'mesh.dynamic()' method is to declare that the mesh might change. Can you please provide a simple test-case which demonstrates the problem? Without it I cannot work on this any further as we have no cases showing any problem with 'mesh.dynamic()'.
(0011913)
peksa   
2021-03-05 13:01   
Ok, I came up with somewhat an example case by combining freePiston and aachenBomb tutorials. Case is attached. The idea is that if you run this with coldEngineFoam, the solver will consider the "rhoUf" correction and its found from the results folders. However, if you run the case with "engineFoam" which utilises "createRhoUfIfPresent.H" and pEqn.H from sprayFoam solver, this correction is NOT carried out and you can't find the rhoUf field either because mesh.dynamic() guard prevents its creation and usage in the corresponding "createRhoUfIfPresent.H" and "pEqn.H" files.

In this particular case, both solutions run without crash but this just highlights the inconsistent behaviour.
(0011914)
henry   
2021-03-05 13:31   
I have just downloaded the case and run it and I see no problem, what do I need to do to is to see a problem?
(0011915)
henry   
2021-03-05 13:37   
Try with

commit d4d21c9c04958b373904f1363770cab5b4386219 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Fri Mar 5 13:36:06 2021 +0000

    engineMesh: Added dynamic() member function
(0011916)
peksa   
2021-03-05 14:52   
Hey,

Yes, there was not supposed to be any "problems" but the case was just to indicate the missing rhoUf, which may lead into severe problems in certain cases as I myself experienced lately in a more complicated case.

Regarding the commit, yes, it fixes the issue with the engineMesh class and I'm satisfied with it. Now this discussion and that commit serves as an example for other users/developers that dynamic() virtual function should be implemented whenever you deal with mesh motion outside dynamicMesh class.

Have a nice weekend.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3634 [OpenFOAM] Bug major always 2021-02-24 09:54 2021-02-25 21:47
Reporter: federico Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 14.04  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: multiphaseEulerFoam does not reproduce the analytical solution for the Sod Shock tube problem
Description: multiphaseEulerFoam (OpenFOAM 8) is not reproducing the exact solution for the single phase Sod shock tube benchmark. In particular, the temperature field is significantly different (see figure). This issue is not observed in older OpenFOAM versions. TwoPhaseEulerFoam is not presenting this problem and reactingEulerFoam is affected since OpenFOAM 6.

Please find attached the results for the test performed with different OpenFOAM versions ( dashed line representing the exact solution). The “first bad commit” is also reported in the “Additional information” section.

Summary for reactingTwoPhaseEulerFoam:
OF-4 - ok.
OF-5 - convergence issue (easily solved just re-adding fluid.correct() at the beginning of the loop in pEqn.H). Then the solution is ok.
OF-6 - not good (higher temperature)
OF-7 - not good (higher temperature)
OF-8 - multiphasePhaseEulerFoam: not good (higher temperature)
Tags:
Steps To Reproduce: 1- Enter Sod shock tube test case for OF8 (multiphaseEulerFoam) or OF<=7 (reactingTwoPhaseEulerFoam). The analytical solution is also included. For OF<=5 change the phase system in constant/phaseProperties dict.

2- ./Allclean; ./Allrun

3- paraview -> load state file -> ParaviewState/vsAnalytical.pvsm (paraview version
5.0-5.6)

4- select “thermo:rho.gas” and click “apply” to check gas density
Additional Information: This issue/bug is first observed with the following commit (found with “git bisect”):
 
commit e352828514abe029065d8032ec78516c980a7a2d
Date: Thu Mar 22 11:36:43 2018 +0000

    reactingMultiphaseEulerFoam: Stationary phase

            Two new phase models have been added as selectable options for
    reactingMultiphaseEulerFoam; pureStationaryPhaseModel ...
System Description
Attached Files: SodShockTube-Issue.zip (710,467 bytes) 2021-02-24 09:54
https://bugs.openfoam.org/file_download.php?file_id=3131&type=bug
SodSchock_OF8_multiphase.png (54,352 bytes) 2021-02-24 09:54
https://bugs.openfoam.org/file_download.php?file_id=3132&type=bug
SodSchock_OF7_twoPhase.png (56,511 bytes) 2021-02-24 09:54
https://bugs.openfoam.org/file_download.php?file_id=3133&type=bug
SodSchock_OF7_reactingTwoPhase.png (53,288 bytes) 2021-02-24 09:54
https://bugs.openfoam.org/file_download.php?file_id=3134&type=bug
SodSchock_OF4_reactingTwophase.png (70,003 bytes) 2021-02-24 09:54
https://bugs.openfoam.org/file_download.php?file_id=3135&type=bug
SodShock_OF8-updated_multiphaseEulerFoam.png (67,043 bytes) 2021-02-25 21:33
https://bugs.openfoam.org/file_download.php?file_id=3136&type=bug
Notes
(0011897)
henry   
2021-02-24 15:40   
Thanks for the detailed bug-report, this should now be fixed in OpenFOAM-dev:

commit a060c63235710dcebdb33fc8601ecab7bf7ba0fb (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Wed Feb 24 15:37:28 2021 +0000

    multiphaseEulerFoam: Corrected handling of K for energy equation
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3634
(0011898)
henry   
2021-02-24 19:03   
I have also pushed the fix to OpenFOAM-8: commit 078af2d2d26518a6e5e4a75cb26308959db04e8c
(0011900)
henry   
2021-02-25 18:32   
I have compiled OpenFOAM-dev with gcc and clang and see no problems.
(0011901)
federico   
2021-02-25 21:33   
I confirm that this bug is solved with OpenFOAM-8 updated at

commit: 078af2d2d26518a6e5e4a75cb26308959db04e8c
multiphaseEulerFoam: Corrected handling of K for energy equation

thank you very much for your prompt replay !


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3631 [OpenFOAM] Bug minor always 2021-02-17 12:22 2021-02-17 15:19
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: Damping fvOptions, selectionMode not working?
Description: I was reading through the recent changes to fvOptions and happened to notice that while the damping fvOptions are derived from cellSetOption and supposedly can act only on a certain selection, they don't seem to contain any code handling the situation where not all cells are chosen. For example, there is no forAll(cells(), ... loop like in some other fvOptions derived from cellSetOption.

To double check, I took the wave tutorial and made a cellSet with 0 cells and pointed the damping to that set, but it did not change the results compared to "selectionMode all".

I have not personally used these options and I'm not sure what would be the best fix. A simple fix might be to modify the add-functions to only operate on cells within the cells()-list.

Other misc notes:

Documentation for addSup-fuctions refer to momentum equation, although these are for enthalpy equation
https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/src/fvOptions/sources/derived/buoyancyEnergy/buoyancyEnergy.H
https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/src/radiationModels/fvOptions/radiation/radiation.H
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011887)
tniemi   
2021-02-17 12:25   
To add: by damping fvOptions I'm referring to is
https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/src/fvOptions/sources/derived/damping/isotropicDamping/isotropicDamping.H

and the wave tutorial is
https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/tutorials/multiphase/interFoam/laminar/wave/
(0011888)
henry   
2021-02-17 12:41   
The simplest fix would be to not derive from cellSetOption.
(0011889)
tniemi   
2021-02-17 12:48   
Yes, that is true. I would also guess that by using suitable non-uniform scale, it should be possible to emulate localized damping.
(0011890)
henry   
2021-02-17 15:19   
Resolved by commit a24e8e463ad0703b695295da9f4b222a9cc0d21b


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3627 [OpenFOAM] Bug minor always 2021-02-12 08:52 2021-02-12 11:08
Reporter: deo Platform: Linux  
Assigned To: will OS: RHEL  
Priority: normal OS Version: 8.3  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Default value of C1 in Prince & Blanch model is wrong
Description: The default value for C1 in applications/solvers/multiphase/multiphaseEulerFoam/phaseSystems/populationBalanceModel/coalescenceModels/PrinceBlanch/PrinceBlanch.C is 0.356. However, the default value in the header file is said to be 0.089. Looking at the Prince & Blanch (1990) paper, the value should be 0.089.

In the two tutorial cases which use the Prince & Blanch model (wallBoilingPolydisperse and wallBoilingPolydisperseTwoGroups), the value for C1 is set to 0.1, such that the default value is not used.
Tags:
Steps To Reproduce: n/a
Additional Information:
System Description
Attached Files: 0001-Corrected-header-documentation-of-PrinceBlanch-coale.patch.tar.gz (1,850 bytes) 2021-02-12 10:05
https://bugs.openfoam.org/file_download.php?file_id=3130&type=bug
Notes
(0011877)
oertel59   
2021-02-12 10:05   
Thanks for reporting. It is only the code documentation that is wrong. Equation 2 in the paper contains an error. It should use the diameter rather than the radius for computing the collision cross-section. This error extends to equation 8, where the coefficient that is also referred to in the header is off by a factor of 4.

The documentation is updated in the attached patch, the implementation should be correct. The tutorials are ok too by extension.
(0011878)
will   
2021-02-12 11:08   
Thanks for the patch, Ronald. Resolved in dev by:

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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3626 [OpenFOAM] Bug minor always 2021-02-12 02:30 2021-02-12 09:46
Reporter: dscian 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: 8  
    Target Version:  
Summary: Search for alphac as volVectorField in DenseDragForce
Description: in cacheFields() function of DenseDragForce, there is a search for alphac as volVectorField, causing it to never be found. (Line 90, DenseDragForce.C)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011873)
will   
2021-02-12 08:36   
(Last edited: 2021-02-12 08:36)
Tutorials with dense drag models are operating correctly, as far as I can see.

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

(0011874)
dscian   
2021-02-12 09:34   
Apologize for opening the report as a bug because this is trivial. It does not affect the outcome since alphac is looked up afterwards independent of this if statement. It's just that the if statement will always be running because alphac is not a volVectorField, and the computation for "this->owner().theta()" is redundant. I couldn't also see where else alphacPtr_ is used.

To reproduce the issue, I tested it by placing "Info <<" statement inside the if statement with volVectorField and volScalarField in line 90. volScalarField skips the if statement.
(0011875)
will   
2021-02-12 09:41   
Apologies. Yes I see the issue now. You are correct. It should be volScalarField. It doesn't cause an error, because the lookup failure just means the field gets re-generated, but it is missing a potential optimisation.

Fixed in dev by the following commit.

https://github.com/OpenFOAM/OpenFOAM-dev/commit/0f04dd04c6b0eacf92ec77ae3e2bbeb20cf54f5c
(0011876)
will   
2021-02-12 09:45   
And fixed in 8 by:

https://github.com/OpenFOAM/OpenFOAM-8/commit/0f3c9c49f485f0d127ffaebf622a0a5f330d326b


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3625 [OpenFOAM] Bug text always 2021-02-09 09:14 2021-02-09 09:57
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: foamSearch, help-text uses dot syntax instead of slash
Description: The usage text for foamSearch uses dot-syntax, like "foamSearch $FOAM_TUTORIALS fvSchemes ddtSchemes.default", but with the new default slash syntax this should be "foamSearch $FOAM_TUTORIALS fvSchemes ddtSchemes/default".

So ddtSchemes.default -> ddtSchemes/default and relaxationFactors.equations.U -> relaxationFactors/equations/U
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011870)
henry   
2021-02-09 09:57   
Resolved by commit e36a9475f9507e68a7642ab45330e3b8f5c28d4e


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3624 [OpenFOAM] Bug major always 2021-02-08 18:31 2021-02-08 19:49
Reporter: mboesi Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: The reference to the pressure field is initialized by the temperature field in the MaxwellStefan and Fickian diffusion models.
Description: When correcting the MaxwellStefan diffusion model, the temperature field reference is used instead of the pressure field reference when creating the const volScalarField& p variable in line 608:

608 const volScalarField& p = this->thermo().T();
609 const volScalarField& T = this->thermo().T();

of the MaxewellStefan.C file.

The same issue occurs in the Fickan.C at line 468
Tags:
Steps To Reproduce:
Additional Information: I've added corrected versions of both files to the report.
Attached Files: MaxwellStefan.C (18,501 bytes) 2021-02-08 18:31
https://bugs.openfoam.org/file_download.php?file_id=3128&type=bug
Fickian.C (14,547 bytes) 2021-02-08 18:31
https://bugs.openfoam.org/file_download.php?file_id=3129&type=bug
Notes
(0011869)
henry   
2021-02-08 19:49   
Resolved by commit aa852124e3c7933a0e9a9b15763c497f67b038f0


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3622 [OpenFOAM] Bug minor always 2021-02-04 16:16 2021-02-04 17:06
Reporter: marniemann Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu 18.04  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: Variable caluclation fails for divisions
Description: Calculating variables using the #calc statement fails for divisions, if the slash operator is not separated by spaces.
Example:

a 1;
b 2;
c #calc "$a / $b"; // works
d #calc "$a+$b"; // works
e #calc "$a/$b"; // does NOT work

The last statement to compute variable e leads to a declaration error: ‘$a’ was not declared in this scope
Since the last statement was still valid in OpenFOAM-6, I assume (but am not sure) that the issue might stem from this new feature:
https://github.com/OpenFOAM/OpenFOAM-dev/commit/a7b842569064ede1574a77210b731904a206182a
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011843)
henry   
2021-02-04 17:05   
I have updated the documentation for #calc:

Class
    Foam::functionEntries::calcEntry

Description
    Uses dynamic compilation to provide calculating functionality
    for entering dictionary entries.

    E.g.

    \verbatim
    a 1.0;
    b 3;
    c #calc "$a*$b";
    \endverbatim

    Note the explicit trailing 0 ('1.0') to force a to be read (and written)
    as a floating point number.

    Special care is required for calc entries that include a division since
    "/" is also used as the scoping operator to identify keywords in
    sub-dictionaries. For example, "$a/b" expects a keyword "b" within a
    sub-dictionary named "a". A division can be correctly executed by using a
    space between a variables and "/", e.g.

    \verbatim
    c #calc "$a / $b";
    \endverbatim

    or "()" scoping around the variable, e.g.

    \verbatim
    c #calc "($a)/$b";
    \endverbatim
(0011844)
henry   
2021-02-04 17:06   
Resolved by commit 2d9c05f8cb5d52a35dc7068c5d268d8b995d9f95


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3617 [OpenFOAM] Bug major always 2021-01-25 08:45 2021-01-25 11:02
Reporter: jeigemann Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Calculation of psiu and muu in heheuPsiThermo.C uses false temperature reference
Description: In version 8 (and dev) the calculation of psiu and muu uses T as the temperature field instead of Tu, leading to wrong results for solvers using psiuReactionThermo, e.g. XiFoam. For the 'moriyoshiHomogeneous' turorial case this leads to wildly varying combustion progress at the end of the run, with <1 % for version 8 and ~40.5 % for version 7.
Tags:
Steps To Reproduce: Run the 'moriyoshiHomogeneous' turorial case with XiFoam in version 7 and 8. The difference in combustion progress is visible in the log.
Additional Information: Further analysis showed that heheuPsiThermo.C uses different Temperature fields to calculate psiu and muu in version 8 vs 7, namely T instead of Tu. Modifying version 8 to use Tu for the calculation of psiu and muu leads to approximately equal combustion progress of ~40.5 % for both versions (see attached log files).
Attached Files: log_v7.gz (308,461 bytes) 2021-01-25 08:45
https://bugs.openfoam.org/file_download.php?file_id=3121&type=bug
log_v8.gz (299,085 bytes) 2021-01-25 08:45
https://bugs.openfoam.org/file_download.php?file_id=3122&type=bug
log_v8_Mod.gz (308,489 bytes) 2021-01-25 08:45
https://bugs.openfoam.org/file_download.php?file_id=3123&type=bug
Notes
(0011826)
henry   
2021-01-25 10:59   
(Last edited: 2021-01-25 11:02)
Thanks for reporting, resolved in

OpenFOAM-dev by commit e901e84eb2da0ccf11d613838bb601265bf35e51
OpenFOAM-8 by commit e0f23cae73e02928574507ff425518aedbc6ea5f



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3613 [OpenFOAM] Bug crash always 2021-01-14 07:37 2021-01-15 09:53
Reporter: jtriesch 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: setFields breaks some time-varying boundary conditions, i.e. falsely replacing dictionary keyword
Description: When using setFields with some time-varying boundary conditions (e.g., sine), the 'amplitude' dictionary entry is falsely replaced by multiple keyword 'value' entries in '0' folder. This breaks the required keyword entries for subsequent solver runs. Apparently this does not affect the 'coded' BC used in the examples below.
Tags:
Steps To Reproduce: Run the modified 'pitzDailyPulse' tutorial cases attached to this report.
1. Added runApplication setFields to 'Allrun'
2. Added setFields dictionary to 'system' folder
3. Modified p -> boundaryField -> outlet -> type (e.g. uniformFixedValue etc, see examples)
4. Execute 'Allrun' for various cases

Case with uniformFixedValue and 'type sine' fails with 'keyword amplitude is undefined in dictionary' message (see attached log files).
Additional Information: I suspect this issue has been introduced to OpenFOAM-dev sometime between 6-Oct-2020 and 13-Jan-2021.
System Description
Attached Files: log.blockMesh (3,254 bytes) 2021-01-14 07:37
https://bugs.openfoam.org/file_download.php?file_id=3112&type=bug
log.pimpleFoam (1,688 bytes) 2021-01-14 07:37
https://bugs.openfoam.org/file_download.php?file_id=3113&type=bug
log.setFields (2,007 bytes) 2021-01-14 07:37
https://bugs.openfoam.org/file_download.php?file_id=3114&type=bug
setFields_tests.tar.gz (2,973 bytes) 2021-01-14 07:37
https://bugs.openfoam.org/file_download.php?file_id=3115&type=bug
Notes
(0011814)
henry   
2021-01-14 10:55   
Thanks for the clear and detailed bug-report, with this it was easy to find the issue.

Try commit c6f69e7987d4ca2e4cd6f75fdcba074f6cc39fb1
(0011820)
jtriesch   
2021-01-15 06:38   
Thanks for the fast fix. I confirm this issue is solved for me.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3610 [OpenFOAM] Bug text always 2021-01-07 19:40 2021-01-08 13:42
Reporter: Tiberias_ Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: none OS Version: 20.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: foamMonitor small spelling mistake
Description: foamMonitor if file is missing:

"File residuals.dat does not exit."

bash script line number 154.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011808)
henry   
2021-01-08 13:42   
Resolved by commit 476bce93cea3f495555af3cd8f448f560ca4f272


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3609 [OpenFOAM] Feature trivial always 2021-01-07 19:27 2021-01-08 13:21
Reporter: Tiberias_ Platform: Unix  
Assigned To: henry OS: Ubuntu  
Priority: none OS Version: 20.04  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: Included y+ function object doesnt show realtime values in simulation log
Description: In controlDict I have included the yPlus function by:

functions
{
    #includeFunc residuals
    #includeFunc yPlus
}

For running simpleFoam for example I have a writeInterval of 10.
In Version 7 of OpenFOAM I got the current yPlus values during simulation at the point of timestep writing.

For example:

[...]
Time = 10

DILUPBiCGStab: Solving for Ux, Initial residual = 0.2159051, Final residual = 0.001826788, No Iterations 4
DILUPBiCGStab: Solving for Uy, Initial residual = 0.06784772, Final residual = 0.0002873746, No Iterations 5
DILUPBiCGStab: Solving for Uz, Initial residual = 0.1879635, Final residual = 0.0016049, No Iterations 4
DICPCG: Solving for p, Initial residual = 0.0353227, Final residual = 0.0003407865, No Iterations 46
DICPCG: Solving for p, Initial residual = 0.002074315, Final residual = 1.987197e-05, No Iterations 106
time step continuity errors : sum local = 0.0016527, global = 0.0001161923, cumulative = -0.001386994
DILUPBiCGStab: Solving for omega, Initial residual = 0.0134613, Final residual = 9.790165e-05, No Iterations 2
DILUPBiCGStab: Solving for k, Initial residual = 0.03926103, Final residual = 0.0001613133, No Iterations 2
bounding k, min: -6.874777e-06 max: 63.89042 average: 0.05916318
ExecutionTime = 152.19 s ClockTime = 158 s

yPlus yPlus write:
    writing object yPlus
    patch minZ y+ : min = 3.509461, max = 1217.934, average = 298.061
    patch wall y+ : min = 0.1989935, max = 129.9126, average = 4.696098

Time = 11

CDILUPBiCGStab: Solving for Ux, Initial residual = 0.1944093, Final residual = 0.001118355, No Iterations 5
[...]

Since Version 8 this information doesnt appear anymore. It´s just an inconspicuous feature but it was helpful for investigating the progress of simulation.
I am not that good at coding, I couldn´t find out if it´s a deliberate change or a bug.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0011801)
henry   
2021-01-07 19:50   
Logging is now optional:

    #includeFunc yPlus(log=true)
(0011802)
Tiberias_   
2021-01-07 19:55   
I didn't noticed that change for optional logging, tried it out and works.
Thank you!
(0011803)
Tiberias_   
2021-01-07 20:09   
Maybe it could be helpful to add this optional logging information to the yPlus Header.
Something like:

        Property | Description | Required | Default value
        type | type name: yPlus | yes |
        phase | phase name | no | none
        log | write yPlus data to standard output | no | no
(0011804)
henry   
2021-01-07 20:42   
It is a generic control applicable to all functionObjects documented in the base-class:

Description
    Namespace for functionObjects.

    OpenFOAM includes a collection of functionObjects selected by the user at
    run-time to manipulate the simulation and provide mechanisms to extract
    field and derived quantities. Alternatively, the same actions can be
    executed after the simulation using the \c -postProcess command-line option.

    \subsection secFunctionObjects Using functionObjects

    FunctionObjects are selected by additional entries in the
    $FOAM_CASE/system/controlDict dictionary. Each object is listed in the \c
    functions sub-dictionary, e.g. to select the \c functionObjectType
    functionObject the following entry would be specified:

    \verbatim
    functions
    {
        <functionObjectName>
        {
            type functionObjectType;
            libs ("libMyFunctionObjectlib.so");
            region defaultRegion;
            enabled yes;
            startTime 0;
            endTime 10;
            writeControl writeTime;
            writeInterval 1;
            ...
        }
    }
    \endverbatim

    Where:
    \table
        Property | Description | Required | Default value
        type | Type of functionObject | yes |
        libs | Libraries containing implementation | yes |
        region | Name of region for multi-region cases | no |
        enabled | On/off switch | no | yes
        log | Log information to standard output | no | yes
        startTime| Start time | no |
        endTime | End time | no |
        executeAtStart | Execute at start time switch | no | yes
        executeControl | See time controls below | no | timeStep
        executeInterval | Steps between each execute phase | no |
        writeControl | See time controls below | no | timeStep
        writeInterval | Steps between each write phase | no |
    \endtable

    Time controls:
    \table
        Option | Description
        timeStep | Execute/write every 'Interval' time-steps
        writeTime | Execute/write every 'Interval' output times
        adjustableRunTime | Execute/write every 'Interval' run time period
        runTime | Execute/write every 'Interval' run time period
        clockTime | Execute/write every 'Interval' clock time period
        cpuTime | Execute/write every 'Interval' CPU time period
        none | Execute/write every time-step
    \endtable

    The sub-dictionary name \c \<functionObjectName\> is chosen by the user, and
    is typically used as the name of the output directory for any data written
    by the functionObject. The \c type entry defines the type of function
    object properties that follow. FunctionObjects are packaged into separate
    libraries and the \c libs entry is used to specify which library should be
    loaded.

    Each functionObject has two separate run phases:

      - The \c execute phase is meant to be used for updating calculations
        or for management tasks.
      - The \c write phase is meant for writing the calculated data to disk.

    For each phase the respective time controls are provided, as listed above.

Class
    Foam::functionObject

Description
    Abstract base-class for Time/database functionObjects.

See also
    Foam::functionObjectList
    Foam::functionObjects::timeControl

SourceFiles
    functionObject.C
(0011805)
Tiberias_   
2021-01-07 21:14   
I see, that is what I was looking for.

Just a little thing: The properties table says that the default value for log is yes, is this information still up-to-date? As far as I have seen now the function object yPlus has the default value "no", I also tried forceCoeffs, same behaviour.
(0011806)
henry   
2021-01-07 21:49   
The default is "no" I will correct the documentation.
(0011807)
henry   
2021-01-08 13:21   
Resolved in OpenFOAM-8 by commit 2827872a22fa783f8d9cbe9c9f45792457b0039e
Resolved in OpenFOAM-dev by commit 0b21dbf1ec051280b79665687c3958c562991d13


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3607 [OpenFOAM] Bug minor always 2020-12-16 08:06 2020-12-31 09:14
Reporter: dr.elia.daniele Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04 LTS  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: foamDictionary entry0 querying
Description: A FOAM FATAL IO ERROR is reported when trying to query a deeper level feature of a boundary file dict by accessing to entry0 as reported in https://cpp.openfoam.org/v8/foamDictionary_8C.html in the Change patch type bullet point.
Tags:
Steps To Reproduce: Being in tutorials/incompressible/icoFoam/cavity/cavity, display the boundary dict file content as follows:

foamDictionary constant/polyMesh/boundary -entry entry0 -value

Reproduce the error as follows:

foamDictionary constant/polyMesh/boundary -entry entry0.movingWall -value
Additional Information:
System Description
Attached Files:
Notes
(0011797)
henry   
2020-12-16 08:37   
The online documentation is currently not up to date on this point. The default dictionary syntax is now slash rather than dot, so you need to use

foamDictionary constant/polyMesh/boundary -entry entry0/movingWall -value
(0011798)
henry   
2020-12-16 08:52   
(Last edited: 2020-12-16 08:53)
You can access the latest documentation for foamDictionary using

foamInfo foamDictionary

(0011799)
dr.elia.daniele   
2020-12-24 08:35   
Hi Henry, thanks for the clarification.
(0011800)
henry   
2020-12-31 09:14   
The online documentation for OpenFOAM-dev has now been updated to include examples of the dictionary 'slash' syntax: https://cpp.openfoam.org/dev/foamDictionary_8C.html


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3605 [OpenFOAM] Bug minor always 2020-12-06 21:43 2020-12-06 22:21
Reporter: gskillas Platform: openSUSE  
Assigned To: henry OS: Leap  
Priority: normal OS Version: 15.2  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Solver compressibleInterFoam does not work with "prgh.*Pressure" BCs
Description: Hello,

I am trying to use compressibleInterFoam with a total pressure BC. This BC needs a specification of density (it reports so when rho is omitted in the BC specification). When I add

rho thermo:rho;

to the BC specification in 0/p_rgh.orig it still fails reporting that it cannot find rho in the database; Also (minor) foamInfo does not produce any result for prghPressure and
prghTotalPressure.

Best regards,

George
Tags:
Steps To Reproduce: Take the compressibleInterFoam tutorial and replace one BC with prghTotalPressure. It will fail during the first iteration.
Additional Information:
System Description
Attached Files:
Notes
(0011790)
henry   
2020-12-06 22:21   
Resolved by commit b43dac58f53bdfe17d375f89a76c44b78f6312e1


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3602 [OpenFOAM] Bug minor always 2020-11-26 15:16 2020-12-02 11:11
Reporter: rrossi Platform: Linux 64bit  
Assigned To: will OS: Centos  
Priority: none OS Version: Centos7  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Potential degradation/issue/bug in snappyHexMesh when using cyclic patches
Description: I came across this (potential) change in behavior in snappyHexMesh when trying to mesh a pipe with some components inside where inlet and outlet patches have to be periodic.

The original mesh was created some years ago with the 2.1.1 release by specifying the inlet and outlet patches of the pipe as cyclic in blockMeshDict. The mesh was then created successfully by snappy including layers.

If the same procedure is used with the any higher version, including the latest 8.0, the mesh resulting from the snap phase is completely distorted.

The picture attached shows the castellated mesh and the snapped mesh, 2.1.1 on the left and 8.0 on the right.

Attached is the test case. To replicate:

1. foamCleanPolyMesh
2. blockMesh
3. snappyHexMesh
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: castellated.png (1,225,547 bytes) 2020-11-26 15:16
https://bugs.openfoam.org/file_download.php?file_id=3095&type=bug
snapped.png (1,156,811 bytes) 2020-11-26 15:16
https://bugs.openfoam.org/file_download.php?file_id=3096&type=bug
test.tgz (970,182 bytes) 2020-11-26 15:16
https://bugs.openfoam.org/file_download.php?file_id=3097&type=bug
snappyDictLatest.png (722,610 bytes) 2020-11-26 15:53
https://bugs.openfoam.org/file_download.php?file_id=3098&type=bug
Untitled.png (254,729 bytes) 2020-11-30 17:37
https://bugs.openfoam.org/file_download.php?file_id=3100&type=bug
Notes
(0011762)
henry   
2020-11-26 15:27   
It looks like the snappyHexMeshDict settings are not appropriate for OpenFOAM-8/dev, have you tried refining the edges more?
We could look into this in detail and provide better settings but this would be user-support which requires funding.
(0011763)
rrossi   
2020-11-26 15:53   
This is the result with the snappyHexMeshDict from 8.0 motorbike tutorial.

Features refinement does not help.

In my humble opinion, with the 2.1.1 working with no issues (in serial execution) this is more likely a regression.
(0011764)
rrossi   
2020-11-26 16:01   
also meshQualityDict from 8.0 motorbike
(0011765)
henry   
2020-11-26 16:08   
The motorbike snappyHexMeshDict is optimised for the motorbike, it is very unlikely to be optimal for your case.

> In my humble opinion, with the 2.1.1 working with no issues (in serial execution) this is more likely a regression.

Can you show which changes are causing the problem and what the consequence is of reverting them?
(0011766)
rrossi   
2020-11-26 16:12   
> Can you show which changes are causing the problem and what the consequence is of reverting them?

Not sure I understand what you mean. Which changes are you referring to?
(0011767)
henry   
2020-11-26 16:15   
You suggest that the issue "is more likely a regression", what "regression", i.e. what changes between 2.1.1 and 8 do you think should be reverted and what is the consequence for other cases?
(0011768)
rrossi   
2020-11-26 16:25   
That I don't know of course because I'm not involved in the development of snappy and would be quite hard for me to debugging it and that's why I brought this to your attention.

The reason why I'm saying it could (conditional) potential regression (as mentioned in the title) it's just because the older release handles it regardless of the snappyHexMeshDict (flange, motorbike, etc) and optimal parameters, which again in my humble opinion is a step back.
(0011769)
henry   
2020-11-26 16:34   
I think it will be possible to mesh your case correctly with the current snappyHexMesh with suitable handling of the edges and setting of the parameters. We could undertake this work for you as paid user-support.
Many other similar cases have been meshed successfully with the current snappyHexMesh.

> That I don't know of course because I'm not involved in the development of snappy and would be quite hard for me to debugging it and that's why I brought this to your attention.

You have access to the complete source code and could study the changes between 2.1.1 and 8 if you believe that a bug was introduced or if it would be better if one or more of the changes were reverted.
(0011770)
rrossi   
2020-11-26 16:37   
Well, I thought this was the purpose of reporting potential bugs, but I get you won't recognize this as such so feel free to close the ticket.
(0011771)
henry   
2020-11-26 16:46   
I doubt this is a bug and it would be MUCH easier to mesh your case with the current snappyHexMesh rather than reverting developments.

However if you check the code and show which changes have caused the problem you see we can work on it.
(0011774)
tniemi   
2020-11-27 13:59   
Hi

I quickly checked this as I have sometimes seen similar issues (strange behavior with patches). If I changed the cyclic patches to walls, then snappy was able to produce a nice mesh. It seems that something goes wrong when the type of the patch is cyclic in the blockMesh phase. I vaguely remember having encountered these kind of problems, and personally in my workflow I have always created blockMesh and snappy with all patches as walls and then changed the types on the final mesh with createPatch and/or by editing the boundary file.

Don't know what change back in 2.1.1 would have changed this...
(0011776)
rrossi   
2020-11-27 14:35   
Hi tniemi.

Thanks for taking the time to look into this and for the valuable feedback.

Unfortunately I need to preserve a very strict tolerance between the cyclic patches because I can't switch to cyclicAMI in the solver I'm using, so the workflow you are suggesting is not an option for me.
(0011777)
henry   
2020-11-27 14:39   
Someone would need to spend a lot of time checking the changes in the snappyHexMesh code between 2.1.1 and 8 to find the relevant ones and propose a correction.
Currently we have no funding to work on snappyHexMesh so we will either need sponsorship for the work or I can leave this open for a while in case you or someone else would like to work in it on your behalf.
(0011782)
tniemi   
2020-11-29 19:09   
I happened to have some old OFs still compiled and ran this with 2.2.x and 2.3.x out of curiosity. 2.2.x still worked, but 2.3.x did not. I looked at the release notes and there has been quite a lot of snappy improvements at that point, including improvements to handling cyclics. So probably some update does not play along well with this case.

For what it's is worth, I was able to get this working with OF-dev by setting "detectNearSurfacesSnap false;" and "keepPatches true;" (somehow deletion of zero sized boundaries causes segFault in this case). The produced mesh looks quite ok (cyclic boundary is sharp), but checkMesh tells that there are several regions so maybe it is not entirely valid.
(0011783)
rrossi   
2020-11-30 09:32   
Thanks for info tniemi.

I've tried to use the same flags with the current 8.0 release but the resulting mesh is still distorted.

However, now the layer mesh is written correctly to file whereas I was getting the following error/crash without the "keepPatches true" (I guess) flag:

Removing zero-sized patches:
    x0 type patch at position 0
    x1 type patch at position 1
    y0 type patch at position 2
    y1 type patch at position 3

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in "/lib64/libc.so.6"
#3 Foam::globalPoints::reverseMeshPoints(Foam::cyclicPolyPatch const&) at ??:?
#4 Foam::globalPoints::receivePatchPoints(bool, Foam::Map<int> const&, Foam::List<int> const&, Foam::PstreamBuffers&, Foam::HashSet<int, Foam::Hash<int> >&) at ??:?
#5 Foam::globalPoints::calculateSharedPoints(Foam::Map<int> const&, Foam::List<int> const&, bool, bool) at ??:?
#6 Foam::globalPoints::globalPoints(Foam::polyMesh const&, Foam::PrimitivePatch<Foam::IndirectList<Foam::face>, Foam::Field<Foam::Vector<double> > const&> const&, bool, bool) at ??:?
#7 Foam::globalMeshData::calcGlobalPointSlaves() const at ??:?
#8 Foam::globalMeshData::globalPointSlaves() const at ??:?
#9 Foam::syncTools::getMasterPoints(Foam::polyMesh const&) at ??:?
#10 Foam::meshRefinement::printMeshInfo(bool, Foam::string const&) const at ??:?
#11 ? at ??:?
#12 ? at ??:?
#13 __libc_start_main in "/lib64/libc.so.6"
#14 ? at ??:?

Also, as mentioned in the original post, even with the 2.1.1 the mesh creation is successful in serial execution only.

When running in parallel with the same release and same snappyHexMeshDict, I get:

Surface refinement iteration 0
------------------------------

Marked for refinement due to surface intersection : 3058 cells.
Determined cells to refine in = 0 s
Selected for refinement : 3058 cells (out of 33880)
[1] Cannot find point in pts1 matching point 0 coord:(0.257289 0.257289 58.05) in pts0 when using tolerance 3.62299e-05
[1] Searching started from:16 in pts1
[1] Compared coord:(0.513473 10.7608 -12.4) with difference to point 71.2292
[1] Cannot find point in pts1 matching point 11 coord:(0.769658 0.257289 58.05) in pts0 when using tolerance 3.62299e-05

Do you have any feedback/guidelines on this?
(0011784)
tniemi   
2020-11-30 10:41   
> I've tried to use the same flags with the current 8.0 release but the resulting mesh is still distorted.

The "detectNearSurfacesSnap false;"-flag should be under "snapControls" for it to have an effect. If false, it reverts to 2.1.1 behaviour. At least for me it removes the distortion from the cyclic boundary in 8 and dev.

> However, now the layer mesh is written correctly to file whereas I was getting the following error/crash without the "keepPatches true" (I guess) flag:

Yes, that crash happens because by default snappy now removes 0-sized patches. This usually works without problems, but for some reason not here. Probably the cyclics don't play along well as that crash happens directly after removing the extra boundaries and when snappy starts to write the mesh to disk.

> Do you have any feedback/guidelines on this?

Unfortunately no, improvement to parallel operation is something that has been specially improved in eg. 2.3.0 release (https://openfoam.org/release/2-3-0/snappyhexmesh/).
(0011785)
rrossi   
2020-11-30 17:36   
> The "detectNearSurfacesSnap false;"-flag should be under "snapControls" for it to have an effect. If false, it reverts to 2.1.1 behaviour. At least for me it removes the distortion from the cyclic boundary in 8 and dev.

Got it. I've tried with the 8.0 as well and works as you suggested. I've also tried to run to case but crashed when starting to solve for pressure. Strange enough, the 4 regions are 4 isolated cells with size way smaller than the local grid resolution and completely detached from the boundary mesh (see attached).

> Unfortunately no, improvement to parallel operation is something that has been specially improved in eg. 2.3.0 release (https://openfoam.org/release/2-3-0/snappyhexmesh/).

Beside the 4 disconnected regions, given the overall good quality of the mesh I've tried to run in parallel on 4 cores with the 8.0 (to have all improvements you mentioned), but crashed with the following error during refinement:

After refinement surface refinement iteration 6 : cells:140823 faces:472212 points:192489
Cells per refinement level:
    0 287
    1 4433
    2 10952
    3 27031
    4 98120
Uncoupled 10 faces on coupled patches. (processorPolyPatch, cyclicPolyPatch)
Uncoupled 10 faces on coupled patches. (processorPolyPatch, cyclicPolyPatch)
[3] #0 Foam::error::printStack(Foam::Ostream&)[2] #0 Foam::error::printStack(Foam::Ostream&)[0] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[2] #1 Foam::sigSegv::sigHandler(int) at ??:?
[3] #1 Foam::sigSegv::sigHandler(int) at ??:?
[0] #1 Foam::sigFpe::sigHandler(int) at ??:?
[2] #2 ? at ??:?
[3] #2 ? at ??:?
[0] #2 ? in "/lib64/libc.so.6"
[2] #3 Foam::processorPolyPatch::updateMesh(Foam::PstreamBuffers&) in "/lib64/libc.so.6"
[3] #3 Foam::processorPolyPatch::updateMesh(Foam::PstreamBuffers&) in "/lib64/libc.so.6"
[0] #3 Foam::processorPolyPatch::updateMesh(Foam::PstreamBuffers&) at ??:?
[2] #4 Foam::polyBoundaryMesh::updateMesh() at ??:?
[3] #4 Foam::polyBoundaryMesh::updateMesh() at ??:?
[2] #5 Foam::polyMesh::resetPrimitives(Foam::Field<Foam::Vector<double> >&&, Foam::List<Foam::face>&&, Foam::List<int>&&, Foam::List<int>&&, Foam::List<int> const&, Foam::List<int> const&, bool) at ??:?
[0] #4 Foam::polyBoundaryMesh::updateMesh() at ??:?
[3] #5 Foam::polyMesh::resetPrimitives(Foam::Field<Foam::Vector<double> >&&, Foam::List<Foam::face>&&, Foam::List<int>&&, Foam::List<int>&&, Foam::List<int> const&, Foam::List<int> const&, bool) at ??:?
[2] #6 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, bool, bool, bool, bool) at ??:?
[0] #5 Foam::polyMesh::resetPrimitives(Foam::Field<Foam::Vector<double> >&&, Foam::List<Foam::face>&&, Foam::List<int>&&, Foam::List<int>&&, Foam::List<int> const&, Foam::List<int> const&, bool) at ??:?
[3] #6 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, bool, bool, bool, bool) at ??:?
[2] #7 Foam::fvMeshDistribute::repatch(Foam::List<int> const&, Foam::List<Foam::List<int> >&) at ??:?
[3] #7 Foam::fvMeshDistribute::repatch(Foam::List<int> const&, Foam::List<Foam::List<int> >&) at ??:?
[0] #6 Foam::polyTopoChange::changeMesh(Foam::polyMesh&, bool, bool, bool, bool) at ??:?
[2] #8 Foam::fvMeshDistribute::distribute(Foam::List<int> const&) at ??:?
[3] #8 Foam::fvMeshDistribute::distribute(Foam::List<int> const&) at ??:?
[2] #9 Foam::meshRefinement::balance(bool, bool, Foam::Field<double> const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[0] #7 Foam::fvMeshDistribute::repatch(Foam::List<int> const&, Foam::List<Foam::List<int> >&) at ??:?
[3] #9 Foam::meshRefinement::balance(bool, bool, Foam::Field<double> const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[2] #10 Foam::meshRefinement::refineAndBalance(Foam::string const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&, Foam::List<int> const&, double) at ??:?
[0] #8 Foam::fvMeshDistribute::distribute(Foam::List<int> const&) at ??:?
[3] #10 Foam::meshRefinement::refineAndBalance(Foam::string const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&, Foam::List<int> const&, double) at ??:?
[2] #11 Foam::snappyRefineDriver::surfaceOnlyRefine(Foam::refinementParameters const&, int) at ??:?
[0] #9 Foam::meshRefinement::balance(bool, bool, Foam::Field<double> const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&) at ??:?
[3] #11 Foam::snappyRefineDriver::surfaceOnlyRefine(Foam::refinementParameters const&, int) at ??:?
[2] #12 Foam::snappyRefineDriver::doRefine(Foam::dictionary const&, Foam::refinementParameters const&, Foam::snapParameters const&, bool, Foam::dictionary const&) at ??:?
[0] #10 Foam::meshRefinement::refineAndBalance(Foam::string const&, Foam::decompositionMethod&, Foam::fvMeshDistribute&, Foam::List<int> const&, double) at ??:?
[3] #12 Foam::snappyRefineDriver::doRefine(Foam::dictionary const&, Foam::refinementParameters const&, Foam::snapParameters const&, bool, Foam::dictionary const&) at ??:?
[2] #13 at ??:?
[0] #11 Foam::snappyRefineDriver::surfaceOnlyRefine(Foam::refinementParameters const&, int) at ??:?
[3] #13 ?? at ??:?
[0] #12 Foam::snappyRefineDriver::doRefine(Foam::dictionary const&, Foam::refinementParameters const&, Foam::snapParameters const&, bool, Foam::dictionary const&) at ??:?
[0] #13 at ??:?
[2] #14 __libc_start_main at ??:?
[3] #14 __libc_start_main? in "/lib64/libc.so.6"
[2] #15 in "/lib64/libc.so.6"
[3] #15 ? at ??:?
[0] #14 __libc_start_main? at ??:?
(0011786)
rrossi   
2020-11-30 17:37   
Sorry. Here is the attachment.
(0011787)
will   
2020-12-02 11:11   
The distortion problem is in `Foam::snappySnapDriver::avgCellCentres`. This is doing a `syncPointList` on a sum of point-adjacent cell centres. This operation is incompatible with transformed interfaces. We can transform vectors and positions, but there's no way of transforming a sum of positions like this. Instead, you sum up the point-cell-centre vectors, and synchronise those, rather than the cell-centres directly. This is just a position-less vector, and transforms/synchronises fine. Then, after synchronisation, you just add the point locations back on again. There are actually a few places in `snappySnapDriver.C` that I can spot where this fix applies. I've done as many as I can find, and pushed to dev. This means the meshing works OK with or without "detectNearSurfacesSnap false;". See commit:

https://github.com/OpenFOAM/OpenFOAM-dev/commit/983f77e19c82eb58a0fd3832bec858e5b8c30716

The segfault without "keepPatches true;" is caused by the patch removal process renumbering all the patches but not renumbering (or clearing) the stored neighbour patch indices in the coupled patches. This information needed propagating through couplings. This has been done in dev by the following commit.

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

The parallel crash is due to `fvMeshDistribute` not ordering processor cyclics correctly. This has been fixed in dev by this commit.

https://github.com/OpenFOAM/OpenFOAM-dev/commit/685664b3ca399e04ad8d203686d7153698d985cd

The remaining issue for meshing this case in parallel is that `reconstructParMesh` does not seem to support cyclic patches. Adding that is a big job. For now, `redistributePar` does support cyclics, and it seems to do the job of reconstructing the mesh correctly in this case. It is far less convenient to use, however, and possibly also less efficient. Alternatively, you have the option of constraining the cyclics to a single processor, which will circumvent this issue. Or, just mesh it in serial. It's not a big case.

I do not see the multiple regions issue with this setup. In any case, the generation of multiple regions and associated solution failure is usually due to bad geometry, inappropriate settings, or just unrealistic expectations of what snappy can do. Helping you with that would constitute support, which is not provided on the bug tracking system.

Whilst there remains an issue with `reconstructParMesh` and it's support of cyclics, I think all of the issues raised in this report have now been resolved, so I'm closing this report. If you want to open another more specific issue relating to `reconstructParMesh` you are welcome to do so, though the response is likely to be "This is a significant development, can you fund it?".


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3600 [OpenFOAM] Bug tweak always 2020-11-26 08:16 2020-11-26 08:55
Reporter: tiziano.maffei Platform:  
Assigned To: will OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 8  
    Target Version:  
Summary: multiphaseEulerFoam - missing Raoult model
Description: Good morning,

in multiphaseEulerModel there is not possibility to select Raoult model in interfaceCompoisition dictionary. Raoult class is not compiled and missing in the
OpenFOAM-8/applications/solvers/multiphase/multiphaseEulerFoam/interfacialCompositionModels/Make/files.

Moreover, adding the file and compiling the code, I got the error message:
error: ‘const class Foam::hashedWordList’ has no member named ‘contains’

Then I have modified the line code in Yf and YfPrime functions:
if (species().contains(speciesName)) - > if (species().found(speciesName))
and the code compilation works.

I hope this can be useful

Tiziano

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011760)
will   
2020-11-26 08:55   
Thanks for pointing this out. The Raoult model has been included in the build in dev and 8 by the following commits:

https://github.com/OpenFOAM/OpenFOAM-dev/commit/f779ddae156d0f7be0c93bde5b2d1da01ef0853d
https://github.com/OpenFOAM/OpenFOAM-8/commit/13d66902f78c3a17d58aac28aeea7c91597ac31f


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3598 [OpenFOAM] Feature minor always 2020-11-23 19:30 2020-11-24 17:13
Reporter: peksa Platform: Linux  
Assigned To: henry OS: Centos  
Priority: low OS Version: 7  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: distanceSurface -based sampling not implementing zones
Description: I noticed that zoneKey_ is created in constructor of "distanceSurface.C" but it is not updated anywhere, yielding no action when "zone" keyword is used in sampledSurface dictionary entry.

I'd imagine one could implement the zoneKey_ treatment similar to other xSurface methods?

Best regards,

peksa
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: distanceSurface.tar.gz (5,029 bytes) 2020-11-24 14:22
https://bugs.openfoam.org/file_download.php?file_id=3094&type=bug
Notes
(0011745)
henry   
2020-11-23 19:49   
> I'd imagine one could implement the zoneKey_ treatment similar to other xSurface methods?

Probably, have you tried?
(0011746)
peksa   
2020-11-23 19:53   
Not yet, just noticed this and decided to report first. I'll give it a go.
(0011748)
henry   
2020-11-23 21:17   
Do you need it?
(0011749)
peksa   
2020-11-23 22:23   
When using distanceSurface together with e.g. searchableCylinder object with an ambition to sample data only on the cylinder side, you will get the top / bottom cylinder discs included as well as expected from the searchableCylinder implementation, which biases e.g. areaAverage etc. functionObject results. I was hoping to achieve separation between top/bottom discs and side surface by defining cell-zones such that discs wouldn't be sampled.

Of course one option is to modify the searchable-objects but they seem more difficult and brittle pieces of code compared to zone modification.
(0011751)
peksa   
2020-11-24 14:22   
Hey,

As an attachment you find an implementation for which I added zone-capability following the approach used in "sampledCuttingPlane" class. I tested it for my particular case at hand and it worked as intended.

Best regard,

peksa
(0011754)
henry   
2020-11-24 15:32   
One of the constructors is commented-out, is there a reason for that?
(0011756)
henry   
2020-11-24 16:32   
commit a00831687097d0c19d1ca431cfd7e68dee3fc265 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Tue Nov 24 16:25:47 2020 +0000

    sampledSurface::distanceSurface: Added zone support using zoneKey
    
    combining functionality from sampledCuttingPlane and sampledPlane.
    Updated sampledCuttingPlane to use zoneKey.

I think it would be best if the zone sub-setting were abstracted so that it can be applied to the other sampledSurfaces, in particular sampledIsoSurface, without further code duplication.

I do not have any test cases setup for these changes, please let me know if they work correctly.
(0011757)
henry   
2020-11-24 16:57   
Even better would be to rewrite the iso-surface algorithm on which the sampledCuttingPlane and distanceSurface are based to operate directly on a cell-set to avoid the inefficient mesh sub-setting.
(0011758)
peksa   
2020-11-24 17:03   
Hey,

Tested your implementation and it works as intended with my present case (unfortunately can't share it publicly).

Regarding the other constructor, I had left it commented by accident because didn't see it being used and wanted to minimize changes on my first implementation. I tested your implementation by adding the the second constructor as it was earlier, and expectedly, it still compiles and works as intended.

Thanks for the work!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3594 [OpenFOAM] Patch minor have not tried 2020-11-16 13:32 2020-11-23 14:55
Reporter: rgutt Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 20.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: alphaEqh wrong order
Description: I think alpha2 should be calculated after alpha1 was corrected. Otherwise, the sum of alpha1 + alpha2 might not be equals to 1, if alpha1 has some correction coming from the contact angle.


Line code
225 alpha2 = 1.0 - alpha1;
226
227 mixture.correct();
Tags:
Steps To Reproduce:
Additional Information: File: Solvers/multiphase/VoF/alphaEqn.H
Attached Files:
Notes
(0011687)
henry   
2020-11-16 14:13   
The mixture.correct() might use alpha2 (currently it doesn't but perhaps it should be written that way) so it would have to be updated before and after the mixture.correct(), but it would probably be better if it updated alpha2 after updating alpha1.
(0011744)
henry   
2020-11-23 14:55   
Resolved by commit 92c9b112f005f02cd32dbbfbe03671dda7c3959c


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

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

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

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

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


Run:
Allpre
reactingParcelFilmFoam

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

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

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

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

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


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

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

addedMassTotal 0.006046627137;

injectionModel
{
    curvatureSeparation
    {
        injectedMass 0;
    }
}



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

With a film tickness deltaStable = 0.0001 the attached test case as well as the Hot Boxes - Tutorial stay numerically stable.
(0011738)
henry   
2020-11-23 12:08   
Resolved by commit d7d1221cd47833c0e12fbbe5e38bc5f3db95a467


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

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

As we can see by the simulation, before one 1 s, the internal temperature increases beyond 400 K, which is a violation of the energy balance.
Tags:
Steps To Reproduce: Run the scipt "Allrun" in the attached case, which uses the solver "compressibleInterFoam".
Additional Information:
System Description
Attached Files: emissivityErrorTestCase.tar.gz (593,018 bytes) 2020-10-22 16:12
https://bugs.openfoam.org/file_download.php?file_id=3078&type=bug
externalWallHeatFluxTemperatureFvPatchScalarField.C (14,295 bytes) 2020-11-21 23:44
https://bugs.openfoam.org/file_download.php?file_id=3092&type=bug
Notes
(0011703)
henry   
2020-11-21 19:50   
How do you think radiation should be implemented in externalWallHeatFluxTemperature? Can you provide a patch?
(0011728)
henry   
2020-11-21 23:16   
Have you tried relaxing the radiation contribution and using more outer iterations to converge the heat transfer?
(0011730)
henry   
2020-11-22 01:13   
The point of the current implementation is to avoid the "/(Ta-Tp+VSMALL)" which can cause serious problem, particularly if (Ta-Tp) = -VSMALL. The stabilisation will have to be done more carefully than this to avoid crashes.
(0011732)
henry   
2020-11-22 16:46   
If we factor (Ta^4 - Tp^4) as

    (Ta - Tp)((Ta^3 + Tp^3) + TaTp(Ta + Tp))

we can avoid the division by (Ta -Tp)
(0011736)
henry   
2020-11-23 11:31   
Resolved in OpenFOAM-8 by commit 132a11d3674a0bd71761bedd5d3e75d52b373b82
Resolved in OpenFOAM-dev by commit bdbb2ae0a83a5aa06ed55c472ef7dac602bcb077


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1855 [OpenFOAM] Bug feature always 2015-09-26 13:48 2020-11-21 22:39
Reporter: user1210 Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 14.04  
Status: resolved Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: decomposePar+refinementHistory doesn't work
Description: For any *DyMFoam solver, decomposePar is not working for refinementHistory file, which is stored in polyMesh folder in time folders. This disables the unrefinement process in parallel run.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0005371)
wyldckat   
2015-09-27 20:50   
Will be fixed along with #1822.
(0005373)
user1210   
2015-09-27 21:25   
This report is different than the issue #1822;

#1822: Celllevel and pointlevel can be decomposed and used in parallel. The only problem is that they cannot be reconstructed.

#1855: refinementHistory cannot be decomposed at all. Therefore you lose the history in parallel.
(0005374)
wyldckat   
2015-09-27 21:29   
Thanks for the clarification! Resetting the Status to "New".
(0005504)
wyldckat   
2015-10-27 15:34   
For future reference for fixing this issue, it seems that the following commit on the OpenFOAM-History repository has the fix for this, or at least part of the fix: https://github.com/OpenCFD/OpenFOAM-history/commit/af7a439fc7a4f5b03d5f5bf65399a46888f3d164
(0011727)
henry   
2020-11-21 22:39   
Resolved by commit 1441f8cab064a79b65e0dc7c80e86b8c45dc2f80


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1103 [OpenFOAM] Bug minor always 2013-12-06 16:16 2020-11-21 20:27
Reporter: gdtech Platform: Linux  
Assigned To: henry OS: Centos  
Priority: normal OS Version: 5.10  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Issue using fvOptions with moving mesh
Description: When the mesh is changing, fvOption cell selection is updated multiple times within a time step instead of once. This makes the simulation slower and the stdout unreadable (see attached log files).
Tags:
Steps To Reproduce: add fvOption :

source1
{
    type fixedTemperatureConstraint;
    active true;
    timeStart 0;
    duration 1.0e-4;
    selectionMode cellSet;
    cellSet ignitionCells;

    fixedTemperatureConstraintCoeffs
    {
        mode uniform;
        temperature 2000;
    }
}

and topoSet :

actions
(
    {
        name ignitionCells;
        type cellSet;
        action new;

        source sphereToCell;
        sourceInfo
        {
            centre ( 0.0 0.05 0.0 );
            radius 0.002;
        }
    }
);

to sprayFoam and sprayEngineFoam cases.
Additional Information:
System Description
Attached Files: logFiles.zip (5,882 bytes) 2013-12-06 16:16
https://bugs.openfoam.org/file_download.php?file_id=649&type=bug
Notes
(0011719)
henry   
2020-11-21 20:27   
Resolved by commit b8f9ed8062f4e58005954a084b67d07809061c5a


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2302 [OpenFOAM] Bug minor always 2016-10-21 08:26 2020-11-21 20:18
Reporter: ALU Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 12.04  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: wallHeatFlux utility: wrong calculation of heatfluxes using anisotropic kappa
Description: The wallHeatFlux utility calculates wrong heat-fluxes if anisotropic kappa for heSolidThermo is used.

It seems that the kappa is calculated with kappa = sqrt(kappa1^2 + kappa2^2 + kappa3^2) instead of using the normal-component of the surface.

Also it would be nice if wallHeatFlux could be used like a function object.
Tags:
Steps To Reproduce: In the multiRegionHeater tutorial use anisotropic kappa (80 80 80) instead of kappa 80 and change the kappaMethod to directionalSolidThermo in the relevant boundary conditions. Using wallHeatFlux utility now calculates wrong heatfluxes.
Additional Information:
System Description
Attached Files:
Notes
(0007059)
henry   
2016-10-21 08:54   
In OpenFOAM-dev:

dm(201) wallHeatFlux
wallHeatFlux has been superceded by the '-postProcess' solver command-line option, e.g.
simpleFoam -postProcess -func wallHeatFlux
(0011716)
henry   
2020-11-21 20:18   
Resolved in OpenFOAM-dev provided the anisotropy is aligned with the boundary.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Any thoughts?

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

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

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

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


With something like:
nOuterCorr 3;
nOuterEnergyCorr 30;

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

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

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

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

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

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

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

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

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

Thank you for any help
(0011705)
henry   
2020-11-21 19:53   
This should now be resolved in OpenFOAM-dev.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3591 [OpenFOAM] Bug block always 2020-11-13 22:40 2020-11-15 18:12
Reporter: wyldckat Platform: x86_64  
Assigned To: henry OS: CentOS  
Priority: normal OS Version: 7.x  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Recent updates associated Function2 seems to have broken fluidReactionThermo
Description: In the last couple of nights, I've tried updating a build of OpenFOAM-dev to the latest commits and have gotten the start of a long error message, of which the first relevant error is listed in "Steps to Reproduce" below.

For reference, I'm using GCC 7.3:
    gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)

1. Perhaps a commit is missing, because the file "$FOAM_SRC/OpenFOAM/primitives/functions/Function2/evaluate/Function2Evaluate.H" only has 2 "evaluate" functions with 3 arguments, even though the .C file does define to those functions with 4 arguments...

2. Or is it because a more modern GCC version is needed?
Tags:
Steps To Reproduce: Allwmake src/ThermophysicalTransportModels
wmake fluidReactionThermo
g++ -std=c++14 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -I/home/ofuser/OpenFOAM/OpenFOAM-dev/src/MomentumTransportModels/momentumTransportModels/lnInclude -I/home/ofuser/OpenFOAM/OpenFOAM-dev/src/MomentumTransportModels/compressible/lnInclude -I/home/ofuser/OpenFOAM/OpenFOAM-dev/src/ThermophysicalTransportModels/lnInclude -I/home/ofuser/OpenFOAM/OpenFOAM-dev/src/thermophysicalModels/specie/lnInclude -I/home/ofuser/OpenFOAM/OpenFOAM-dev/src/thermophysicalModels/basic/lnInclude -I/home/ofuser/OpenFOAM/OpenFOAM-dev/src/thermophysicalModels/reactionThermo/lnInclude -I/home/ofuser/OpenFOAM/OpenFOAM-dev/src/finiteVolume/lnInclude -I/home/ofuser/OpenFOAM/OpenFOAM-dev/src/meshTools/lnInclude -IlnInclude -I. -I/home/ofuser/OpenFOAM/OpenFOAM-dev/src/OpenFOAM/lnInclude -I/home/ofuser/OpenFOAM/OpenFOAM-dev/src/OSspecific/POSIX/lnInclude -fPIC -c fluidReactionThermophysicalTransportModels.C -o /home/ofuser/OpenFOAM/OpenFOAM-dev/platforms/linux64GccDPInt32Opt/src/ThermophysicalTransportModels/fluidReactionThermo/fluidReactionThermophysicalTransportModels.o
In file included from /home/ofuser/OpenFOAM/OpenFOAM-dev/src/ThermophysicalTransportModels/lnInclude/FickianEddyDiffusivity.H:164:0,
                 from fluidReactionThermophysicalTransportModels.C:62:
/home/ofuser/OpenFOAM/OpenFOAM-dev/src/ThermophysicalTransportModels/lnInclude/FickianEddyDiffusivity.C: In member function ‘virtual Foam::tmp<Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> > Foam::turbulenceThermophysicalTransportModels::FickianEddyDiffusivity<TurbulenceThermophysicalTransportModel>::j(const volScalarField&) const’:
/home/ofuser/OpenFOAM/OpenFOAM-dev/src/ThermophysicalTransportModels/lnInclude/FickianEddyDiffusivity.C:188:79: error: no matching function for call to ‘evaluate(const Foam::Function2<double>&, const Foam::dimensionSet&, const volScalarField&, const volScalarField&)’
                 evaluate(DT_[composition.index(Yi)], dimDynamicViscosity, p, T)
                                                                               ^
Additional Information:
Attached Files:
Notes
(0011684)
henry   
2020-11-13 22:54   
commit ac3473d7b8c24a3e95df37269a449293f75317c3
(0011686)
wyldckat   
2020-11-15 18:12   
@Henry: Many thanks! Am marking this issue as resolved by you.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3589 [ThirdParty] Bug minor always 2020-11-09 18:57 2020-11-11 12:00
Reporter: Kyle 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: 8  
    Target Version:  
Summary: Threshold not working on lagrangian data
Description: Hello,

When trying to threshold the data from the lagrangian solve it doesn't work. I have to the glyph the data then threshold to get it to work which messes up the data. I don't have this issue when using the v2006. It is also not possible to threshold the data once I have foamToVTk the data.
Tags:
Steps To Reproduce: Run the cyclone tutorial can and threshold the data.
Additional Information: I did this on windows.
System Description
Attached Files: cloud_6000.vtk (1,768,138 bytes) 2020-11-11 10:29
https://bugs.openfoam.org/file_download.php?file_id=3085&type=bug
save_state_threshold.pvsm (263,367 bytes) 2020-11-11 10:29
https://bugs.openfoam.org/file_download.php?file_id=3086&type=bug
Notes
(0011670)
henry   
2020-11-09 19:45   
It is not clear if you are referring to a problem in OpenFOAM or ParaView. The ParaView threshold functionality does not relate directly to OpenFOAM so it maybe that you are seeing a problem with the ParaView version you are using.

> Run the cyclone tutorial can and threshold the data.

This is not sufficient information to reproduce the problem, could you provide more detail?
(0011671)
Kyle   
2020-11-09 20:25   
Hi,
I like the changes that were made to the lagrangian solvers so I moved my MPPIC case, that I setup in v2006, to the reactingParticelFoam solver so I can model the heat transfer from the hot gas to a limestone cloud.
When I got my case running and got some of the data lagrangian data I first tried to use paraFoam but that would not load the .openFOAM reader. I then used foamToVTK to get the data into VTK format and then loaded it into ParaView 5.8. applied a threshold filter but it wouldn't actual threshold the data as I want to see only the particles less with an age less than one second. I could do this with the MPPIC lagrangian cloud data that was changed to VTK with foamToVTK from v2006.
I tested to see if it was some setup issue by running the \tutorials\lagrangian\denseParticleFoam\cyclone case to 1.3 seconds and then changing it to VTK with foamToVTK. I would load that into ParaView 5.8 and the threshold filter will not work unless I apply a glyph filter to the data first and then apply the threshold.

I have not tried to see if it works in ubuntu. I will see if I get time tomorrow.

I am also not sure if this is a ParaView or OpenFOAM issue. I know that the two versions save the lagrangian results in different formats and that KitWare only supports the .com version with a builtin reader. But if it doesn't work after changing it to VTK surely it must be OpenFOAM then?

I hope this clears things up.
(0011672)
henry   
2020-11-09 21:44   
There are some serious bugs in ParaView-5.8 so we are using ParaView-5.6.3.
(0011673)
henry   
2020-11-09 21:58   
I ran the cyclone in OpenFOAM-dev to 1.3s, loaded the Lagrangian data for time 1.3s into ParaView-5.6.3 using the paraFoam reader and thresholded on age from 0 to 0.1s and it works fine.
(0011674)
Kyle   
2020-11-10 04:38   
Okay, thanks. I will look into it a bit further on my side to try and get paraFoam to load the reader correctly.
(0011675)
Kyle   
2020-11-10 16:45   
Hello,

I looked into a bit further and it seemed to be an issue with the foamToVTk function of the lagrangian data.
I got paraFoam working correctly but removing and purging and the dev and parafoam and reinstalling. Then closing the ubuntu shell and Xming and reopening it. Now paraFoam is working correctly and able to load .openFOAM files and the threshold works. Now I tested the foamToVTK on the complete case of the cyclone tutorial by reconstructing the data and running foamToVTK (just foamToVTK no extra arguments). I open the vtk file after in paraFoam and it can not threshold the data. I then reloaded the case using the PVreader to load the data and exported from paraFoam to a VTM file. This work correctly in 5.8 and parafoam. This to me points to an issue with the foamToVTK.
(0011676)
will   
2020-11-11 09:09   
I cannot reproduce this. The age data (and everything else) is present in the VTK output, and Paraview 5.6.3 and 5.8.1 have no problem loading it and applying a threshold. I do not have Paraview 5.8.0 installed.

If you want us to investigate further, please upload the VTK file in question as well as a Paraview state file showing how you are viewing it (File > Save State).

However, I suspect that this is either an issue of usage or a bug in the version of Paraview that you are using. In either of these cases we will not be able to help. Paraview's bug tracker can be found here: https://gitlab.kitware.com/paraview.
(0011677)
Kyle   
2020-11-11 10:29   
Hello,

Please see the attached vtk data.
(0011678)
will   
2020-11-11 10:33   
Apologies for the above. I can now see the issue. The problem is that the lagrangian VTK files only have the points listed. They have no VERTICES section, which is needed for them to display by default and for various filters to work. We will add this.
(0011679)
will   
2020-11-11 12:00   
Resolved in dev and in version 8 by the following commits:

https://github.com/OpenFOAM/OpenFOAM-dev/commit/93357284dbc9ee39a6334bd1135a644044f421fe
https://github.com/OpenFOAM/OpenFOAM-8/commit/340defec456f31b70645f29e78ffed1e6ede5a8e


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3587 [OpenFOAM] Bug crash always 2020-11-03 09:48 2020-11-06 11:21
Reporter: maxdre91 Platform: Linux  
Assigned To: henry OS: Ubuntu  
Priority: high OS Version: 18.04  
Status: resolved Product Version: 7  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: fluent3DMeshToFoam and mergeMeshes crash with large (around 170 mio cells) meshes
Description: During Mesh conversion from ICEM-generated .msh files (written in ASCII) i come across errors when i try to convert large meshes (around 170 mio. cells) via fluent3DMeshToFoam.
As a workaround i tried to split my mesh into 3 smaller parts in order to merge them after the conversion with fluent3DMeshToFoam.
For all of these 3 parts of the mesh, the conversion via fluent3DMeshToFoam is successfull and checkMeshes also provide good results.
Now when i try to merge them in any possibility (1&2; 1&3; 2&3) mergeMesh crashes witht he same error output as in the fluent3DMeshToFoam of the large mesh.
I attached the log-file from mergeMeshes. As you can see it was performed under OF7.

As these issues only occur with large mesh sizes, i am not sure how to provide a minimum working example.
Any help would be very appreciated, thanks.

M. Drexelius
Tags:
Steps To Reproduce:
Additional Information: Further info on the meshes:
Total cells: 172,114,578‬ hexahedral cells
Part 1: 8.6 GB data; 44,166,906 hexa cells; 24 boundary patches
Part 2: 11.2 GB data; 57,232,114 hexa cells; 27 boundary patches
Part 3: 14.0 GB data; 70,715,558 hexa cells; 27 boundary patches
System Description
Attached Files: log_mergeMesh (8,173 bytes) 2020-11-03 09:48
https://bugs.openfoam.org/file_download.php?file_id=3079&type=bug
log_mergeMeshes_v7 (9,123 bytes) 2020-11-03 09:56
https://bugs.openfoam.org/file_download.php?file_id=3080&type=bug
Notes
(0011655)
henry   
2020-11-03 10:15   
Try compiling with 64bit labels.
(0011656)
maxdre91   
2020-11-03 11:07   
Thanks alot for your reply. Could you elaborate on how to do that?
(0011657)
maxdre91   
2020-11-03 11:17   
I guesss you are refering to:
/etc/bashrc
changing WM_LABEL_SIZE=32 to 64.
I will try that and give feedback on the results when its done
(0011662)
maxdre91   
2020-11-06 08:16   
I managed to compile it with WM_LABEL_SIZE=64 which seems to do the trick! fluent3DMeshToFoam ran successfully this time.
Thanks a lot.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3584 [OpenFOAM] Bug minor always 2020-10-31 17:53 2020-11-05 11:11
Reporter: diego Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: low OS Version: 18.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Setting "system/controlDict" to use USCS unit system fails for perfect gas compressible flow
Description: Setting "system/controlDict" ("single case controlDict") to use USCS unit system, as mentioned in the end of < https://cfd.direct/openfoam/user-guide/v7-global-settings/ >, fails for perfect gas compressible flow. Although this issue is being reported for OpenFOAM 7.0, by checking the source code, it seems to be reproducible since OpenFOAM 3.0, and also in OpenFOAM 8.0.
Tags:
Steps To Reproduce: An example to reproduce the error is shown below. For simplicity for showing the error, the setup of one of the OpenFOAM tutorials is used (although all the setup is performed in SI units, it serves to show the issue).

1) Set up an example that uses "rhoSimpleFoam":
$ run
$ cp -r $FOAM_TUTORIALS/compressible/rhoSimpleFoam/aerofoilNACA0012 ./
$ cd aerofoilNACA0012
$ blockMesh

2) Write the following in "system/controlDict":

DimensionedConstants
{
    unitSet USCS;
}

3) Edit "rhoSimpleFoam" solver by including the following prints in the beginning of pEqn.H file:

Info << ">> constant::physicoChemical::R = " << constant::physicoChemical::R.value() << endl;
Info << ">> constant::standard::Pstd = " << constant::standard::Pstd.value() << endl;
Info << ">> constant::standard::Tstd = " << constant::standard::Tstd.value() << endl;
Info << ">> constant::thermodynamic::RR = " << constant::thermodynamic::RR << endl;
Info << ">> constant::thermodynamic::Pstd = " << constant::thermodynamic::Pstd << endl;
Info << ">> constant::thermodynamic::Tstd = " << constant::thermodynamic::Tstd << endl;

Recompile "rhoSimpleFoam" (using "wmake").

3) After compiling the edited "rhoSimpleFoam" solver, running the example with "rhoSimpleFoam" shows that the values defined in "constant::thermodynamic" kept their SI values, and did not change to their USCS counterparts. The prints of "Time = 1" from, for example, OpenFOAM 7.0, are reproduced below:

-----------

Time = 1

DILUPBiCGStab: Solving for Ux, Initial residual = 1, Final residual = 0.083305068, No Iterations 1
DILUPBiCGStab: Solving for Uz, Initial residual = 1, Final residual = 0.070339263, No Iterations 1
DILUPBiCGStab: Solving for e, Initial residual = 0.99999239, Final residual = 0.026874282, No Iterations 2
>> constant::physicoChemical::R.value() = 109.61021
>> constant::standard::Pstd.value() = 2088.6
>> constant::standard::Tstd.value() = 536.67
>> constant::thermodynamic::RR = 8314.4701
>> constant::thermodynamic::Pstd = 100000
>> constant::thermodynamic::Tstd = 298.15
GAMG: Solving for p, Initial residual = 1, Final residual = 0.0079628396, No Iterations 19
time step continuity errors : sum local = 0.026544362, global = 0.0036102344, cumulative = 0.0036102344
pressureControl: p max 2332425.8
pressureControl: p min -241003.58
DILUPBiCGStab: Solving for omega, Initial residual = 0.0040281112, Final residual = 0.00026767745, No Iterations 1
DILUPBiCGStab: Solving for k, Initial residual = 1, Final residual = 0.052874407, No Iterations 1
ExecutionTime = 0.21 s ClockTime = 1 s

-----------

As can be seen, R, Pstd and Tstd (from "constant::physicoChemical" and "constant::standard") are in USCS units (according to system/controlDict), while RR (RR = 10**3*R), Pstd and Tstd (from "constant::thermodynamic") are in SI units.
Additional Information: Idea of the cause of the issue:
By looking at < https://github.com/OpenFOAM/OpenFOAM-8/blob/master/src/OpenFOAM/global/constants/thermodynamic/thermodynamicConstants.C >, it can be seen that the values in "constant::thermodynamic" are defined as "const scalar" instead of objects (* The other constants are defined as objects, such as dimensionedScalar). This seems to mean that the variables in "constant::thermodynamic" are only set from the "global controlDict" (etc/controlDict) instead of the "single case controlDict" (system/controlDict), resulting in an inconsistency in measurement units.
System Description
Attached Files:
Notes
(0011649)
henry   
2020-11-01 21:30   
Setting DimensionedConstants in system/controlDict is not currently supported, I get a segmentation fault:

Overriding DimensionedConstants according to controlDict
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in "/lib64/libc.so.6"
#3 Foam::Hasher(void const*, unsigned long, unsigned int) at ??:?
#4 Foam::dictionary::lookupEntryPtr(Foam::word const&, bool, bool) at ??:?
#5 Foam::dictionary::subDict(Foam::word const&) at ??:?
#6 Foam::registerDimensionedConstant::lookup() at ??:?
#7 Foam::Time::readDict() at ??:?
#8 Foam::Time::setControls() at ??:?
#9 Foam::Time::Time(Foam::word const&, Foam::argList const&, Foam::word const&, Foam::word const&) at ??:?
#10 ? at ??:?
#11 __libc_start_main in "/lib64/libc.so.6"
#12 ? at /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/../sysdeps/x86_64/start.S:122

However if you set
    unitSet USCS;

in etc/controlDict it should work.
(0011651)
henry   
2020-11-02 09:28   
commit a121baf047b901a9184183a8eb0295911bde0a7c (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Mon Nov 2 09:26:04 2020 +0000

    OpenFOAM::dimensionedConstants: Updated handling of constant specification in system/controlDict
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3584


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

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

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

(0011294)
zhangxusjtu   
2020-04-16 12:51   
I agree with you, and the proposed test case is convincing. I will try it later.
(0011658)
zhangxusjtu   
2020-11-04 02:36   
I have carried out a test with mixed water parcel in a box, with 50% H2O and 50% anotherH2O (with the same liquid properties). The results are different though, with different particle diameter at time=0.5. This indicates that they are evaporating with different rates. I am working with OpenFOAM-6. The orig case was from the $FOAM_TUTORIALS.
(0011661)
will   
2020-11-04 09:47   
Thanks for confirming it.

More importantly than the evaporation rates being different, if we apply your proposed fix then the evaporation rates become the same. See the attached graphs for before and after.

This has been fixed in dev and version 8 by the following commits.

https://github.com/OpenFOAM/OpenFOAM-8/commit/dcc529a042ac794e0bff1242d57da4d42824708c
https://github.com/OpenFOAM/OpenFOAM-dev/commit/900eb1cf8c7d92e298356337dcf1a63ccadc6038


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3586 [OpenFOAM] Bug minor always 2020-11-02 10:07 2020-11-04 08:44
Reporter: michael.mueller-wrd Platform: GNU/Linux  
Assigned To: henry OS: centOS  
Priority: normal OS Version: (please specify)  
Status: resolved Product Version: 8  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: chtMultiRegionFoam: output of wallHeatFlux function object deviates during runtime and as postProcess
Description: In a chtMultiRegionFoam case, I noticed deviations in the output wallHeatFlux function object when (a) executed during runtime as entry in controlDict and when (b) executing the postprocessing command after the run finished.
While the difference for the fluid region is rather small, the differences for solid regions is rather large.
I would assume, there should be no difference at all.

This behaviour may also be reproduced with tutorial cases.
Tags:
Steps To Reproduce: For "heatedDuct" tutorial:
1. add function object to controlDict:
...
functions
{
    wallHeatFlux_heater
    {
        type wallHeatFlux;
        libs ( "libfieldFunctionObjects.so" );
        writeControl writeTime;
        region heater;
    }
    wallHeatFlux_metal
    {
        type wallHeatFlux;
        libs ( "libfieldFunctionObjects.so" );
        writeControl writeTime;
        region metal;
    }
    wallHeatFlux_fluid
    {
        type wallHeatFlux;
        libs ( "libfieldFunctionObjects.so" );
        writeControl writeTime;
        region fluid;
    }
}

2. run case

3. postprocess data after run is finished:
$> chtMultiRegionFoam -postProcess -region fluid -func wallHeatFlux -latestTime
$> chtMultiRegionFoam -postProcess -region metal -func wallHeatFlux -latestTime
$> chtMultiRegionFoam -postProcess -region heater -func wallHeatFlux -latestTime

4. compare output:
$> diff postProcessing/fluid/wallHeatFlux/0/wallHeatFlux.dat postProcessing/fluid/wallHeatFlux_fluid/0/wallHeatFlux.dat
$> diff postProcessing/heater/wallHeatFlux/0/wallHeatFlux.dat postProcessing/heater/wallHeatFlux_heater/0/wallHeatFlux.dat
$> diff postProcessing/metal/wallHeatFlux/0/wallHeatFlux.dat postProcessing/metal/wallHeatFlux_metal/0/wallHeatFlux.dat
Additional Information: You have been working on this function object recently, in the dev version.
Unfortunately, I could not yet find the time to check this issue with the latest dev version -- maybe it's already fixed with recent changes!?
System Description
Attached Files:
Notes
(0011652)
henry   
2020-11-02 10:16   
(Last edited: 2020-11-02 10:17)
> Unfortunately, I could not yet find the time to check this issue with the latest dev version -- maybe it's already fixed with recent changes!?

Yes it is likely that the changes in OpenFOAM-dev have resolved this issue, let us know when you have tested it.

(0011659)
michael.mueller-wrd   
2020-11-04 08:37   
Yes, I can confirm that it is already resolved in the latest dev version.

And the refined header of the output is very helpful, too.
Thanks.
(0011660)
henry   
2020-11-04 08:44   
Already fixed in OpenFOAM-dev


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3583 [OpenFOAM] Bug minor always 2020-10-27 15:26 2020-10-28 08:45
Reporter: peksa Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: low OS Version: 15.04  
Status: resolved Product Version: 8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: magSqr functionObject produces unnecessary warnings
Description: Hey,

I noticed that while using magSqr functionObject for non-scalar field (here U), the function produces a warning message:

--> FOAM Warning : functionObjects::magSqr magFn cannot find required object U of type volScalarField
--> FOAM Warning : functionObjects::magSqr magFn cannot find required object U of type surfaceScalarField

I believe this happens because the present implementation of the calc() function in magSqr.C calls the templated calcMagSqr function for each data type as shown below. How

bool Foam::functionObjects::magSqr::calc()
{
    bool processed = false;

    processed = processed || calcMagSqr<scalar>();
    processed = processed || calcMagSqr<vector>();
    processed = processed || calcMagSqr<sphericalTensor>();
    processed = processed || calcMagSqr<symmTensor>();
    processed = processed || calcMagSqr<tensor>();

    return processed;
}
Tags:
Steps To Reproduce: In order to reproduce the problem, add the following fucntionObject into controlDict functions subdictionary of any tutorial (tested with compressible "aerofoilNACA0012" tutorial):

    magSqrU
    {
        type magSqr;
        functionObjectLibs ("libfieldFunctionObjects.so");
        field U;
        writeControl timeStep;
        writeInterval 1;
    }
Additional Information:
System Description
Attached Files:
Notes
(0011642)
henry   
2020-10-27 15:36   
That is correct. If we remove the warning messages then the user would not know if they have selected a field that does not exist. Personally I don't mind either way and am happy to remove the warning if that is what most users would prefer.
(0011643)
peksa   
2020-10-27 15:56   
There is a point to include the message as well, you're right. Could we consider having a general "checkExistence()" function in the constructor or in the calc() function, which would throw a warning only if no variable name with any dataType is found.

Only downside of having Warnings appearing always is that when using functionObjects at every time step (or very often), the log files become bloated with them which can be annoying and I could imagine that it could mislead the user in some cases during debugging. In particular if one wants to utilize various functionObject producing Warnings like this. And I think when creating complex simulations, this may be a case.

Let me know your thoughts.
(0011644)
henry   
2020-10-27 15:59   
The warning needs to be delayed until after all the types are tested e.g.:

bool Foam::functionObjects::magSqr::calc()
{
    bool processed = false;

    processed = processed || calcMagSqr<scalar>();
    processed = processed || calcMagSqr<vector>();
    processed = processed || calcMagSqr<sphericalTensor>();
    processed = processed || calcMagSqr<symmTensor>();
    processed = processed || calcMagSqr<tensor>();

    if (!processed)
    {
        cannotFindObject(fieldName_);
    }

    return processed;
}

This change will need to be made to

field/CourantNo/CourantNo.C
field/Lambda2/Lambda2.C
field/PecletNo/PecletNo.C
field/Q/Q.C
field/components/componentsTemplates.C
field/ddt/ddtTemplates.C
field/div/divTemplates.C
field/enstrophy/enstrophy.C
field/fieldsExpression/fieldsExpressionTemplates.C
field/flowType/flowType.C
field/grad/gradTemplates.C
field/log/log.C
field/mag/magTemplates.C
field/magSqr/magSqrTemplates.C
field/pressure/pressure.C
field/randomise/randomiseTemplates.C
field/scale/scaleTemplates.C
field/streamFunction/streamFunction.C
field/vorticity/vorticity.C
field/wallHeatFlux/wallHeatFlux.C
(0011645)
peksa   
2020-10-27 19:34   
Hey,

I implemented a solution according thoughts above. So I extended the functionObjects::fieldExpression::foundObject function to include "bool verbose" variable to control verbosability. For example, in PecletNo.C it would be beneficial to keep the Warning behavior as it is, i.e. verbose=true, while in magSqr it would be set to false.

Regarding a case when the field does not exist, I realized that the functionObjects::fieldExpression::execute() includes already a warning which is activated if the calc() returns false (see below). Hence, I think it's not necessary to have a separate cannotFIndObject(fieldName_) in calc().

What do you think?


bool Foam::functionObjects::fieldExpression::execute()
{
    if (!calc())
    {
        Warning
            << " functionObjects::" << type() << " " << name()
            << " failed to execute." << endl;

        // Clear the result field from the objectRegistry if present
        clear();

        return false;
    }
    else
    {
        return true;
    }
}
(0011646)
henry   
2020-10-27 20:05   
commit f7848e62a1722fb8a99ee67ba2fa8d229d50d8cd (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Tue Oct 27 20:03:19 2020 +0000

    functionObjects: Emit warning messages only for field names which do not exist for any type
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3583
(0011647)
henry   
2020-10-27 20:07   
> I realized that the functionObjects::fieldExpression::execute() includes already a warning which is activated if the calc() returns false

It does not provide any information about why it failed, i.e. that the field name could not be found.
(0011648)
peksa   
2020-10-28 07:13   
Looks good and effective solution which seems to work.


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

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

Best,

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


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

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

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

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

I am able to run Docker hello world

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

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

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

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

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

Continuing with builtin reader: paraFoam -vtk

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

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

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

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

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

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

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

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

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

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

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

The result is the following error:

./makeParaView

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

Do you have any idea what can I do?

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

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

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

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

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

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

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

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

    sudo apt install libpng-dev

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

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

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

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

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

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

    foam
    ./Allwmake

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

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

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

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

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

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

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

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

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

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

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

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

Then explicitly run:

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

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

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

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

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

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

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

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


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

 :-)

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

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

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

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

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

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

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


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

Here is a patch which adds the missing copy calls.

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

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


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


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

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

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

With the regex option off.

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

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

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

outputName whatever_name;

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

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

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

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

and so on.

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

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

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

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

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

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

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

To run the case, type in the terminal:

    $> sh run_solver.sh

It will run simpleFoam only one iteration.


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

    kOmegaSST:G
    (omega*yWall)


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

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

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

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

FOAM exiting


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

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


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

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

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

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

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


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

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

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

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

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

with the regex option off

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

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

You can contact the OpenFOAM Foundation:

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

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


Then use the following functionObject,


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

    enabled on;

    writeControl outputTime;

    regExp off;

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

I believe it should be as follows:

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

This issue also applies to the development version.

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

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

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

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

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

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


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


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

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


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

After running icoFoam, here's the output:

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

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

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

Add to the end of 'controlDict':

functions
{

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

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

        regionType all;
        operation none;

        fields
        (
            p
        );
    }

}

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

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

numberOfSubdomains 2;

method simple;

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

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

Run:

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

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

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


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

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

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

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

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

Attached files:

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

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


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

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

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

   sourceFile = "singlePhaseTransportModel/singlePhaseTransportModel.H";

then the result will be:

   sourcePath = "singlePhaseTransportModel?";

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

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

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

The proposed solution is to use the attached changes:

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

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

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

   sourcePath[basePos - sourceFile] = 0;

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

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

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

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

would be even more explicit, see

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

Marking this issue as resolved in the commit above.

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


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

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

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

           //- Default precision
        static unsigned int precision_;

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

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

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

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


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

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

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

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

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

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

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

Time = 0.0015


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

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

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

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

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

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

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

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

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



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

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

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


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

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


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

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

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

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


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

Tags:
Steps To Reproduce: using namespace Foam;

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

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

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

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

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

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

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

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



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

// STL reverse_iterator (not really -Petteri)

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

and implemeting the functions as:

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

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

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


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


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

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

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

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

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

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

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


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

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

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


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

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

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

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

Applying these changes, the diff would be as follows:

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


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

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

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


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

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

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

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

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

            return tfvm;
        }

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

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

   nOuterCorrectors 5;

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

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

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

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

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

    faceExplicitCellImplicit
    faceExplicitCellLagged
    faceImplicit

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

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

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

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


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

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

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

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

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

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

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


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

In versions older than 19, MPI_ROOT needed to point to

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

It now should point to:

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

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

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

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

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

_foamAddLib $MPI_ARCH_PATH/lib/release

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


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


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

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

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

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

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

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

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

    residualControl
    {
        T 1;
    }

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

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

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

$> sh run_all.sh

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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


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

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


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

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



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


file:


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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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


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

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

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


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

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

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

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

    forAll(wallHeatFluxBf, patchi)
    { ...

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

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

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


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

grep -r lcompressibleTransportModels:

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

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

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

    Removed redundant library link statements


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

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

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

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


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

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

Resolved by commit 53ac3f223ad399df78ec40f72bc271776356c68d


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

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

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

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


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

I've attached a patch that implements this.

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

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

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

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

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

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

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

commit 4be01b4e70e4bab877346cce52900a59fd6bfeac

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


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

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

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

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

Create mesh for time = 1e-06

Reading thermophysical properties

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

Reading field U



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

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

FOAM aborting

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

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

blockMesh
decomposePar
mpirun -np 4 rhoCentralFoam -parallel
reconstructPar

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

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

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


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

instead of values based p_rgh.

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

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

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

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

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

while in the 0.001/p_rgh file we can se that

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


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

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


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


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

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

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

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

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

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


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

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

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

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

Outer Iteration = 0

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

    Inner iteration = 0

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

fields (T);

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

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

Thanks.


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

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

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

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


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


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

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

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

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


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

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

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

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

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

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

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


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


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

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

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

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

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

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

If it does give the same error, then:

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

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

3- Then run the following commands for installing:

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

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


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

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

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


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

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

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

When I tried again, I got:

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

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

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


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

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

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

Have a nice day,

Emeline

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


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


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

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

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

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

        cellSet cells(mesh, setName);

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

Best regards,

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

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

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

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

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

Best regards,

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


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

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

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

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

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

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


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

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

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

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

```
    start #codeStream
    {

      code
      #{

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

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

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


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

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


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

Any help would be greatly appreciated.

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

An extract of the surfaces dictionary file:

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

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

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

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

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

            filtering none;

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

            type plane;
            .
            .
            .
            triangulate false;

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

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

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

    filtering none;

instead and in place of

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

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

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

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

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

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

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

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

Thanks,
Jeroen


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

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

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

which is more recent than commit-7fdfe4224aad.

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

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

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


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

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

Resolved by commit 30970970030fe6100cb75d7bff9c5e6eb9b54645


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

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

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


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


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

echo "test 4;" > system/test

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

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

Run the case manually:

blockMesh
setFields
decomposePar
foamJob -p interFoam

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



This is the output:

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

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

Does using

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

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

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


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

        $FOAM_SRC/lagrangian/basic/particle/particleTemplates.C

is unused. I think it can be removed.

Happy New Year,
/federico
Tags:
Steps To Reproduce: Just recompile the code from scratch or compile a custom solver using the lagrangian class.

Additional Information:
System Description
Attached Files:
Notes
(0011008)
henry   
2019-12-30 07:45   
Resolved by commit b460b9e93d2c67da2fd534118efeb58236efe640


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3417 [OpenFOAM] Feature minor always 2019-12-23 09:43 2019-12-23 10:46
Reporter: jkau Platform: Linux  
Assigned To: henry OS: CentOS  
Priority: normal OS Version: 8  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: rigidBodyMeshMotionSolver does not account for force ramp
Description: force ramp is only included in rigidBodyMeshMotion, but not in rigidBodyMeshMotionSolver. Attached path fixes this issue
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: ramp.patch (3,321 bytes) 2019-12-23 09:43
https://bugs.openfoam.org/file_download.php?file_id=2861&type=bug
Notes
(0011000)
henry   
2019-12-23 10:46   
I could not apply the patch you provided as it was not compatible with the latest OpenFOAM-dev. However I have transferred the ramp functionality from rigidBodyMeshMotion to rigidBodyMeshMotionSolver.

Resolved by commit 5a2956218038d46253d5897ea945365cc99f124d


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3416 [OpenFOAM] Bug minor always 2019-12-20 16:39 2019-12-21 06:24
Reporter: wwzhao Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: Inconsistent behavior between foamGet and findEtcDirs
Description: In foamGet, line 149, it searches file at "$WM_PROJECT_INST_DIR/site/$WM_PROJECT_VERSION/etc".

While in findEtcDirs function in etcFiles.C, line 87, it searches file at "searchDir/"site/etc"/FOAMversion".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010997)
henry   
2019-12-20 23:01   
I have updated etcFiles.C to be consistent:

commit 33cfa1319873af9eab9df954e835a87e3b6743a3 (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://openfoam.org>
Date: Fri Dec 20 23:00:26 2019 +0000

    etcFiles: Corrected handling of "site" to correspond to the documentation
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3416

let me know if this resolves the issue you are having.
(0010998)
wwzhao   
2019-12-21 03:24   
Thank you, henry. It is resolved.
(0010999)
henry   
2019-12-21 06:24   
Resolved in OpenFOAM-7 by commit 33cfa1319873af9eab9df954e835a87e3b6743a3
Resolved in OpenFOAM-dev by commit 000a3bbd8dcff2fb00250ea07310a16e3db8a835


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3413 [OpenFOAM] Bug minor always 2019-12-17 08:35 2019-12-19 14:25
Reporter: SteffenB Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: foamSetupCHT creates wrong regionProperties if no fluid included
Description: When using the template file for creating a chtMultiRegionFoam case regionProperties requires an entry for fluid. If no fluid is included in the case (pure conduction model) the "foamSetupCHT" command creates a regionProperties file containing this:
regions 1 ( solid 2 ( body1 body2 ) );

The required structure for chtMultiRegionFoam in this case would be
 regions 2 ( fluid 0 () solid 2 ( body1 body2 ) );

I guess this just needs to be changed in the script of foamSetupCHT.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: regionProperties_case.zip (76,611 bytes) 2019-12-18 12:58
https://bugs.openfoam.org/file_download.php?file_id=2858&type=bug
Notes
(0010987)
henry   
2019-12-17 14:12   
Could you provide a suitable case and steps to reproduce the problem?
(0010989)
SteffenB   
2019-12-18 12:58   
Ok. I modified the chtMultiRegionFoam tutorial case of the coolingSphere to fit my problem. I renamed the "fluid" region into outerSolid and adjusted the boundary in the templates/solids/T file to fit.
Then i ran "Allmesh" and used "foamSetupCHT" afterwards. This way the problematic regionProperties file is created in constant. And chtMultiRegionFoam stops, when started, because "fluid" is missing in the regionProperties file.
After adjusting this file the way I previously mentioned (I appended the correct regionProperties file in the main folder of the given example), the simulation works flawlessly.
(0010990)
henry   
2019-12-19 14:25   
Resolved by commit a9ddd758e8f16815c7c3252867844af03437f63b


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3409 [OpenFOAM] Bug minor always 2019-12-09 08:39 2019-12-13 08:18
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Regression bug in Ensight part
Description: In commit (https://github.com/OpenFOAM/OpenFOAM-dev/commit/409548cbccac26e5c9632d2543505f659da58945)

"os.writeKeyword" was replaced with "writeKeyword(os, ..)" and I assume this was made with search&replace with the assumption that os is a regular OStream. However, in some Ensight-related files os is "ensightGeoFile" or "ensightFile", which have their own specializations of writeKeyword (=write + add newline + some additional logic). The commit makes them use the regular writeKeyword which produces invalid files due to missing newline.

I have attached a diff-file which simply reverses the changes in the affected files.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: patch.diff (3,592 bytes) 2019-12-09 08:39
https://bugs.openfoam.org/file_download.php?file_id=2852&type=bug
Notes
(0010975)
henry   
2019-12-10 09:58   
Is the EnSight converter still needed? My understanding is that EnSight is now released with an OpenFOAM reader, can we now drop the reader and converter supplied with OpenFOAM?
(0010977)
tniemi   
2019-12-10 11:12   
Well, I don't know about the EnSight software, but I have found the EnSight format to be better than VTK for sampled surfaces. ParaView can read EnSight and the format allows to store mesh in a separate file, which combined with binary writing can reduce disk space usage by a huge fraction compared to (legacy) VTK-files where each time step must have a copy of the surface mesh.
(0010979)
henry   
2019-12-12 13:09   
resolved by commit 52255e53a7a983995aa2e27b64b8fcc3399d15b6


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3390 [OpenFOAM] Bug major always 2019-11-18 12:57 2019-12-12 11:38
Reporter: MSontheimer Platform: Unix  
Assigned To: will OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Wrong liquid properties coefficients of ethanol (Cp, h)
Description: The calculation of liquid properties "heat capacity Cp" and "enthalpy h" of ethanol (C2H5OH) based on the NSRDSfunc0 function is wrong due to wrong coefficients. This was found by comparing the OpenFOAM calculations with CoolProp 6.3.0 (see attached image) and literature data.

I don't have access to the NSRDS data base, so I cannot check the coefficients reported there. However, one could also find new coefficients based on the CoolProp database (see additional information).
Tags:
Steps To Reproduce: Use the NSRDS functions implemented in $FOAM_SRC/thermophysicalModels/thermophysicalProperties/thermophysicalFunctions/NSRDSfunctions with the coefficients provided in $FOAM_SRC/thermophysicalModels/thermophysicalProperties/liquidProperties/C2H5OH/C2H5OH.C and calculate heat capacity and enthalpy for different temperatures and compare the results with literature data.
Additional Information: One can use CoolProp to find new coefficients for ethanol. A least-squares fit within the temperature range T=[200K, 350K] (up to boiling temperature) for NSRDSfunc0 leads to the following coefficients for the heat capacity of ethanol:

Cp_
(
        3086.27257308567,
       -13.9017298192482,
        0.04495256866223873,
       -1.89534803995077e-05,
        0.0,
        0.0
)

with an average error of 0.024% and maximum error of 0.062%.

The coefficients for enthalpy are found by integration, and the integration constant is calculated from enthalpy of formation and latent heat (consistency for "latentHeat"-mode, see https://bugs.openfoam.org/view.php?id=3085):

h_latent = h_vapor - h_liquid => h_latent(T_std) = h_fv - h_liquid(T_std) => h_liquid(T_std) = h_fv - h_latent(T_std).

The latent heat of vaporization is calculated using the OpenFOAM coefficients (since they agree with the CoolProp data), and the enthalpy of formation of vapor is h_fv = -235.31e6 J/kmol (Çengel & Boles: Thermodynamics: An Engineering Approach. 2006), and T_std=298.15K is the standard-state temperature.

This finally leads to the following coefficients:

h_
(
       -6710293.74515003,
        3086.27257308567,
       -6.95086490962410,
        0.01498418955407958,
       -4.73837009987693e-06,
        0.0
)

Results with old and new coefficients are shown in the attached images. Experimental data for Cp are taken from https://webbook.nist.gov/cgi/cbook.cgi?ID=C64175&Mask=2.
Attached Files: OpenFOAM_CoolProp_Comparison.png (299,110 bytes) 2019-11-18 12:57
https://bugs.openfoam.org/file_download.php?file_id=2832&type=bug
comparison_old_new_coeffs.png (56,168 bytes) 2019-11-18 12:57
https://bugs.openfoam.org/file_download.php?file_id=2833&type=bug
Notes
(0010926)
henry   
2019-11-20 12:45   
If someone here has access to the NSRDS database it would be REALLY useful if all the liquid properties coefficients could be checked and corrected as necessary.
(0010978)
will   
2019-12-12 11:38   
We now have obtained (with some difficulty) a copy of the 1985 Daubert and Danner reference (see NSRDS0ThermophysicalFunction.H). The liquid Cp coefficients were clearly taken from here and there are two mistakes; "b" is a factor of ten too large, and "c" has the wrong sign. The correct set is as follows:

    Cp_
    (
        2052.57331394213,
       -0.121990926653498, // <-- Was -1.21990926653498
       -0.00714146172046278, // <-- Was 0.00714146172046278
        5.20523562482363e-05,
        0.0,
        0.0
    ),

The Cp/H plots are now much closer similar to yours, but there is still a noticeable difference (about 13%). The referred data is old and is probably not as accurate as the new values that you have fitted. However, in this instance, I think we have to implement something for which we can provide a reference. If you want to use your coefficients you can do so via the "liquid" type which lets you choose NSRDS functions and coefficients at run-time.

Resolved in dev by https://github.com/OpenFOAM/OpenFOAM-dev/commit/d37fbcc39c834c2bbc436d0e5dd5e588aede0b5a


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3405 [OpenFOAM] Bug text always 2019-12-04 14:25 2019-12-07 13:56
Reporter: HTauber Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: Typos in User Guide
Description: Some typos in User Guide version 7 from 10th July 2019
Tags:
Steps To Reproduce: file appended
Additional Information:
System Description
Attached Files: OpenFOAMUserGuide-A4_korr.pdf (1,133,814 bytes) 2019-12-04 14:25
https://bugs.openfoam.org/file_download.php?file_id=2851&type=bug
Notes
(0010969)
chris   
2019-12-07 12:21   
Thanks for a very comprehensive set of typo corrections. It was a great job!
The corrections have been incorporated in the Guide and will be pushed to repositories shortly.
Thanks again,
Chris
(0010970)
henry   
2019-12-07 13:56   
Resolved in OpenFOAM-7 by commit e9752a8928897c5c4240a941307308dce5ae1b3c
Resolved in OpenFOAM-dev by commit 5ae7052e12be90559816628850356911adb911f5


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3407 [OpenFOAM] Bug text always 2019-12-05 12:18 2019-12-05 22:41
Reporter: tniemi Platform:  
Assigned To: henry OS:  
Priority: low OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Minor typos in surfaceInterpolate function object
Description: There are very minor typos in surfaceInterpolate function object, the description has been likely copied from nearWallField.

In line 52 (https://github.com/OpenFOAM/OpenFOAM-dev/blob/c0cffb357da44ede4a26554caa2563d31d5757be/src/functionObjects/field/surfaceInterpolate/surfaceInterpolate.H#L52) the "type name: nearWallFields" should be "type name: surfaceInterpolate". Also, in line 45 the example refers to pNear and UNear, which could be named eg. pInterp and UInterp or so.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010964)
henry   
2019-12-05 22:41   
Resolved by commit d32e012238b74ce7383c904267087efd132d8f7a


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3397 [OpenFOAM] Bug minor always 2019-11-26 14:21 2019-11-26 16:36
Reporter: handrake0724 Platform:  
Assigned To: will OS:  
Priority: normal OS Version:  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: Airy wave makes an error when wave length is less than 2
Description: in wave tutorial of tutorial/multiphase/interFoam/liminar/wave,
if Airy wave has the following setup (wave length being less than 2 or wave number being larger than pi), it make an overflow error in exp or sinh functions.
But the Airy wave setup has nothing wrong in linear wave theory point of view.

waves
(
    Airy
    {
        length 2;
        amplitude 0.01;
        phase 0;
        angle 0;
        // depth 10; // for shallow
    }
)

call stack shows the error was originated from waveSuperposition::UGas as shown below

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/usr/lib/libc.so.6"
#3 __sinh_finite in "/usr/lib/libm.so.6"
#4 sinhf32x in "/usr/lib/libm.so.6"
#5 Foam::sinh(Foam::Field<double>&, Foam::UList<double> const&) at ??:?
#6 Foam::sinh(Foam::tmp<Foam::Field<double> > const&) at ??:?
#7 Foam::waveModels::Airy::vi(int, double, Foam::Field<Foam::Vector2D<double> > const&) const at ??:?
#8 Foam::waveModels::Airy::velocity(double, Foam::Field<Foam::Vector2D<double> > const&) const at ??:?
#9 Foam::waveSuperposition::velocity(double, Foam::Field<Foam::Vector<double> > const&) const at ??:?
#10 Foam::waveSuperposition::UGas(double, Foam::Field<Foam::Vector<double> > const&) const at ??:?

or

#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/usr/lib/libc.so.6"
#3 ? in "/usr/lib/libm.so.6"
#4 expf64 in "/usr/lib/libm.so.6"
#5 Foam::exp(Foam::Field<double>&, Foam::UList<double> const&) at ??:?
#6 Foam::exp(Foam::UList<double> const&) at ??:?
#7 Foam::waveModels::Airy::vi(int, double, Foam::Field<Foam::Vector2D<double> > const&) const at ??:?
#8 Foam::waveModels::Airy::velocity(double, Foam::Field<Foam::Vector2D<double> > const&) const at ??:?
#9 Foam::waveSuperposition::velocity(double, Foam::Field<Foam::Vector<double> > const&) const at ??:?
#10 Foam::waveSuperposition::UGas(double, Foam::Field<Foam::Vector<double> > const&) const at ??:?


 
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010941)
will   
2019-11-26 16:36   
It's z/(2*pi*l), or z*k that when much greater than 2 triggers the error, not the length/wavenumber itself. That's good, because otherwise we'd have an issue with clipping a dimensioned number.

My suspicion is that if the decay functions (exp/sinh/etc...) are overflowing, then the parameters are unlikely to be realistic. In this example, setting an amplitude of 1cm in a domain 600m tall... However, it is preventable by similar means to some clipping that we already do for depth, so there's not really any disadvantage in your proposal.

Resolved by https://github.com/OpenFOAM/OpenFOAM-dev/commit/d0768e6039ba526d4fde446fd22fd6ff76577417


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3386 [ThirdParty] Bug text always 2019-11-13 01:28 2019-11-26 15:12
Reporter: lichuanlong Platform: Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: the guide for compile openfoam need upgrade .
Description: https://openfoam.org/download/source/software-for-compilation/
In 1st step of compile preview ,there is an setting for qt:
export QT_SELECT=qt4

if qt set to 4, there will be errors when compile preview.

the error like this below.

CMake Error at VTK/CMake/vtkQt.cmake:6 (message):
  Expected value for VTK_QT_VERSION is '5'
Call Stack (most recent call first):
  VTK/GUISupport/Qt/CMakeLists.txt:1 (include)


-- Configuring incomplete, errors occurred!
See also "/home/parallels/myOpenFOAM/ThirdParty-7/build/linux64Gcc/ParaView-5.6.0/CMakeFiles/CMakeOutput.log".
See also "/home/parallels/myOpenFOAM/ThirdParty-7/build/linux64Gcc/ParaView-5.6.0/CMakeFiles/CMakeError.log".
Tags:
Steps To Reproduce: export QT_SELECT=qt4
and run makeParaView
Additional Information: I think it should be set to 5
export QT_SELECT=qt5
or don't use QT_SELECT
System Description
Attached Files:
Notes
(0010920)
chris   
2019-11-18 09:27   
Updated the compilation information.
We are using ParaView 5.6.x now, which is not properly supported by the system libraries of Ubuntu 16.04.
So the instructions use a minimum Ubuntu version of 18.04 now and install QT5, deprecating QT4.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3393 [OpenFOAM] Feature minor always 2019-11-20 13:13 2019-11-21 13:02
Reporter: blttkgl Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: low OS Version: 15.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: ISAT statistics
Description: Hey,

Original reporter from https://bugs.openfoam.org/view.php?id=3392

I re-checked the patch provided by Prof. Contino, and apparently there is a bug where he removed the timeIncr variable added to the cpu times, so the library won't compile without undefined variable.

I provide a patch that should work, attached. I unfortunately do not have the dev installed in my workstation, so maybe you could try it.

Pseudocode is:

Initialize time (line 629)
Add the time it takes to search the tree (line 642)
initialize time once more (line 650)
add the time it takes for mechanism reduction (line 658)
add the time for solving chemistry (line 695)
add the time for add (line 722) or grow (line 727)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: TDACChemistryModel.C (23,405 bytes) 2019-11-20 13:13
https://bugs.openfoam.org/file_download.php?file_id=2836&type=bug
ISAT_statistics_new.png (1,682,601 bytes) 2019-11-21 12:46
https://bugs.openfoam.org/file_download.php?file_id=2837&type=bug
ISAT_statistics_old.png (1,726,831 bytes) 2019-11-21 12:46
https://bugs.openfoam.org/file_download.php?file_id=2838&type=bug
ISAT.patch (2,501 bytes) 2019-11-21 12:46
https://bugs.openfoam.org/file_download.php?file_id=2839&type=bug
printCPUT.py (10,721 bytes) 2019-11-21 12:46
https://bugs.openfoam.org/file_download.php?file_id=2840&type=bug
Notes
(0010928)
henry   
2019-11-20 14:27   
Thanks for the additional report about the patch, I have reverted it pending a version that compiles and tested in OpenFOAM-dev.
(0010929)
blttkgl   
2019-11-21 12:46   
Hey,

I compiled and tested the version I posted earlier on OpenFOAM dev.

Steps to reproduce:

- Run the counterFlowFlame2D_GRI_TDAC tutorial with reduction->off and tEnd=0.25 seconds on 4 processors..
- Use the (quite messy) python script I provide to look at the cpu statistics of the ISAT for old and new way.

You can see in figures (especially bottom middle figure), the cpu_solve is now not included in cpu_add and cpu_grow, which shows more clearly that even utilizing ISAT majority of the time is still spent on solving the ODE, and not binary tree add/grow operation, which is what one might get from the old way.

I also attach a patch that could be applied to the current -dev head.

Best,

Bulut Tekgul
(0010930)
blttkgl   
2019-11-21 12:46   
python code
(0010931)
henry   
2019-11-21 13:02   
Thanks for the correction

Resolved by commit e18c81e84ff3cd5f293001585489d966d7189dd0


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3392 [OpenFOAM] Feature minor always 2019-11-20 08:24 2019-11-20 13:07
Reporter: blttkgl Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: low OS Version: 15.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: ISAT statistics are misleading
Description: In TDACChemistryModel, the cpu time statistics generated for ISAT are a bit misleading.

Algorithm goes so that for each cell:

* If retrieve is successful, time it takes is written to cpu_retrieve
* If retrieve returns false, chemistry is solved and cpu time written to cpu_solve
* Then this solved chemistry is either added to the binary tree, or used to grow an existing binary tree. Time it takes for this operation is written to cpu_add or cpu_grow.

Currently, cpu_add and cpu_grow also includes to time for solving the chemistry cell, so cpu_add = addTime+ solveTime and cpu_grow = growTime + solveTime. When processing the statistics, especially for a parallel job where the user is trying to locate the bottleneck rank for each individual operation, this may be misleading.

Of course one can simply substract cpu_solve from cpu_add and cpu_grow for each time step, but I think cpu_add and cpu_grow should only reflect the time it takes to perform those individual operations.
Tags:
Steps To Reproduce: In OpenFOAM-dev, in OpenFOAM-dev/src/thermophysicalModels/chemistryModel/chemistryModel/TDACChemistryModel/TDACChemistryModel.C , check line 697 to 734

Additional Information:
System Description
Attached Files: TDACChemistryModel.C (23,390 bytes) 2019-11-20 12:27
https://bugs.openfoam.org/file_download.php?file_id=2835&type=bug
Notes
(0010924)
fcontino   
2019-11-20 12:27   
This is an excellent point. The statistics would be easier to understand without accumulation in the different times. I have adjusted the code accordingly. Could you please check if it works as you think is more efficient? (see uploaded file)
(0010925)
blttkgl   
2019-11-20 12:36   
Exactly, timeTmp (solve time) is removed from addNewLeafCpuTime and growCpuTime. We are using the ISAT logs like this and it makes more sense when benchmarking the performance.


Bulut
(0010927)
henry   
2019-11-20 12:51   
Resolved by commit f66ea315840b4e2bfb86f522a9467adef89562a9


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3389 [OpenFOAM] Bug major always 2019-11-15 06:20 2019-11-15 09:03
Reporter: adcpk Platform: Linux  
Assigned To: henry OS: Ubuntu  
Priority: high OS Version: 18.04.3 LTS  
Status: resolved Product Version: 7  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 7  
    Target Version:  
Summary: instantaneous reaction rate is not performed
Description: When the reaction rate is set to instantaneous, the reaction is disappeared.
This bug is due to the mistake in "src/combustionModels/laminar/laminar.C", the instantaneous reaction rate is totally not performed in function "correct".

 
Tags:
Steps To Reproduce: add following set in constant/combustionProperties
integrateReactionRate off;
Additional Information: //openfoam6
template<class ReactionThermo>
 void Foam::combustionModels::laminar<ReactionThermo>::correct()
 {
     if (this->active())
     {
         if (integrateReactionRate_)
         {
             //some codes
         }
         else
         {
             this->chemistryPtr_->calculate();
         }
     }
 }

//openfoam7
template<class ReactionThermo>
 void Foam::combustionModels::laminar<ReactionThermo>::correct()
 {
     if (integrateReactionRate_)
     {
         //some codes
     }
 }

//suggested
template<class ReactionThermo>
 void Foam::combustionModels::laminar<ReactionThermo>::correct()
 {
     if (integrateReactionRate_)
     {
         //some codes
     }
    else
     {
         this->chemistryPtr_->calculate();
     }
 }
System Description
Attached Files:
Notes
(0010911)
henry   
2019-11-15 09:03   
Thanks for the report.

Resolved in OpenFOAM-7 by commit ca808c8420bf6f92640a723e576ab79c830d5ed2
Resolved in OpenFOAM-dev by commit e286cf4ef942c0a6951a92e5022cb98c5ea2ad28


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3361 [OpenFOAM] Bug major always 2019-10-07 11:12 2019-11-14 12:03
Reporter: niklas.wikstrom Platform: x86_64  
Assigned To: henry OS: Fedora  
Priority: normal OS Version: 29  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: snappyHexMesh region refinement contaminates entire geometry facet
Description: A distance refinement region sometimes refines entire triSurface facet. This happens when a refinement region entry specifies a distance that crosses at least one of the facet's edges.

The problem occurs in parallel or serial runs and with OpenFOAM versions 5 to dev (7).

On a geometry that has this problem it is allways reproducable, but manually generating a similar geometry to reproduce the problem is difficult.
Tags:
Steps To Reproduce: Extract attached snappyBugReportRoom.tgz, run blockMesh and snappyHexMesh.
Additional Information: The image file, attached, shows the overly refined facet and visualizes the distance refinement geometry object (pink), pointed at by the yellow line.
System Description
Attached Files: geomFacetRef.png (928,134 bytes) 2019-10-07 11:12
https://bugs.openfoam.org/file_download.php?file_id=2794&type=bug
snappyBugReportRoom.tgz (4,846 bytes) 2019-10-07 11:12
https://bugs.openfoam.org/file_download.php?file_id=2795&type=bug
snappyHexMeshM.C (46,072 bytes) 2019-10-08 09:08
https://bugs.openfoam.org/file_download.php?file_id=2796&type=bug
Notes
(0010802)
niklas.wikstrom   
2019-10-07 11:14   
Forgot to add: This issue is caused by the call to surfaces.setMinLevelFields(shells); in snappyHexMesh.C. Removing the call fixes the issue, but introduces other refinement problems.
(0010803)
wyldckat   
2019-10-07 16:23   
I've had this issue for years and never reported it because I wasn't aware of how much it affects others.

In a custom version we have internally, we have an option for turning off the following lines:
- Starting here: https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/mesh/snappyHexMesh/refinementSurfaces/refinementSurfaces.C#L440
- Ending here: https://github.com/OpenFOAM/OpenFOAM-7/blob/master/src/mesh/snappyHexMesh/refinementSurfaces/refinementSurfaces.C#L448

This has been a custom option for us here at our office, but I've never tested this further to see how this affects other geometries.

@niklas.wikstrom: Perhaps by only commenting out the lines I've pointed out, instead of simply commenting 'setMinLevelFields', does it reduce the occurrence of the refinement problems you've seen? Or do the same issue occur?
(0010804)
niklas.wikstrom   
2019-10-08 05:18   
Yes, It's been around, and I mostly have gotten around it through geometry refinements :-D

Thanks a lot! I'll try the modification.

/Niklas
(0010805)
niklas.wikstrom   
2019-10-08 09:08   
It seems to work fine, although I overloaded the setMinLevelFields() in a modified snappyHexMesh.C, thus keeping the src tree intact. (Attaching my local version of snappyHexMesh.C, this is for v5, but minor changes to dev)

Thank you again.

/N
(0010806)
henry   
2019-10-08 14:40   
This change could be put on an optional switch, what do you think would be an appropriate name for it?

A better option would be to change the refinement approach so that it isn't so sensitive to the aspect ratio of the triangles (I am assuming the issue is with long thin triangles), any thoughts?
(0010808)
wyldckat   
2019-10-08 15:38   
@henry: We defined the switch as 'triSurfacesLevelsOnly' in the 'castellatedMeshControls' dict.

I have the very vague idea that the problem occurs when the triangle was large/long enough to overlap multiple refinement regions, resulting in being affected by the other refinement definitions.

From what I can remember, there was no clear fix at the time when I saw and tried to fix this issue, only turning off that particular detection would do the trick.
(0010809)
niklas.wikstrom   
2019-10-08 15:54   
Good with a switch in the dictionary. Note, however, that the facet in my example above does not have a large aspect ratio; just three or so, but the facet gets refined as soon as the distance ref reaches across its edge(s?). The switch name 'triSurfacesLevelsOnly' might need some explanation ;-)

It would be interesting to know when the feature is needed, but I guess I'll figure it out if I run without it for a while.

Thanks for helping!
(0010810)
henry   
2019-10-08 16:06   
@niklas.wikstrom Do you have a better name in mind?

Is this feature needed at all? Shall I simply remove it?
If I add a switch what should the default be? If it is true how will people know that they need to set it to false?
(0010814)
niklas.wikstrom   
2019-10-08 16:57   
Very vague suggestions below, since I do not know what else the thing affects.

Name:
shellLevelToFacets

Default:
false
Will show faster if it's needed or not, set the default to false and wait for bug reports...

Needed?
I do not know, but I assume there was a good reason for it. Better keep it.
(0010816)
henry   
2019-10-08 17:25   
The problem is that if it is needed and was put in for good reason it should be on by default for backward compatibility unless we know for sure that it actually generally not needed and then we need to know for what cases it is needed so that we can inform people of the change in default behavior.
(0010818)
niklas.wikstrom   
2019-10-08 20:37   
I realise that. It is safer. I will run without the thing and if I find some inconsistency or find out what it is all about, I will report back.
/N
(0010888)
henry   
2019-11-12 16:10   
Is there any progress and/or recommendations on this or should I close the report?
(0010895)
niklas.wikstrom   
2019-11-13 14:34   
Hello!
I have not seen any issues with the feature turned off, but have not much statistics. However, I think it is a good idea to add the option "shellLayerToFaces" with default value "true" to snappyHexMesh. And then close the issue.
(0010896)
henry   
2019-11-13 14:39   
How should I document this change? Can any particular recommendations be made? When should users consider changing this switch?
If we don't say anything it will just be a hidden switch that no one knows about or knows how to use so there wouldn't be much point having it.
(0010897)
wyldckat   
2019-11-13 15:17   
If I'm not mistaken, the description can be along these lines:

   This option will allow tessellated surfaces (shells?) to inherit refinement levels from other overlapping features. If you see unwanted refinement spreading onto triangles, turn off this option.


As a side note, I very vaguely remember seeing this happen when larger triangles were overlapping smaller features that I wanted to have refined and yet the large triangle centres would get caught on the overlapping heuristic.
(0010901)
henry   
2019-11-14 12:03   
It is not clear for what cases this refinement condition is useful and given the difficulty in choosing a suitable name for the option, how to control it, what the default should be or when to recommend it should be switched on or off it makes sense to remove it for now and reinstate under an option if cases are found and reported which benefit from this option.

commit a64d71929f0a51229ef6c5603af1d1ca21dad5f1
Author: Henry Weller <http://openfoam.org>
Date: Thu Nov 14 11:51:13 2019 +0000

    snappyHexMesh::refinementSurfaces: Removed problematic shell refinement transfer to surface
    
                // Find out if triangle inside shell with higher level
                // What level does shell want to refine fc to?
                //
                // Note: it is not clear for what cases this additional requirement
                // is beneficial but for triangulated surfaces with triangles that
                // span refinement regions it introduces unnecessary refinement so
                // it has been removed.
                //
                // This option can be reinstated under a switch if cases are
                // provided which demonstrate the benefit.
                /*
                labelList shellLevel;
                shells.findHigherLevel(ctrs, minLevelField, shellLevel);
    
                forAll(minLevelField, i)
                {
                    minLevelField[i] = max(minLevelField[i], shellLevel[i]);
                }
                */


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3384 [OpenFOAM] Bug minor always 2019-11-11 10:26 2019-11-13 09:58
Reporter: HTauber Platform: GNU/Linux  
Assigned To: henry OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: resolved Product Version: dev  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: dev  
    Target Version:  
Summary: surfaceFieldValue causes error at inlet patches
Description: In the case tutorials/lagrangian/simpleReactingParcelFoam/verticalChannel I make an additional entry in controlDict/functions for the patch "inletSides".

    surfaceFieldValue2
    {
        type surfaceFieldValue;
        libs ("libfieldFunctionObjects.so");
        enabled yes;
        writeControl writeTime;
        log yes;
        writeFields no;
        regionType patch;
        name inletSides;
        operation weightedAverage;
        weightField phi;
        fields
        (
            T
            //p -> comes to an error
        );
    }

The result for the field "T" in postProcessing is as follows:

# Time weightedAverage(T)
0 -1.0787610941e+308
10 -1.7686424138e+308

For the field "p" I get an error at the run:

surfaceFieldValue surfaceFieldValue2 write:
    weightedAverage(inletSides) of T = -1.078761094e+308
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 double Foam::functionObjects::fieldValues::surfaceFieldValue::processSameTypeValues<double>(Foam::Field<double> const&, Foam::Field<Foam::Vector<double> > const&, Foam::Field<double> const&) const at ??:?
#4 double Foam::functionObjects::fieldValues::surfaceFieldValue::processValues<double>(Foam::Field<double> const&, Foam::Field<Foam::Vector<double> > const&, Foam::Field<double> const&) const at ??:?
#5 bool Foam::functionObjects::fieldValues::surfaceFieldValue::writeValues<double>(Foam::word const&, Foam::Field<double> const&, bool) at ??:?
#6 Foam::functionObjects::fieldValues::surfaceFieldValue::write() at ??:?
#7 Foam::functionObjects::timeControl::write() at ??:?
#8 Foam::functionObjectList::start() at ??:?
#9 Foam::Time::run() const at ??:?
#10 Foam::Time::loop() at ??:?
#11 ? in "/opt/openfoam-dev/platforms/linux64GccDPInt32Opt/bin/simpleReactingParcelFoam"
#12 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#13 ? in "/opt/openfoam-dev/platforms/linux64GccDPInt32Opt/bin/simpleReactingParcelFoam"
Gleitkomma-Ausnahme
Tags:
Steps To Reproduce: tutorials/lagrangian/simpleReactingParcelFoam/verticalChannel
Additional Information:
System Description
Attached Files: