[aerosayan]

I'm not able to visualize and understand the benefits of high order schemes.
I know they improve accuracy, but i don't know or understand how much improvement we observe in the results.


Is there anyway we can visualize the improvements to understand why we use high order schemes?


Thanks

[sbaffini]

The doubt is, indeed, legit, but the reason is quite obvious when you think about it.

The primary reason is for applications where that accuracy is mandatory. Have you ever made the 1d experiment of transporting, say, a gaussian pulse again and again trough a domain with periodic boundaries? That is quite explanatory of why even second order is not typically sufficient. Think about DNS or LES, where the very scope is resolving the transport of flow structures across the domain. High order schemes allow this with very low dispersion and dissipation errors. Note that formal order of accuracy is not even that relevant here, as long as the spectral resolution of the scheme stays "close" to the ideal one. Most CFDers work with RANS or URANS, where this is less relevant, but orherwise it is a relevant use case.

The other one directly comes from the formal order of accuracy, which implies that, below a certain threshold, less grid points are required to reach the same accuracy.

However, I feel that the latter one is more of an academic workhorse in motivating these schemes than an actual thing. I mean, it is true, but when you compare total costs the picture becomes less clear, as algorithmic aspects come into play. Not only such schemes are less stable at large, but there are a lot of them and, in my opinion, no clear winner (as you have for 2nd order finite volume schemes).

Said orherwise, I think it is clear that a high order scheme is needed for certain applications. But promoting them at large using solely a motivation based on formal order of accuracy and required grid points is wrong because it doesn't take into account practical usability, especially in industrial contexts.

For example, a high order code is going to require a high order boundary description. Except maybe in aeronautics, I won't beleive anyone designs its own surfaces with, say, 3rd order accuracy. But even if they were, how are they going to produce them? Additive manufacturing? Seriously?

Of course, if you have a high order code it is still mandatory to handle high order boundaries in order to properly verify it.

[sbaffini]

So, to answer your question, a typical measure (which, however, I think is overinflated) is the number of required grid points for a given accuracy, when compared to low order codes.

[arjun]

As I have been on and off working on third order solver for last 2.5 years. This is my opinion based on this experience.

1. I have heard quite a lot that higher order is only for academics. Indeed when mesh gets tough the stability becomes very very tough to maintain.


So was the case, now the current version in Wildkatze is quite stable and i have been delibrately using tough meshes to develop it.

Stability part is more or less taken cared of.

2. Calculation costs. The cost per iteration is 90% more than of second order solver in steady mode and 40% or so in transient mode. (Because one can switch off calculation of expensive gradients after 2 or 3 inner iteration).

3. If the accuracy that it provide is almost same as 10 times or so finer mesh then there is huge reason to use it.

4. In the world of cloud computing, the cost of managing and transferring data is very important. Third order solvers generate less data for same accuracy.

So the case for higher order is , transient calculations on clouds etc.

PS: Whose's higher order you use matters. Not all higher orders are same. (Wildkatze is stable on the meshes others would be pain in A to use for example).

[FMDenaro]

Originally Posted by aerosayan

I'm not able to visualize and understand the benefits of high order schemes.
I know they improve accuracy, but i don't know or understand how much improvement we observe in the results.


Is there anyway we can visualize the improvements to understand why we use high order schemes?


Thanks

Think about a practical flow problem where you fix the grid size dimension h. Your question is now how about the solution changes while increasing the accuracy order on the same grid.
First, for this given mesh size, irrespectvely of the accuracy order, you cannot represent nothing in the solution having wavelengths smaller than 2*h (unresolved). Thus you have to consider an advantage in the resolution of the resolved wavelenghts. This can be formally analysed by means of the spectral accuracy analysis.
But, depending on the flow problems, at a given fixed mesh size, you could get a better solution using a lower order accurate scheme.

In conclusion, one of the real advantages could be supposed in the fact that high order schemes give a solution comparable to low order schemes on a coarser grid. But working using a greater h means you are resolving lesser wavelenghts. And even on a coarse grid the computational cost for a high order scheme could be high.

