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 On Monday, June 26, 2017 at 8:49:09 AM UTC-4, Vincent, Peter E wrote: > > 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 > > Dr Peter Vincent MSci ARCS DIC PhD > Reader in Aeronautics and EPSRC Fellow > Department of Aeronautics > Imperial College London > South Kensington > London > SW7 2AZ > UK > > web: www.imperial.ac.uk/aeronautics/research/vincentlab > twitter: @Vincent_Lab > > > > > On 7 Jun 2017, at 04:14, Andy Smith <[email protected] <javascript:>> > wrote: > > 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 > > On Tuesday, August 30, 2016 at 8:28:32 AM UTC-4, Antonio Garcia-Uceda > wrote: >> >> 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 >> >> On Tuesday, August 30, 2016 at 11:49:09 AM UTC+2, Vincent, Peter E wrote: >>> >>> 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 (<<flux>>), interfaces (<<surf-flux>>), or div_flux (<<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 >>> >>> Dr Peter Vincent MSci ARCS DIC PhD >>> Senior Lecturer and EPSRC Early Career Fellow >>> Department of Aeronautics >>> Imperial College London >>> South Kensington >>> London >>> SW7 2AZ >>> UK >>> >>> web: www.imperial.ac.uk/aeronautics/research/vincentlab >>> twitter: @Vincent_Lab <https://twitter.com/Vincent_Lab> >>> >>> >>> >>> >>> >>> On 30 Aug 2016, at 11:30, Antonio Garcia-Uceda <[email protected]> >>> wrote: >>> >>> 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 (<<flux>>), interfaces (<<surf-flux>>), or div_flux (<<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 >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "PyFR Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/pyfrmailinglist. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> > -- You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at https://groups.google.com/group/pyfrmailinglist. For more options, visit https://groups.google.com/d/optout.
