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.
Iâve run into this error with a mesh created in Pointwise and elements exported as q1 normally with the Gmsh CAE solver. It doesnât seem like the original issue with the non-parallelogram test failing on valid pyramid elements was addressed. Is the recommended solution here to simply increase the tolerance, so that it passes? Would it be worth re-visiting whether the tolerance value being used is appropriate? Thanks!
Best Regards,
Zach
Hi,
I donât think change tolerance is a good idea. It is better to go back to mesh. With my experience, this issue could happen if you have surface lift (projection) and your pyramids are too close to this region. If you check the corner points of pyramids after lifting, the base could be not a parallelogram. The second possible thing to solve this is to use translate to create a surface or a volume which can guarantee the base is a parallelogram.
Regards,
Zhenyang
I agree, that adopting a strategy to create meshes which avoid introducing pyramid elements is probably the most direct approach, and Pointwise does provide hyperbolic and algebraic extrusion options that assist in doing so. However, the robustness of these extrusion options can be somewhat limited when the underlying geometry is not a simple quasi-3D shape. For more complex models, in which an unstructured mesh is desired, youâre sort of left with the anisotropic tetrahedral extrusion algorithm (T-Rex) with element re-combination from a robustness standpoint in which introducing pyramids is somewhat unavoidable.
It seems like the issue reported here with pyramids was actually an artifact of using anti-aliasing with your given filtering approach, rather than the quadrature of pyramid elements themselves. Freddie and Will seemed to think there may have been an issue with the Jacobian expressions for linear elements that may be incorrectly flagging valid pyramid elements when this parallelogram test is being run. I was just curious whether this was looked into any further as being able to handle meshes that include some/more pyramids will likely have a longer term benefit to using PyFR.
Our eventual conclusion was that affine pyramids are working as expected. The only caveat is that when using anti-aliasing one needs to ensure that a suitable quadrature rule is used.
We have looked into adding support for fixing the bases of pyramids into the importer. I have a rough sketch of the algorithm but several aspects of it are non-trivial.
One first needs to identify the nodes associated with the bases of all non affine pyramids. Then, we loop over the bases. If a base does not share any nodes with the base of another pyramid then the fix is relatively straightforward; nude the nodes to make the base affine. (This likely requires forming a linear-least squares problem to find a solution which minimises the total amount of node movement.) If a base is shared then more care is required as fixing one base could render its neighbour non-affine. Thus one needs to form a linear system for each collection of adjoined pyramid bases and solve this to obtain the updated node set.
How applicable this algorithm is really depends on several factors. The most important one being if the pyramid bases are on a surface. If so, moving the nodes is likely to be problematic as it will impact the representation of the geometry. However, if they are a few layers out then it will likely work fine.
Regards, Freddie.
That sounds like it should work. If users are creating meshes using recommended practices in Pointwise, their meshes shouldnât include pyramids that share nodes with other pyramids. Nor should the pyramids appear in any of the boundary layer resolved grid layers. Typically these pyramids either appear in the farfield as part of the voxel transition elements, or transition region between the boundary layer resolved hexahedra/prisms and the isotropic tetrahedra if cell combination fails.
Of course, users are free to insert pyramids ignoring best practices, in which case the additional correctional measures outlined here would be good to have. One error where I can see users might commonly add pyramids inappropriately is if they for some reason are using the mixed quads/tris 2-D surface meshing algorithm on outer control volume boundaries or symmetry planes. In those instances you could end up with pyramids that share nodes with the base of another pyramid if one were to mirror the grid about one of those planes. But users should be using the Advancing Front or Delaunay triangulation algorithms with tris only on those boundariesâŚ
1 Like