Supersonic Chines

[timoth...@gmail.com]

Hi Rob and team,

Do you have any thoughts/best practises for modelling the highly swept in-board chine sections of a supersonic aircraft? The large chord of the root aerofoil and high sweep of the first section required to produce the chines means that the wings pierce the front of the fuselage.

One solution I can think of is to use x_loc and y_loc to manually place the root chords a little further outboard but as I'm doing this as part of an optimisation routine, I wondered if there is a better way to trim the wing automatically?

Incidentally (and more generally), does anyone have any thoughts on how this contributes to the reference wing area in design? Should one include that massive section of wing embedded to create the chines?

Also, a quick thanks for the latest update! I'm loving the extra settings available for the wedge aerofoils! Just to let you know that the descriptions don't seem to be supplied for the new parms yet (when you click the name)!

Thank for all the support.

Kind regards,

Tim

[Rob McDonald]

Tim,

Glad the added wedge airfoil parameters are working for you -- I probably forgot to add descriptions to them.  I'll look into that.

The reference area doesn't really matter.  You could use 1.0 and so long as you are consistent, everything will work out fine.  The only thing you lose is intuition about the magnitude of a coefficient value -- say CLmax.  I would probably ignore the chine and just use the underlying equivalent trapezoidal wing for reference.  Some OpenVSP users carry a second reference wing in their models (in different sets) to calculate ref quantities when they have a complex planform.

By 'pierce' the fuselage, do you mean along the sides - or protruding out the nose.  It is normal practice to bring the wings to the y=0 centerline and have them pierce / overlap with the fuselage.  CompGeom or CFDMesh will trim the overlapping portions and you'll be OK.

A long time ago, I worked a parametric design of a Sonic Cruiser concept.  Controlling the inboard strake via sweep, chord, span did not work out well because corners of that design space would produce designs where the strake extended beyond the nose of the airplane, etc.

This was many, many years ago, so OpenVSP (actually I think it was RAM back then, maybe it was VSP) did not have built-in support to address this sort of thing.  So, I used some scripts in ModelCenter (I think) to pre-compute a change of variables.  Instead of parameterizing the strake with LE sweep, span, and root chord, I came up with parameters like what percentage of the nose length was to be strake (from the nose of the airplane to the LE of the reference wing).  I then did the trig to feed the native parameters.

Today, the best way to do this is to use advanced parameter linking and possibly also User Parameters.  There is a presentation and video on these from the latest Workshop.

Dig into that a bit and then let me know what questions you have.

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/7e3000b7-c5b6-4898-8d4d-78e35f2235e3n%40googlegroups.com.

[timoth...@gmail.com]

Hi Rob,

Thanks for your reply. Since I have a fairly flexible parameterisation, I think I'll have to make some kind of metric to decide when the inboard wing-section happens to count as a chine! But thanks for your thoughts on the reference planform!

Regarding the fuselage, yes as you described, it would pierce the nose. Is there a way to export the trimmed geometry instead of having to trim the stl components manually? It would simplify the meshing process if this were possible!

Thanks for the tip on parameter linking too! I took a look through the video and I think I have a good idea of where to start now.

About the extra wedge parameters - do you have any quick tips/tricks for avoiding combinations of parms that result in a self-intersecting aerofoil?

Thanks a lot!

Kind regards,

Tim 

[Rob McDonald]

I'm not entirely sure I understand all your questions.

Have you familiarized yourself with CompGeom?  I believe it will do the mesh trimming you want.

If you want an isotropic mesh instead, you might check out CFDMesh.

Finally, if you want to export STEP or IGES files to CAD, check out Trimmed Surfaces.

Could you show an example of a self-intersecting shape from the wedge airfoil?  You probably want UFwdUp/Low to be equal.  You probably also want dU Flat Up/Low to be equal.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/de9ac67c-a024-4595-b6ad-bde182324b7cn%40googlegroups.com.

[timoth...@gmail.com]

Hi Rob,

Sorry for the slow reply. Your message had answered my previous question, thank you!

When I was last using OpenVSP, trimmed surfaces weren't a thing yet, so it's great that you can export trimmed IGES models now - super handy for passing watertight geometries to a meshing program!

How does one trigger the Analysis > Trimmed Surfaces... menu from the API? I tried looking through the API docs and tried ListAnalysis() to find the right string but it returns nothing at the moment.

In Python:

import openvsp

openvsp.ListAnalysis()

>> ()

Do I have to pull a specific branch?

Thanks,

Tim

[Rob McDonald]

Those API calls went into 3.21.0.  There is a 'SurfaceIntersection.vspscript' example that scratches the surface.

If that isn't enough to get you making progress, Justin should be able to answer more questions or provide more detail.

Great to hear that the trimmed surface output is useful to you -- Justin has worked really hard on it.  I'm sure he would appreciate a more detailed report from a user if you have time.  What software are you using it with, successes / failures, which format, which options, etc.