Thus, the answer is that the choice depends on the flow problem, on the formulation you want to use and on your personal experience in a particular scheme.

[digger]

I have another question in that spirit to experts from the forum. Maybe it is somewhat phylosophical. Since LES requires the use of low dissipation schemes due to implicit filtering isn't is that FV method of a second order put some extremely high requirements on mesh resolution comparing to high-order difference methods?

[FMDenaro]

Originally Posted by digger

I have another question in that spirit to Texperts from the forum. Maybe it is somewhat phylosophical. Since LES requires the use of low dissipation schemes due to implicit filtering isn't is that FV method of a second order put some extremely high requirements on mesh resolution comparing to high-order difference methods?

This question would drive to a long discussion...

For example, in ILES you actually use dissipative schemes!
Then FV methods are based on a smooth filter, that is a top-hat that is always second order accurate in terms of the pointwise solution. The accuracy order you are talking about is for the numerical flux function, not for the resolved variable.

[sbaffini]

Originally Posted by digger

I have another question in that spirit to experts from the forum. Maybe it is somewhat phylosophical. Since LES requires the use of low dissipation schemes due to implicit filtering isn't is that FV method of a second order put some extremely high requirements on mesh resolution comparing to high-order difference methods?

I think the most honest answer here is really the one provided by Filippo above (the first one).

But let me digress a little further. The mesh size is not always an ideal measure of the costs you have in HO codes. For example, Nek5000, a spectral element code, actually implies a Gauss-Lobatto grid of points within each element. So your grid has a step h, but the number of degrees of freedom and the resolution is not really linked to that h anymore. So, first of all, let us exclude these codes from the reasoning and just consider codes with a given grid that always has a one to one link with the actual stored variables, and achieve HO only trough stencil enlargement. In this case, the grid step h is both a measure of what you can resolve and of the costs.

In this scenario, what Filippo mentioned in very general terms for the accuracy vs costs of HO schemes, becomes impressively relevant for LES, even more so if you add to the picture the difference between implicit and explicit filtering. That is, for given h, what is the advantage A I get by going from order 2 to N and what its cost C? If I invest the same cost C in refining the grid and stay order 2, do i get the same advantage A? Turns out that, in general, it is very problem and code dependent and there is no clear answer, but there is a relevant amount of evidence where adding representable scales to your LES (i.e., lowering h), even if poorly resolved, is better than doing any math on less scales.

Note that I kind of superseded on this in my firts answer in favor of a more clear, textbook like, answer to the original question of Aerosayan.

In practical terms, however, this is how I would proceed:

1) fix the grid at what your memory/storage requirements allow using a 2nd order model for the computing costs

2) Engage in higher order schemes if the added costs (which is only computational now) are justified by the results and practically obtainable

[digger]

Originally Posted by FMDenaro

This question would drive to a long discussion...

For example, in ILES you actually use dissipative schemes!
Then FV methods are based on a smooth filter, that is a top-hat that is always second order accurate in terms of the pointwise solution. The accuracy order you are talking about is for the numerical flux function, not for the resolved variable.

Yes Professor, I would not want to start the discussion which probably was already addressed many times on that forum. Anyways, would you or other users be so kind to clarify a couple of my questions, even briefly:

“For example, in ILES you actually use dissipative schemes!”


1. Yes, but how their performance can be justified prior doing the actual simulation, not knowing the amount of dissipation the ILES produce?

“Then FV methods are based on a smooth filter that is a top-hat that is always second order accurate in terms of the pointwise solution.”


2. As far I understood the LES equations in theory results from mathematical filtering operation applied to the NS equations. However, in practice the filter is actually implicit it and is related to the discretization scheme applied and some characteristic size of the grid. So, is the actual filter you have mentioned second-order accurate or the FV discretization itself is a second-order approximation?


“The accuracy order you are talking about is for the numerical flux function, not for the resolved variable.”


