|
|
filter.png (130,414 bytes) |
|
|
> When running tutorials/modules/multicomponentFluid/filter one first encounters two sucessive errors: I don't get this error, in fact entries "thermo:mu" and "thermo:kappa" do no exist in any OpenFOAM-dev tutorials: git grep "thermo:mu" and git grep "thermo:kappa" return nothing and the case runs to completion. |
|
|
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 "(walls|cyc.*)" { type rebound; } would be changed to walls { type rebound; } in constant/cloudProperties. That way it becomes clear that particles are not supposed to rebound off the cyclics. |
|
|
OK, yes, if the carrier velocity opposes another force (i.e., gravity) then this makes quite a lot more sense. The bottom of a fluidised bed is a sensible place to apply a model like this. It seems to me that without the rebound on the cyclic, the filter case doesn't demonstrate anything useful beyond any of the other tutorials. So, I think, the obvious way to resolve this is just to delete it. Done here: https://github.com/OpenFOAM/OpenFOAM-dev/commit/9a4bcbf7f4daa6d0443c02bc30c26d5be33fb712 Indeed, an appropriate cloud function does not currently exist, and would have to be written. I appreciate that the Lagrangian library does not make this process convenient. On reflection, I'm not sure if this is the best way forward. A "patchType"-like specifier might be neater. I would have to think about it. In any case, either would require development effort, which would have to be paid for. If you want to go this route, please contact us: https://openfoam.org/contact |
- Anonymous