ListAnalysis() returns a string of analyses, it doesn't dump them to screen.  You then have to for-loop over them to print them out.  Something like this (from the API Docs...)

array< string > @analysis_array = ListAnalysis();
Print( "List of Available Analyses: " );
for ( int i = 0; i < int( analysis_array.size() ); i++ )
{
    Print( ( "/t" + analysis_array[i] + "/n" ) );
}

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/bf5197c8-79ab-4f30-b8b3-aa7eebeff95dn%40googlegroups.com.

[timoth...@gmail.com]

Hi Rob, thanks for the message.

I just had a quick scan through 'SurfaceIntersection.vspscript' and it looks like I'll have what I need to make a start. I'll be using it to trim a few hundred optimisation cases, so I can give some feedback after that is up and running! Thanks for the hard work!

Quick question - has the SurfaceIntersection (or another Analysis Manager tools) been appropriately exposed in the Python API? For ListAnalysis(), I think there might be a little bug there since it returns a zero-length list!

I also tried:

>> import openvsp

>> openvsp.SetAnalysisInputDefaults( 'SurfaceIntersection' )

Error Code: 14, Desc: SetAnalysisInputDefaults::Invalid Analysis ID SurfaceIntersection

 I tried 'CfdMeshAnalysis' just as a test but I get the same error. I'm guessing that if the analysis functions are indeed exposed, then I might have a broken installation.

Thanks,

Tim

[timoth...@gmail.com]

Just to double-check, I went back to OpenVSP-3.20.1 and tried ListAnalysis and GetNumAnalysis but they return an empty list and 0 respectively too.

Kind regards,

Tim

[Rob McDonald]

I haven't dug deep into this in a very long time.  Hopefully Justin can chime in and help out.

In general, the Python API is a 1:1 translation of the AngelScript API documented online.  The Analysis Manager stuff is documented here.

Justin recently changed where the Analysis Manager was set up on startup.  Perhaps this isn't getting called from the Python API -- resulting in no analyses ever being registered...

Just a theory...

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/fe9d7120-0b0f-4002-9544-155c7088b680n%40googlegroups.com.

[jvgr...@gmail.com]

This is a minor bug that I'll look into, but for now just make sure you call "VSPRenew()" right at the start of your script. That should register all of the analyses with the API. 

-Justin

[timoth...@gmail.com]

Thanks for the tip, Justin!

[timoth...@gmail.com]

Hi Justin, Rob,

I had a chance to put the trimmed surfaces API to test today, so I thought I'd type up some feedback. I did some random wing planform sampling for a design space study, so the wing shapes are not 'normal' but I figured they might be a useful test of the trimming algorithm as the fuselage is the same for all planforms. Trimming seems to work 60% - 70% of the time when the curve adaptation tolerance is left at the default setting.

I only exported .igs files and I tried relative tolerances of the default 0.005, 0.0005, 0.0001, and 1e-5. Am I correct in thinking this is the tolerance between surfaces? This makes sense as for tolerances between 0.005 - 0.0005, the trimmed surfaces did not appear watertight in Pointwise unless I set the PW edge tolerances larger than the VSP curve adaptation tolerance.

The trimming algorithm seemed to break for a curve adaptation tolerance of 1e-4, and 1e-5. The .igs that was output was no longer a trimmed surface; for 1e-4, parts of components appeared to not be trimmed correctly (some parts of the component which should be trimmed remained), and for 1e-5 whole components were left untrimmed. (At the moment, my default tolerance for PW projects around a geometry of this scale is around 1e-6.)

I've come across 4 types of issues/warnings that I received over the course of using the API function for around 100 cases - they don't seem to appear when using the GUI. I've attached the vsp files for each warning so that you can reproduce them, if required.

1. /opt/openvsp/OpenVSP_libs_3.23.0/LIBIGES-prefix/src/LIBIGES/src/entities/entity102.cpp:739:AddSegment():

+ [ERROR] curve is aready closed
For A008.vsp3 - only happened for this single file in all the random samples.

2. BAD parameter in SurfPatch::find_closest_uw_planar_approx!

Example A004.vsp3. Making the tolerance smaller appears to increase the number of cases where this error appears.

3. ERROR: Incomplete IGES Loop

Example A038.vsp3. Happened much less often than error 2 above.

4. Minimum distance surface g_functor, v less than minimum.  vv: 0.004 vmin: 0.004

    Minimum distance surface gp_functor, v less than minimum.  vv: 0.004 vmin: 0.004

This error only appeared when setting the curve tolerance to 0.0001 or less for A042.vsp3

I'm not sure how much of a role the above errors play in the failure of the trimming algorithm at small tolerances, as I couldn't immediately see any issues with the successfully trimmed surfaces, where these errors would also appear.

I hope that helps with a little debugging. Let me know if you need more data! I look forward to having this function work more of the time, as then I can finally throw away my own intersection code...

Take care,

Tim