Options Anti-Aliasing in PyFR

Dear all,

My name is Antonio Garcia-Uceda, and I’m a researcher working on Flux Reconstruction Methods.

I have a question about the “Anti-Aliasing” technique available in PyFR in order to improve the stability of the method. I see there are several options available, so as to apply over-integration of the fluxes in the cell (<>), interfaces (<>), or div_flux (<>) in the cell, or coupling some of these together (<<flux | surf-flux>>, …).

Could you please let me know the difference in between these different options? I mean, Are there particular cases where an option turns out to be more efficient than the others in enhancing the stability? Which option do you users of PyFR utilise most often?

Also, which option is more efficient in terms of computational time?

Finally, I’ve seen that the combined options (<<flux | div-flux>>, …) are broken in PyFR (I get the following error message when launching PyFR: “Invalid anti-alias option”, which is an Exception raised in shapes.py). Is this normal, or perhaps I’'m setting something wrong in the .ini file?

Thanks a lot in advance for your help.

Best regards,
Amntonio

Hi Antonio,

I have a question about the “Anti-Aliasing” technique available in PyFR in order to improve the stability of the method. I see there are several options available, so as to apply over-integration of the fluxes in the cell (<>), interfaces (<>), or div_flux (<>) in the cell, or coupling some of these together (<<flux | surf-flux>>, …).

Yes, that is correct.

Could you please let me know the difference in between these different options?

flux: performs an approximate L2 projection of the flux in the volume of each element
surf-flux: performs an approximate L2 projection of the Riemann solver flux on the surface of each element
div-flux: performs an approximate L2 projection of \nabla\cdot f = \hat{\nabla}\cdot\hat{f}/|J|

I mean, Are there particular cases where an option turns out to be more efficient than the others in enhancing the stability? Which option do you users of PyFR utilise most often?

The most important two are flux and surf-flux, but div-flux can also be useful/required if the elements have non-constant Jacobians.

Finally, I’ve seen that the combined options (<<flux | div-flux>>, …) are broken in PyFR (I get the following error message when launching PyFR: “Invalid anti-alias option”, which is an Exception raised in shapes.py). Is this normal, or perhaps I’'m setting something wrong in the .ini file?

I think they need to be a comma separated list e.g. flux, surf-flux and not flux | surf-flux as your snippet implies you were using. Let us know if this fixes the issue.

Cheers

Peter

Hi Peter,

Indeed, replacing the “|” by the comma solves the issues. Thanks a lot.

There is a couple of points I think you didn’t answer in your previous email:

Which option for “Anti-Aliasing” do you normally use in PyFR? Is there any procedure for choosing the most appropriate one? I mean, you first attempt with one and if it doesn’t improve enough the stability you try other options?

Also, Have you done any tests on the performance (increase in both computational time and memory footprint) of each of the “Anti-Aliasing” options?

Finally, out of curiosity, I’ve observed in the sources of PyFR that when applying the “surf-flux” option with the navier-stokes solver, the L2 projection is applied on both the fluxes on the interfaces, as well as the common solution for the correction of the gradients. In my understanding, this last wouldn’t be needed since the common solution can be exactly integrated on the faces just with the flux points. Nevertheless, I presume that you do this in order to avoid to extrapolate the solution twice to the interfaces (to both flux and quad points), and most importantly to avoid having to transfer these two sets of data through MPI in a parallel computation. Could you please tell me whether I’m right with this?

Thanks a lot once more.

Best regards,
Antonio

Peter,

Sorry to bring up an old post but I was also wondering if you had any more guidance regarding recommended anti-aliasing options such as relative order of the over-integration vs. solution polynomial approximation, over-integration quadrature points vs solution quadrature points, etc.

Perhaps some of these points have been addressed in your recently accepted publication to the AIAA Journal, “High-Order Accurate Implicit Large Eddy Simulations of Flow over a NACA0021 Aerofoil in Deep Stall”. If so would it be possible to post a pre-print of this article?

Thank you,
Andy