3. Now I see. But if the flux is obtained by the second-order accurate approximation can we say something about the accuracy of particular variables?


I know these are the newbie questions and I will not contiune this discussion further.



Thank you

[FMDenaro]

Originally Posted by digger

Yes Professor, I would not want to start the discussion which probably was already addressed many times on that forum. Anyways, would you or other users be so kind to clarify a couple of my questions, even briefly:

“For example, in ILES you actually use dissipative schemes!”


1. Yes, but how their performance can be justified prior doing the actual simulation, not knowing the amount of dissipation the ILES produce?

“Then FV methods are based on a smooth filter that is a top-hat that is always second order accurate in terms of the pointwise solution.”


2. As far I understood the LES equations in theory results from mathematical filtering operation applied to the NS equations. However, in practice the filter is actually implicit it and is related to the discretization scheme applied and some characteristic size of the grid. So, is the actual filter you have mentioned second-order accurate or the FV discretization itself is a second-order approximation?


“The accuracy order you are talking about is for the numerical flux function, not for the resolved variable.”


3. Now I see. But if the flux is obtained by the second-order accurate approximation can we say something about the accuracy of particular variables?


I know these are the newbie questions and I will not contiune this discussion further.



Thank you

The amount of dissipation in ILES is formally evaluated by the local truncation error resulting from the discretization. Of course, a practical computation and the analysis of the statistics will confirm the resulting performance.


In FVM, the volume-averaged variable is mathematically a second order approximation of the pointwise- centered variable. Thus, a high order numerical flux reconstrution will reduce the error in the discretization of the surface integral of the fluxes but the computed variable remains a second order approximation of the pointwise one. But in LES we focus on the filtered variable and we want to solve the volume-averaged variable.
MAybe you could be interested in reading this


https://www.researchgate.net/publica...dy_Simulations

[sbaffini]

Originally Posted by arjun

As I have been on and off working on third order solver for last 2.5 years. This is my opinion based on this experience.

1. I have heard quite a lot that higher order is only for academics. Indeed when mesh gets tough the stability becomes very very tough to maintain.


So was the case, now the current version in Wildkatze is quite stable and i have been delibrately using tough meshes to develop it.

Stability part is more or less taken cared of.

2. Calculation costs. The cost per iteration is 90% more than of second order solver in steady mode and 40% or so in transient mode. (Because one can switch off calculation of expensive gradients after 2 or 3 inner iteration).

3. If the accuracy that it provide is almost same as 10 times or so finer mesh then there is huge reason to use it.

4. In the world of cloud computing, the cost of managing and transferring data is very important. Third order solvers generate less data for same accuracy.

So the case for higher order is , transient calculations on clouds etc.

PS: Whose's higher order you use matters. Not all higher orders are same. (Wildkatze is stable on the meshes others would be pain in A to use for example).

Going back to the original question, may I ask what has been the development cost of your HO implementation (with respect to the 2nd order one) and do you perceive its maintainment as an added cost with respect to the rest of your code? Would a novice working on your code be as confident with it with respect to the rest of the code? Did something like, say, having more than one integration point on the faces alter the code simplicity in a significant manner?

Genuine questions here, I'm really interested in your answer

[arjun]

Originally Posted by sbaffini

Going back to the original question, may I ask what has been the development cost of your HO implementation (with respect to the 2nd order one) and do you perceive its maintainment as an added cost with respect to the rest of your code? Would a novice working on your code be as confident with it with respect to the rest of the code? Did something like, say, having more than one integration point on the faces alter the code simplicity in a significant manner?

Genuine questions here, I'm really interested in your answer

Actually Wildkatze is not strictly a flow solver. It is a finite volume framework. The project's original name was FVUS (finite volume utilities and solvers). (It was later changed because i thought that like every other solver the name was boring. ).

Since its a framework, for me adding third order means that adding that part of the framework. Once it is there then models can easily use it and add the third order to it.


