I have tried to import high order mesh into pyfr which produces similar error if that is what you mean. I can send you my mesh since I think the file format is not allowed to upload here. Can you give me your email address?
Even if you export the mesh in high-order format, the elements might be recognized as linear by PyFRâs mesh converter, depending on the energy contained in the high-order modes representation of the cell metric. To ensure that the elements are always tagged as non-linear, you need to pass -lintol 0 to the mesh converter args (and that may even not work in certain cases).
If that still does not solve the issues, could please upload the mesh to Dropbox/GDrive or something similar and send me the link in a PM over this forum? Thanks!
If you want all elements to be tagged as non-linear try: -lintol=-1. The use of a negative number ensures that the linear test will always fail â even if the element is linear.
Regards, Freddie.
Hi all,
I have tried -l -1 in the mesh converting session and tried Euler solver at p = 4 for several time steps, the result is still similar to what I got before. I have send a simple test mesh and setup file in the onedrive here,
https://kth-my.sharepoint.com/:f:/g/personal/zhenyang_ug_kth_se/EumogXVrc3NEg1bNkUXv33wBI3RRtcgB_u__NkWpGAUYJg?e=2bBBPZ
At present, I am running my case with p = 3, everything is okay. Problems occurred when I tried higher P degree in the solver. I assume if it could be some anti-aliasing problem. After read the user guide and increased (from 7 to 9) the degree of quadrature rule for anti-aliasing in pry, hex elements and interface. The solution is correct. That could solve the problem at least for p order = 4.
Just to confirm, does the free-stream preservation issue still occur when -l -1?
Regards Freddie.
If I keep anti-aliasing of quadrature degree to every element and surfaces with degree of 7, the preservation issue still occurs with P = 4. shows as the picture:
Hi @Zhenyang
I finally got round to running that coarse mesh you sent me, sorry about the delay. How quickly did you see the blowup?
Just to get a feel for the problem I have been running it on a single partition and without running the partitioner, so no elements are flagged as linear yet. I have run it for a few thousand time steps and I canât see any issues. However, I did turn off flux anti-aliasing. I have also tried running the case with and without the filter you specified, again I havenât seen any issue so far.
Also is there any chance you could rerun the original case with adaptive time stepping and without anti-aliasing?
Hi Will,
Thanks for following up. Actually I have always running it with anti-aliasing turned on. The problem will show up very soon in this case. I just tried the setup without anti-aliasing. As you said, the result is normal as far as I run it. However in the end, I am going to run a case with low-resolution DNS mesh setup, both anti-aliasing and filter setups should be needed, right? Or simply the filter is enough for the case. My current solution is just simply increase the quadrature order for prevent the problem (as long as set quadrature order is twice of the p order I am using it is alright) along with the filter.
Best wishes,
Zhenyang
Ok, it seems a little contradictory to me to run with filtering and flux anti-aliasing. I would just use anti-aliasing as that will probably be more accurate and doesnât require empirical tuning. Also from your ini file, the anti-aliasing quad-deg is set to 7 for an order 4 simulation. I donât think this is high enough for the various solution point layouts, although youâd need to check the quadrature directory in PyFR. See this post Error associated with time step - #6 by p.vincent
Did you try running with anti-aliasing and globally adaptive time stepping?
Ok, that answer makes a lot of sense.
I havenât try it but to make sure what you mean here is just running the case with rk34 or rk45 with time stepping relaxation factors right? I can do that once I have more GPU allocation on cluster. I will report back then. And another general question to ask here: can rk45 with adaptive time stepping have better performance comparing with rk4 generally?
Best wishes,
Zhenyang
Yeah, I mean RK34 or RK45 with controller = pi.
Performance is a bit of a vague term. If you mean: will RK45 with adaptive time stepping have a lower runtime than RK4? Yes, in most cases, but there can be issues if you have a poor quality mesh. But that probably means that RK4 wouldâve blown up eventually anyway.
Ok thank you. I will report back once I have the outcome.