I have been trying to fit high-order curved faces to geometries. I use PointwiseV18.3R2 for this, because I can use it, and don’t want to bother with learning Gmsh at the moment. The problem is, I don’t know if Pointwise is doing it correctly (I think I am exporting correctly: solver parameters->Q4->export CAE etc. everything looks fine). I want to visually see if the curves match the geometry. The VTU output by Pointwise don’t look like matching the geometry properly, nor does the export by PyFR. In fact, the face edges seem to be straight lines, even when I increase “nonlinear subdivision level” in Paraview.
How do you visualize the high order mesh in your publications etc.? Is Paraview good enough?
I think you might need a newer version of pointwise. I have run into a number of issues with high-order mesh generation on V18 R2, but V18 R3 seems fine.
Much thanks @WillT for the advice. I will try to get a trial license of the new version and try to export the mesh properly.
@GonzaloS I used PyFR1.12.0. I use the default export command to get the high-order mesh (corresponding to -k 4). This is probably an issue related to Pointwise. Pointwise also has a high-order VTU output, which also looks incorrect, that is, straight edges of the cell faces. Thanks!
I want to give heads up for the prospective Pointwise high-order mesh users here:
As Will suggested, old version of Pointwise has problems with exporting the high-order mesh. In fact, PointwiseV18.3R2 was not able to export the mesh (the face edges being straight lines), whereas PointwiseV18.4R4 could did it properly.
Alas, the export process itself took forever. For my small p4 mesh, half a day was easily wasted (with 3 smoothing passes). Almost to the point the efficiency advantage of p=4 is cancelled out I don’t really know how long the export takes with Gmsh, though.
Pointwise fails with exporting, throwing mysterious error messages, if the locale (regional settings on linux) is german etc. That is, it fails when decimal separator is “,” and the thousand separator is “.”. On the other hand, the US regional settings work without problems. I experienced this odd behaviour with other features of Pointwise in the past. I don’t know how it is on Windows…
I’m glad that upgrading pointwise worked, I don’t really ever use Q4 meshes so their may have been a problem that was only fixed in R4.
That brings me to your second point. Do you really need a Q4 mesh? You might want to try using a Q2 mesh, not only will it speed up the export from pointwise, but it will help with aliasing type effects can can arise with higher mesh orders.
Thanks for the point, Will. Actually, I decided to use Q4 only because my simulation is p=4. Although my geometry is fairly complicated, Q2 or Q3 could have represented the shape appropriately. Based on your suggestion, I presume it is sufficient to have all the flux points on the geometry to be able to represent the geometry accurately. Having higher solver p does not cause geometry representation issues, is that correct?
Depending on the settings you are using in Pointwise, the mesh will only be curved near smooth boundaries. As it is doing a polynomial fit, the convergence of the polynomial modes will likely be spectral. I.e. if the polynomial approximating the geometry in an element has the form:
\Xi = \sum^N_{i=0}c_i\phi_i(\zeta_i, \eta_i)
where c are the modes, \phi is some polynomial basis, and (\zeta,\eta) are the coordinates in the reference domain. Then we know that as the degree of the individual bases increases then the scale of c will decrease quite rapidly (if the shape of the geometry is in some H^p space). This is really just a restatement of Taylor’s theorem.
What I am trying to get across is that yes the geometry might be better approximated by a higher-order polynomial, but how much difference is that really going to make? This is also probably why Pointwise is struggling to generate the mesh, the high order coefficients in the geometry approximation are probably small and difficult to converge.
On the flux points, Pointwise will be placing its own set of points on the boundary. PyFR reads the location of those, builds a fit of the surface and then places its own points. Therefore, I don’t think there is a guarantee that the flux points will be on the physical surface, but rather that they will be on the projected surface provided by Pointwise. Abe etal. (2018) is a good starting point.
The point I’m trying to make is to be pragmatic, using a lower order geometry representation is prefered as it makes things easier on the meshing front, and reduces aliasing based problems. But if you find that your solution is faceted then maybe you need to up the geometry order. Others will have views on this as well, so feel free to disagree.
Thanks Will for the kind explanation. Now i started to understand the things better.
On the Pointwise side, it was a failure for me. Based on your suggestion, i started using Q2 export, which looked pretty good on the geometry. The simulation, however, revealed another problem. It seems, when i elevate the mesh to orders higher than Q1, the periodic faces start to fail. In fact, some messing-up of the periodic cells occur on some cells. You can easily see this in the attached screenshot. Note that the screenshot belongs to an initial p1 solution on the Q2 mesh for some time steps.
Pointwise seems not to be able to recognize the periodic couples and start to place flux nodes independently (for a few cells, at least). Everything works fine on Q1 mesh output, though. I tried many things to overcome this issue, without success. I guess I must start learning Gmsh…
Are you using periodics defined in Pointwise using their periodics feature or did you just extrude a 2D mesh and set it as periodic in CAE set boundary conditions? Because I think you need to do the former for it to work.
I don’t really know how long the export takes with Gmsh, though.
that’s embarassing. missed that point… I only copy-paste-translated the domain.