Hi Andy,

Sorry for the very slow reply!

The full paper is now available open-access here: https://arc.aiaa.org/doi/abs/10.2514/1.J055304

Along with a full set of Electronic Supplementary Material, so you can reproduce the results if you like!

Thanks

Peter

Peter,

No worries about the delay, I do appreciate the response. With some trial and error I arrived at similar values for the quadrature order used in the anti-aliasing for my case as the values you presented in the paper. I must say it is quite refreshing having access to the code and inputs such that the results can be reproduced – thank you!

Perhaps I should start a new thread, but I was wondering how the correction functions interact with the anti-aliasing. Specifically, would it be possible to limit or avoid the use of anti-aliasing by using a different correction function (other than DG) on non-uniform grids encountered in complex industrial geometries? I understand this question is the topic of on-going research and you may not have a simple answer. In the future do you foresee additional options for correction functions being included in PyFR?

Thanks for taking the time to interact on this message board and thanks for PyFR.

-Andy

Hi Andy,

Regarding your second point on correction functions, we recently published a paper investigating the influence of correction function choice on non-linear stability and a number of other properties. You should be able to download it here (see Sections 4 and 5): http://www.sciencedirect.com/science/article/pii/S0021999116304557

If you check the supplementary material there is a patch for PyFR that lets you load a custom correction function operator matrix from disk.

Cheers,

Hi Andy,

Further to Brian’s message, please also see an additional paper (attached), and in particular Fig 7.

Cheers

Peter

JSC_ViCaJa_2010.pdf (1.12 MB)

Brian and Peter,

The paper that Brian linked actually partially inspired my questions regarding the use of different correction functions since you specifically stated that no anti-aliasing strategies were used.
The patch you supply reads the M3 operator matrix for a standard element type which is the divergence of the correction function at each solution point correct? Would it be possible for you to share an example file for the operator matrix for a particular set of parameters and element type? Ultimately all the situations where I would ultimately like to use PyFR involve complex geometry for external aerodynamics and aeroacoustics so I would need to be able to generate these operator matrices for all commonly encountered element types in 2- and 3D.

Admittedly I need to re-read your paper (and others related to it about ESFR and VCJH schemes by Peter and colleagues) to understand if it would be straightforward to generate these matrices easily based on user input, i.e., in the configuration file the user specifies the q_0 and q_1 values and the appropriate correction function operator matrices are generated automatically. It would be interesting to play with these parameters a bit and compare the computational efficiency with the anti-aliasing techniques already implemented especially considering since both methods of solution stabilization allow for larger stable and accurate time steps cf the base scheme with no anti-aliasing and DG correction functions. To achieve the same error level is it more efficient to use anti-aliasing or perhaps a higher order solution polynomial combined with alternate correction functions? The answer to that question is probably problem-dependent.

The most relevant case to my initial studies is the SD7003 case you have simulated. This case was run both with E-ESFR schemes (http://www.sciencedirect.com/science/article/pii/S0021999116304557 section 5) and with a nodal DG FR scheme (http://www.sciencedirect.com/science/article/pii/S0021999116307136 section 5.4) with the mean results differing slightly. Can you comment at all about the observed time step that was allowed by the adaptive RK45 scheme and overall efficiency/accuracy?

Thanks,
Andy

Hi Andy,

The simplest way to get an example of the M3 operator matrix (divergence of the correction functions) is to just add a numpy print statement into the release version of PyFR where the matrix is built. This way PyFR will print the default FRDG operator matrix for any element/order you like at runtime. If you review the literature on the ESFR range of schemes you should then be able to generate and load your own custom operator matrix for the correction function.

We did not do a detailed comparison in terms of runtime between the FRDG and extended schemes for the SD7003 case. However, for the Taylor-Green vortex case the extended schemes were significantly faster as discussed at the end of Section 4. Since there is not an exact solution for the SD7003 case, it is hard to make a judgement on accuracy vs. cost for the different schemes. However, both provided results within the expected ranges based on previous studies.

Cheers,