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