Yes, so for me the case runs without issue from t = 0 to the point until I stopped it. Indeed, with anti-aliasing enabling this case has never given me any trouble on any platform.
I am using the latest Git develop version of PyFR although I do not believe there are any differences between the latest release that would impact the case.
Regards, Freddie.
Just following up for completeness. After several trials, I understood that I was making some mistakes when setting the anti-aliasing.
Indeed, as far as I understood, all the following parameters should be specified, in order to correctly set the anti-aliasing:
[solver]
...
anti-alias = flux
[solver-interfaces-line]
flux-pts = gauss-legendre
quad-deg = 11
quad-pts = gauss-legendre
[solver-interfaces-quad]
flux-pts = gauss-legendre
quad-deg = 11
quad-pts = gauss-legendre
[solver-elements-hex]
soln-pts = gauss-legendre
quad-deg = 11
quad-pts = gauss-legendre
In the failing test that I previously experimented with, I was only setting the parameters for [solver-interfaces-line], while I guess that the correct way of doing that is the above one (I guess that in general one should have care of checking what kind of elements his mesh is done of and specify the parameters for all of them).
With the above parameters, the test can be repeated without any issue, as Freddie was mentioning.
Regards,
Federico Cipolletta.
Yes, for flux anti-aliasing the sections you need correspond to those of the element types you have in the simulation. So, if you have an all hex mesh then you need a quad-pts and quad-deg section in [solver-elements-hex]. For surf-flux anti-aliasing, it is necessary to specify the quadrature points on the various element interfaces. If you just have hex elements then you only have quad faces and so only [solver-interfaces-quad] needs to have quad-deg and quad-pts.
Hope that helps.
Regards, Freddie.