.tri CARt3D file bug

164 views
Skip to first unread message

Patrick Hammer

unread,
Dec 10, 2021, 10:58:36 AM12/10/21
to OpenVSP
Good morning,

I'm running into a bizarre issue when I try to run the OpenVSP Panel Method using VSPAERO. A colleague made a geometry in the OpenVSP GUI to try and assist me and the panel method ran fine and exported a sectional load (.lod) file that looked fine. However, when I exported it as a Cart3d .tri file, loaded that into OpenVSP and ran the panel method, it ended up thinking it was only simulating half the wing (there were zeros for the Xavg, Yavg, Zavg, etc. I half of the file) and it also mixed up things like the Xavg, Yavg, S, chord, etc. For instance the span is about 200 ft, so Yavg should go from -100 to +100. However, instead it says chord goes from 200 to 0 (up to half of the wing). 

I'm very new to OpenVSP and wanted to try a simple geometry (rectangular, High AR wing with NACA 0012 cross-section) using an automated process I also use for CART3D.

Any help would be appreciated on what is going on.

Regards,

Patrick

Rob McDonald

unread,
Dec 10, 2021, 1:14:14 PM12/10/21
to ope...@googlegroups.com
Patrick,

Sorry you're having this trouble.

Can you explain why you're generating a model in OpenVSP, exporting it as Cart3D, importing it as Cart3D and then trying to run VSPAERO?  Or perhaps I misunderstand what is going on.

OpenVSP has an option to generate a half mesh when running CompGeom -- and VSPAERO has an option to assume symmetry and work with a half model..  I don't know if either of those things are relevant.

Did your geometry ever exist as an STL file?  Strictly speaking, STL files are not supposed to have any negative coordinates.  So, some programs will automatically shift your model into the +X,+Y,+Z octant before exporting as STL.  Many other programs think that is silly, so we collectively choose to ignore that part of the STL standard.

It wouldn't surprise me that a model that started life in CAD, was exported as STL (shifted into the positive octant), got converted to Cart3D TRI using stl2tri or similar tools, and then imported into OpenVSP -- would end up with the situation you describe...

If you import a STL or TRI file into OpenVSP, you can still rotate/translate/scale the triangle mesh.  So, if this is happening to you, you should be able to translate it back to your desired origin.

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/95b0b651-3b30-4104-b3ee-833b3932f1cbn%40googlegroups.com.

Patrick Hammer

unread,
Dec 10, 2021, 1:19:45 PM12/10/21
to ope...@googlegroups.com
Rob,

That might answer my question. I did generate it first as an STL file, then exported it to a .tri file which then I would use in both VSP and CART3D (which also goes through additional conversion steps).

Patrick

Patrick Hammer

unread,
Dec 10, 2021, 1:21:46 PM12/10/21
to ope...@googlegroups.com
I should preface that that the origin file I was trying to load was an STL-made .tri CART3D file. My co-worker was fiddling with it in the OpenVSP Gui and saved it in a .vsp3 file. Loading that in got his to run. It just seemed weird that once it was specifically exported by OpenVSP as a Cart3D file, then re-loaded in OpenVSP, it created issues.

Rob McDonald

unread,
Dec 10, 2021, 1:26:54 PM12/10/21
to ope...@googlegroups.com
That does seem strange.  I'll try to duplicate it and see if I can find where the problem is happening.

OpenVSP should not shift your model without you knowing it.

Rob

Patrick Hammer

unread,
Dec 10, 2021, 1:35:15 PM12/10/21
to ope...@googlegroups.com
If need be Rob, I can send you the .vsp3 file then tell you what I did. 

Patrick

Rob McDonald

unread,
Dec 10, 2021, 1:40:30 PM12/10/21
to ope...@googlegroups.com
That would be great.

The example file and steps to recreate the issue is certainly the best way to help me find any problems.

Rob


Patrick Hammer

unread,
Dec 10, 2021, 4:57:19 PM12/10/21
to ope...@googlegroups.com
Rob,

Did you receive the files?

Patrick

Rob McDonald

unread,
Dec 10, 2021, 6:02:26 PM12/10/21
to ope...@googlegroups.com
I did.  Thanks.  I'll try to take a look at them soon.

Rob


Patrick Hammer

unread,
Dec 10, 2021, 6:45:39 PM12/10/21
to ope...@googlegroups.com
Okie doke.

Thanks,

Patrick
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/CAEppYpE8k9egf852yzS5r7BZ0dVmBpN%2BTJTWp4Z5i2Foi_p%3D2g%40mail.gmail.com.

Rob McDonald

