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