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