STL use in flow5

[zach....@fhengineering.com]

Flow5  just came onto my radar this week.  I have not had a chance to demo, but I'm curious as to how VSP geometries may work with the flow5 STL import capabilities:https://flow5.tech/docs/flow5_doc/STL_Planes.html

Has anyone tried this yet?

[Tom]

I subscribed to flow5 about a year ago. It is the next generation of XFLR5 by developer Andre Deperrois. It has been in BETA but should be released as a final version by early December/2020. I've been looking for models with wind tunnel test data in order to validate flow5 and discovered VSP.  Brandon Litherland's Cessna 210 model published on VSPHangar (file no. 263) has wind tunnel test data available (see the link on the VSPHangar page). I created two videos on YouTube to assist other flow5 users, the first on how to export the STL file for the Cessna 210 from VSP, and the second on how to import it into flow5. These videos were created for a student/hobbyist level audience. The links are below. Full disclosure, I'm an RC airplane hobbyist not an aerodynamicist, and I'm certainly not a polished video producer so watch the videos at your own risk!

But to answer your question, STL files work great with flow5, but they need to be pre-processed prior to export and when importing into flow5 there is a process you need to follow to make sure all the triangles are connected and the trailing edge needs to be identified by the user in order for the analysis to work. I review this in the videos. And last note, I'm still testing flow5 against the wind tunnel data.

No. 1 - Exporting STL file from Open VSP:   https://www.youtube.com/watch?v=ENXABhF-VkY&t=197s

No 2 - Importing STL files into flow5:           https://www.youtube.com/watch?v=DbeShDWQYM4&t=3s

[Rob McDonald]

STL files are ubiquitous, but they are also pretty limited and inefficient.

The new *.vspgeom file format very recently introduced has the trailing edge lines explicitly identified already.  It is a pretty simple point-connectivity format that would be reasonable for any tool to implement if the developer wanted.  You might make the suggestion if you think it would be a good match.  It is already supported by CFDMesh and CompGeom exports from OpenVSP.

Rob

--
You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/75a7154b-7e36-4e5a-bc56-f298c3574632n%40googlegroups.com.

[Tom]

Thanks very much Rob. *.vspgeom file format looks very promising. I've passed on the information to the developer. I've searched for articles that would define the file format but have not been able to find anything other than in your V3.22 release notes. Are there any publications that you could refer me too?

Thanks,

Tom

[Rob McDonald]

It is a file format that Dave Kinney (VSPAERO developer) and I recently created to support the evolution of VSPAERO.  We iterated back and forth a few times and this is what we have right now.  I would be open to input from other tool developers.

I documented the file format in the code here.  As with most code comments, it is already out of date.  There were numerous changes Dave and I made along the way (the comment was the first idea).  So, I have now updated the comment (will go into the next version), but accurate documentation is this:

nnode                        // Number of nodes
x1 y1 z1                     // Nodal position.  Also any future single-valued node-centered data that we desire to add.
x2 y2 z2
...
xnnode ynnode znnode         // Last node
nface                        // Number of faces (currently only tris, but support polygons)
n1 i11 i12 i13...i1n         // Number of points, index 1, 2, ... n for each face, right hand rule ordering for normals facing out.
n2 i21 i22 i23...i2n
...
nnface in1 in2... inn        // Last polygon face
t1 u11 v11 u12 v12...u1n v1n // Tag number for face 1 followed by multi-valued nodal data -- currently parametric UV coordinate.
t2 u21 v21 u22 v22...u2n v2n // Also any other face-centered data that we desire to add.
...
tnface un1 vn2...unn vnn     // Last tag, multi-valued nodal and face-centered data
nwake                        // Number of wake lines
n1 i11 i12 i13 i14...i1n     // Number of points in wake line, indices in chain-order.  Typically line wrapped at ten indices per line.
n2 i21 i22 i13 i24...i2n
...
nnwake in1 in2 in3 in4...inn // Last wake line

If you don't trust the documentation (reasonable), you might trust the code -- there are two implementations of this file, the CompGeom (with support nodes, faces, data, wake) and CFDMesh version.

The U, V data makes it easier to treat unstructured wing meshes a bit like they were structured...  Spanwise load distributions, strip-wise methods, etc. are easier than if you don't have any underlying structure.  Also, it may improve the calculation when you go to take surface derivatives of the potential to calculate the surface velocities and pressure coefficient after solving.

Most file formats support either node-centered or face-centered data.  Unfortunately, where two objects meet (think a sharp corner wing-body intersection), geometric properties at a common node can be multi-valued (think normal vector and U,V surface coordinates).  We needed to support multi-valued U,V data at the nodes -- we considered a couple approaches, but settled on this one (ergo the changes in file format).  Another good candidate would be to add multi-valued normal vectors.  These would be based on the Bezier surfaces and therefore would be more accurate than you can calculate from the triangles.

The wake identification is there so you don't have to rely on any sort of heuristic based on normal vector angles to try to identify wakes.  OpenVSP knows which components are wings - and it knows where the wakes are, so we use that information to make life easy.  If you still want to specify a wake line at an aft facing step or something else, you're on your own.  This will be a big benefit for rotors -- where the trailing edge sometimes points forward, making heuristic detection a little more tricky.

The file is set up to handle tris, quads, and n-sided polygons.  This is more aspirational than reality -- VSPAERO does some work to reconstruct quads from the tris.  It also does work to get rid of nasty sliver triangles and rebuild them into polygons.  'Some day' I would like OpenVSP to do some of that work based on information we already have.  Until that happens, these files will be all tris.

Our other secret goal is to support mixed thick and thin representations with this file format.  For example, the wings and propellers would be a thin (VLM) representation while bodies and fuselages would be thick (Panel) representation.  The thin surfaces would still be trimmed by the thick surfaces.  Version 3.22.0 added support for this idea for CompGeom (CFDMesh support will come).  The VSPAERO solver already treats thick and thin geometry mostly the same, so the conversions to make this work should be modest.  Finally, the OpenVSP GUI will need to be updated to allow the user to control and understand how to use mixed thick and thin models.  (These changes will also overcome some current limitations in VSPAERO outputs, so OpenVSP will have to parse new data and present it in the Results Manager GUI).

The good news is, the mixed thick/thin business has absolutely no impact on the file format.  So, if a tool (VSPAERO, DUST, Others?) wants to support mixed thick/thin models, they can do so.  However, everything will still work fine for a user who chooses to write everything out as a thick (or thin) surface file.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/f3c613df-37ec-44dd-ba32-d2df114a9871n%40googlegroups.com.