[A.Roy]

Hello,

I am using the feature_adap branch to make some preliminary grid adaptation runs on in-tunnel high-lift flows.
I am wondering if there is any config option to be able to freeze the viscous layers in some form so that adaptation is only carried out beyond that (perhaps so that only tris are adapted, and detected quads are left as-is or something?)

I see from Brian's commits to the feat_adap_dev branch that there is a script to split quads and / or output them to a file...but I can't seem to find if there's an option that allows to let those quads remain untouched (or unaware if that is a feature added to the dev branch) if anyone might know?

If the above isn't possible, is there any open-source (or perhaps academic available) software that allows for reading SU2 output mesh and re-inserting viscous layers?


Thank you!

[A.Roy]

Hello,

I was unable to find the option for frozen boundary layers (as shown in the 2018 presentation: pdf link), however, I used a slightly modified version of the split_quads script from the feat_adap_dev branch with the 7.0.3-feature_adap branch as mentioned to append an NCORNERS section to freeze those nodes (NCORNERS as shown in the 2020 presentation: pdf link).

Some notes from my implementation:
- The split_quads script has been rewritten to accept tris as input also (as opposed to a quad-only mesh), to output the tris and split the quads into new tris, and to output the vertices of the former quad elements into the NCORNERS section.

NOTE 1: This assumes that the inviscid "volume" (well, surface in 2D) mesh is composed of tris only as all quads are assumed to be part of the viscous layers.

NOTE 2: This is a strictly 2D script so far, as splitting hex and pyramid elements into tets requires quite a bit more effort since the corresponding quad surface elements must also be split. As a result, in the near future I am using ICEM to convert 3D hex and pyramid elements to tris and using the bottom portion of the script to output the vertices to NCORNERS. There appears to me to also be the some diminishing returns in 3D at least in terms of number of elements as each hex is split into 6 tet elements compared to each quad being split to 2 tris, significantly ballooning the initial element count.

NOTE 3: The script is written for su2 meshes with a tab character '\t' after the element identification (5 for tris, 9 for quads) as output by conversion from SU2_DEF; if this is applied on gmsh output su2 meshes, those use a space character ' ' instead. This would need some simple logic change / modification to flexible to both kinds of meshes; for consistency, I have been running all meshes through SU2_DEF before applying split_quads_2D.

- This implementation by using frozen corner nodes is not perfect as the amg algorithm still carries out some splits and merges in high gradient sections of the viscous layer (while generally respecting the frozen nodes) - resulting in some deterioration of the first off-wall node spacing.

The modified script I used and some images of the Mach-based adaption are attached.