unread,
Dec 11, 2021, 4:42:10 PM12/11/21
to ope...@googlegroups.com
I have not been able to observe the behavior where the model was shifted to give a span from [0,200].

However, I have been able to observe the behavior where the spanwise load distribution's y coordinate is always zero and the plot axes are from -1e-12 to 1e-12 -- and it looks like a spike.

Fortunately, this is only a problem with the spanwise load distribution post-processing.  The solution worked fine, you can visualize your Cp plot in Viewer, the CL, CD should be fine, etc.

VSPAERO can run a thick surface panel solution on an imported STL or TRI mesh.  However, since this is a 'dumb' mesh, OpenVSP does not know anything about how it was built.  You've already observed that it does not know Sref, bref, cref.  But it also does not know how the model was built.

The code that does spanwise integration in VSPAERO relies on some of that information to give the load distribution context.  Without that context, the spanwise load distribution has no axis and all points are reported at 0.0. This gives the spike you see.

Rob



Okie doke.

Thanks,

To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.

--
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.

--
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.

--
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.

--
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.

--
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.

--
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.

--
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.

--
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/CAD%2BHx8DHD7dGENfJ7fc-XB__KGsp0ZZO%3DMOxPjqgknHQ7U9Maw%40mail.gmail.com.

Patrick Hammer

unread,
Dec 13, 2021, 9:32:16 AM12/13/21
to ope...@googlegroups.com
Rob,

Is there some sort of additional input file that it might need or would I be going on a wild goose chase to use and utilize the tri or stl file? For instance, is there a way to convert the stl or .tri file to a vsp3 file via Matlab that it could read?

I haven't seen documentation of the structure of the .vsp3 file or how to build it in a batch-sort of way.

Again, thanks for the assistance.

Patrick



Patrick Hammer

unread,
Dec 13, 2021, 10:27:38 AM12/13/21
to ope...@googlegroups.com
Rob,

I did get a result when I imported the STL. It still had confusion in coordinates, but it wasn't listing them as zeros.

Where do I go to translate the mesh?

Patrick

Patrick Hammer

unread,
Dec 13, 2021, 11:06:34 AM12/13/21
to ope...@googlegroups.com
I was able to find the translation button.

That seemed to do the trick. After translating it by the semi-span, I'm getting correct looking distributions.

Thanks alot for the help,

Patrick

Patrick Hammer

unread,
Dec 13, 2021, 11:15:07 AM12/13/21
to ope...@googlegroups.com
Rob,

Actually, I had one more question. Is there a way to do the mesh_geo translation via command prompt? I didn't see anything in the documentation about it.

Patrick

Rob McDonald

unread,
Dec 13, 2021, 12:22:14 PM12/13/21
to OpenVSP
You can write a short vspscript to perform the translation -- and then execute the script from the command line.

Your test geometry was very simple -- it would be very easy to recreate in OpenVSP as the 'original' source of the geometry.  This would make the built-in analysis tools easier to access -- while still giving full access to Cart3D through TRI files.

Further, the imported TRI mesh included in your example was not a great representation of the geometry -- OpenVSP will give you more control and consistency in the mesh it outputs.  This will lead to better leading edge resolution for Cart3D.

Perhaps your 'real' geometry is significantly more sophisticated, but is there a reason you can't move to OpenVSP for your 'original' geometry model?

Rob

Rob McDonald

unread,
Dec 13, 2021, 12:24:19 PM12/13/21
to OpenVSP
Rather than build a VSP file in a batch way, a better approach is to use the API (through Python, Matlab, or the built-in scripting vspscript) to build a model using commands similar to what you would do in the GUI.

However, easier than that is usually to build a baseline model in OpenVSP in the GUI -- and then just use scripting or the API to vary the parameters of your particular design study.

If you could describe what you're trying to accomplish a bit more, I may be able to give better guidance.

Rob

Patrick Hammer

unread,
Dec 13, 2021, 12:57:03 PM12/13/21
to ope...@googlegroups.com
Rob,