The framework related to third order consists of providing an extended stencil on a region. Also this shall take care of making proper parallel exchange and provided requested variables on that stencil. Once it is there rest of the work is easier.


It is not too much of work once added and it took me a week's time to do so. Once added does not need maintenance because code is not touched after that and stays in background.

Main problem associated with third order is to keep it stable with very very minimal use of limiters without giving on accuracy. It turned out that since gradients are used so much, third order is very sensitive to it.

Second order wildkatze is very very stable to the extend that if you set up the case, you will get the results provided there are no negative volumes. Third order is not that stable but it is still quite stable now.

Here is snippet from Wildkatze as to how it is used within a region visitor class:

  std::string        fname   =    getFiniteVolume().getName();
  FiniteVolumeExtend*  fvEx  =    getFiniteVolumeEx( fname );
  const double *  xce    =     fvEx->xC();
  const double *  yce    =     fvEx->yC();
  const double *  zce    =     fvEx->zC();

  double * Yx           =      getExtDvar ("volume-fraction");
  double * dYxdx     =      getExtDvar ("dvolume-fraction-dx");
  double * dYxdy     =      getExtDvar ("dvolume-fraction-dy");
   double * dYxdz     =      getExtDvar ("dvolume-fraction-dz");

These variables were exchanged in parallel before this region call as:

{
  setExtendedStencil            (true);

  std::vector < std::string > &  extVars      =          getExtendedStencilVariableNames();

  extVars      .     resize(4);
  extVars[0]   =    "volume-fraction";
  extVars[1]   =    "dvolume-fraction-dx";
  extVars[2]   =    "dvolume-fraction-dy";
  extVars[3]   =    "dvolume-fraction-dz";

}

Now each model just use the extended stencil just like this. Once used the memory for these variables on extended stencil will be deleted. Adds to bit of cost but does not create mess of maintaining variables on third order stencil. Only second order variables exist in the end.

[arjun]

Originally Posted by sbaffini

having more than one integration point on the faces alter the code simplicity in a significant manner?

This I answer separately. The part of the innovation is that solver never really stores these more integration points. It creates them when needed (still not storing them), it uses them and moves on.
This way everything else stays the same in the solver. The third order does not come into play until and unless some model requested the extended stencil. Till that point it does not exist.
First time it is requested it is created and stored. It only create points for parallel exchange and provide the geometric information but never creates those secondary integration points.
This way the solver switches to third order without disturbing rest of the code. You can also convert your code to third order that way. (Because extendedRegion is separate class and does not modify any code outside of it. )

[FMDenaro]

Well, a third order FV scheme should be quite stable (for example the QUICKEST),I suppose that problem is in the coupling with the time integration scheme

[arjun]

Originally Posted by FMDenaro

Well, a third order FV scheme should be quite stable (for example the QUICKEST),I suppose that problem is in the coupling with the time integration scheme

No experience with QUICKEST but in general when meshes have bad skew and aspect ratio things are tough and unstable. In the well behaving meshes usually things work out but in industry bad meshes are norm rather than exception.

[FMDenaro]

Originally Posted by arjun

No experience with QUICKEST but in general when meshes have bad skew and aspect ratio things are tough and unstable. In the well behaving meshes usually things work out but in industry bad meshes are norm rather than exception.

I see, complex geometries are common, however I worked using a QUICKEST-like method also on triangular unstructured grids and had no particular problems in the numerical stability.

[JBeilke]

Tetrahedra are not necessarily poor quality meshes. There is no face warpage and an aspect ratio of 1/1000 is also not possible :-)

[FMDenaro]

yes, often on such grids the problem is in the correct evaluation of the time step to allow for a numerical stability condition

[arjun]

Originally Posted by FMDenaro

yes, often on such grids the problem is in the correct evaluation of the time step to allow for a numerical stability condition

Problem is that it is not easy to do when mesh is bad. Sometimes you get stuck with a situation that can waste lots of your time.



As a user these can be frustrating. As a software developer I am of opinion that software should make user's life easier and not tough (if possible).