There is a simple and rigorous route. Start from the divergence-free constraint Div v = 0 and apply the filter. Now only if the the filter width is homogeneous you can commute filtering and divergence. This results in a divergence-free filtered velocity.
|
2 Attachment(s)
Quote:
|
Admittedly, I haven't read what you wrote in detail, but what Filippo was referring to is a purely mathematical derivation whose result is present in several LES textbooks and papers.
The idea is that you apply the filter to the continuity equation then ask: does this filter commute with the derivarive? The constant filter width is not sufficient to ensure this, you need a constant kernel (the whole shape of the filter cannot change). If your filter commutes with the derivative then your continuity equation is just one for the filtered velocity, meaning that fluctuations must be divergence free as well. If it doesn't, the commutation error defines the divergence of the fluctuation field |
Quote:
yes, but the continuity equation is an example of why the LES has the devil inside... Just consider a FV code like Fluent for example, where the NSE equations are described to be solved in integral form (https://www.afs.enea.it/project/nept...th/node363.htm) while the filtered equations are described in differential form (https://www.afs.enea.it/project/nept.../th/node94.htm). Formally, the kernel is arbitrarily out of the convolution and that does not result in the divergence of the filtered velocity. |
Honestly, I don't feel like blaming Fluent technical documentation for this when the large majority of LES material has the same limitation, but I see what you mean
|
Quote:
Paolo, you're right but this issue should be reported massively by the users. |
I'm now writing the manual for my code and, while I don't have LES in it, I'm telling you, I would still code it in the correct way but I would have a hard time figuring out the best way to present it.
If it is a selling point, and I am deeply convinced that documentation is or should be a selling point for any mathematical software, you must be very careful in what you write and how you do it. Or, more simply, it might happen that the one in charge has just left the company, or any other non technical issue. It happens and the company can't simply afford someone else to go trough the same development to figure details out unless strictly necessary. This assuming that the one in charge of the development was indeed expert in LES in the first place, but it is largely unlikely to have a specialized developer for each code feature. In the end, they just used the good, old LES presentation which is in every paper or book. Who's gonna note or care about that beyond the two of us when, in practice, it also kind of works? At least they have a very well written manual that says almost everything about what the code does, which is very uncommon. |
Paolo but is that only a lack in documentation or something in the implementation is not really well done and the users are not aware of that? Grids for LES are practically never uniform and no explicit uniform filter is supplied in the codes.
Just to be more direct, should be addressed in the documentation that the residual of the continuity equation is satisfied only up to the magnitude of the order of the commutation term? Why an user should have a headache trying to drive the residual lower? |
Quote:
We know that solving a correctly coded set of FV equations is like doing a correct LES with a certain top-hat filter. So, I don't think that Fluent has any issue in its FV LES formalism. Where it might have problems is in its SGS models but that, again, is not a Fluent issue, it is pretty common as we know. Of course, there might be other numerical issues, like how certain equations are solved, etc., but again, I see no peculiarity in Fluent |
All times are GMT -4. The time now is 10:49. |