Basically I'm trying to compare the vortex code AVL against CART3D for a planform I'm looking at and got really strange differences for a particular airfoil even though things agreed for a NACA-series airfoil. So I wanted to try out VSPAero as a cross-validation. Now, one of the codes we use outside of Matlab (which is what I'm running CART3D and VSP Aero) from is ESP/CSM, which is python based. Although it's a separate step, it has the ability of exporting a geometry as a STL file, which CART3D can then use and I didn't have a better way at the time of creating an STL file at the time. So the idea I had was that I could use the Matlab to create the geometry to use for AVL, then from that create the ESP call to generate the STL file I could use for CART3D and VSPAero, so it's all done in a single wrapper. But it's probably extra steps. I also haven't had much time to try and look at how openVSP creates geometries as well but didn't think I'd be running into these types of issues. It definitely looks like OpenVSP has good modeling capability, but wanted to do it all via command-line so it could be run using Matlab.

Patrick


Rob McDonald

unread,
Dec 13, 2021, 1:50:19 PM12/13/21
to ope...@googlegroups.com
All of these things are possible.  It depends on how much time you want to invest in different paths -- difficult for me to say.

Here is a screen grab of the triangulation from your imported geometry in your example file....

Triangulation2.png

If this is representative of what you're getting with your 'real' configuration, it isn't great...

Cart3D has a unique relationship with the triangulation.  It is not used directly for a computational mesh.  Instead, it is used as a cutting surface to slice through a Cartesian mesh.  Consequently, poor resolution or low quality triangles can be tolerated in some ways that they would not be tolerated by other codes.

For example, along the flat wingtips here -- since the true geometry is flat, the surface is essentially exact for Cart3D's purposes.  Cart3D will adapt a mesh across that face and may end up with twenty cells there -- but the single-triangle high mesh is OK for defining the geometry.

On the other hand, the VSPAERO solution is going to use that mesh more directly -- your mesh resolution will be fundamentally linked to the triangles you read in.

The leading edge representation in your mesh is going to end up with noticeable spanwise 'roughness' because the triangles are not aligned with the span.

OpenVSP will create the triangulation in a way that is more aligned with the curvature of the leading edge.  Although a coarse representation is shown here, it is easy to control the mesh resolution and clustering in OpenVSP.

Triangulation4.png

In addition, there is clustering across the wingtip and near the trailing edge -- things likely not important for Cart3D, but that may be important for any code that uses the mesh more directly like VSPAERO.

The spanwise roughness can easily be seen when comparing shaded views of the two meshes.

Triangulation3.png
Triangulation5.png
These spanwise variations will show up in both Cart3D and VSPAERO solutions.  It may not be a big deal for the solution (forces and moments), but it will be a visual artifact that you can see in any plots of surface pressures etc.


OpenVSP is written in C++.  We also have embedded a C++-Like scripting language called AngelScript.  We usually call the scripts *.vspscript files.

OpenVSP has an API that allows almost anything to be accomplished programmatically.  The API is natively C++, but we use SWIG (a wrapper generator) to generate a Python wrapper for it.  The Python wrapper is distributed with OpenVSP for everyone.

With significant effort (not for the faint of heart), it is possible to use an experimental version of SWIG to wrap the C++ API.  This will allow you to call VSP directly from Matlab.  It is really cool, but it is not the easiest approach.

If VSP was going to be the center of your workflow, then it may be worth the time investment.  If you are only using it as a means of validating other tools, then it probably isn't worth the trouble.  Your call.

For most simple automation tasks, the easiest path is to write a short vspscript -- which can then be executed from the command line (from Matlab or manually, etc).

The API is documented online here.

A script to read in a STL file, translate it in the Y direction, and output a TRI file would be something like this....

void main()
{
    string mid = ImportFile( "importfile.stl", IMPORT_STL, "" );
    SetParmVal( mid, "Y_Rel_Location", "XForm", 123.4 );
    Update();
    ExportFile( "exportfile.tri", SET_ALL, EXPORT_CART3D );
}


The 'scripts' directory in the VSP *.zip file comes with quite a few example scripts  you can check out.

There is also a Python script bundled with OpenVSP that will generate an AVL input file for a given OpenVSP model.  You have already invested in a different path to generate AVL files, so this may not be relevant, but it might be helpful.

VSPAERO can be run in both thick-surface and thin-surface modes -- usually referred to as panel method and VLM modes.  We can not create a VLM model from an imported Mesh, so if you import the file, you will only be able to run in the thick-surface mode.

VSPAERO's thick surface mode does not like finite-thickness trailing edges (your geometry looks fine).  And it does not do a great job with cusped trailing edges (depends on your final airfoil).

VSPAERO is also under rapid development.  Hopefully that means that bugs are getting fixed, but this also means new features and capabilities are constantly being added.  I recommend you track which version of VSPAERO you use for any particular solution.  I would always check out new versions -- maybe they fix old problems, but maybe they introduce new ones.

Rob















Patrick Hammer

unread,
Dec 13, 2021, 2:08:26 PM12/13/21
to ope...@googlegroups.com
Rob,

Thank you for the suggestions. I'll talk with some of my co-workers who have experience with this to see if this is a good route. I'll let you know if I have any follow-up questions.

Patrick

Reply all
Reply to author
Forward
0 new messages