Shape Optimization Project

[Charles Schnake]

Hi,

I'm wanting to run a sample shape optimization case with OpenVSP & Cart3D. My goal is to drive some fuselage parameters (elliptical heights/widths @ prescribed axial locations) in a *.des file with an optimizer, call VSP to modify the baseline model and export a triangulation and then proceed with a standard Cart3D workflow to evaluate the fitness & constraint functions. I've got a few questions about things I'd like to use VSP for:

1. So far my call to VSP for the basic modify-->intersect-->export portion looks like this:  vsp -batch airplane.vsp -des fuselage.des -compgeom -tri Components.i.tri. Any issues that you can foresee with this (I haven't actually run it yet)? This is my first foray into running VSP outside the GUI.
2. Can you ask VSP to compute the volume of a specific section of the fuselage (i.e. volume between elliptical sections 5 and 8). This would be nice for computing fuel tank volumes rather than hacking together an estimate.
3. Can you set elliptical sections that will change with the OML as dependents of the curve fit through the defined/driven sections (I guess these would just be interpolated sections)? This would be nice for checking height/width minimum constraints at certain stations that should be allowed to change but aren't being driven.

Thanks in advance for any helpful tips.

-Charles

[Rob McDonald]

Charles,

My answers may be a bit nonlinear, but I'll try to help out as best I
can -- if I miss something, please feel free to follow up. I'll try
to respond to both emails here as well...

Are you using Marian's shape optimization framework, or is this
something that Desktop is developing themselves? The *.des file
support is paralleled by *.xddm support that was specifically crafted
to work with Marian's optimization framework.

The vsp -batch approach is correct (per visual inspection) for VSP
2.X, but I would really recommend you update to 3.X. Instead, you'll
need to use a small script -- the v3 way may not be as well
documented, let me know if you need a hand getting that working.

VSP Can take cross sections and output an area distribution. It is in
the menu near CompGeom, under slicing -- this is a little different in
V2 vs V3. Either way, you'll want X-Slices. You specify start, end,
and number of slices. You can trapezoid rule to come up with a volume
between two stations (specified in terms of model dimensions, not
cross section numbers). This slicing is closely related to what you'd
want for area ruling.

My student Michael Waddington just presented a paper at Aviation on
the interactive wave drag capability he is adding. We hope to have it
released in time for the workshop in August. It should be a great
tool for human in the loop wave drag design.

I think your intuition for where to put control points will prove
largely correct. Michael actually figured out how to identify what
station makes the greatest contribution to wave drag -- and then show
that intuitively to the user. The thing about wave drag is that it
isn't simply the rapid change in fuselage area, but the whole
aircraft. Considering the Mach angle, you may want control in some
fairly non-intuitive places -- say control the fuselage where the wing
starts intersecting the Mach angle.

In general, I recommend you try to use as few 'hard' cross sections as
possible to define your shape. Let VSP come up with the intermediate
shapes as interpolated sections as much as you can -- In v3, use the
angle and strength to get the shape you want (avoid the curvature
control, it is pretty unintuitive).

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.
> For more options, visit https://groups.google.com/d/optout.

[Charles Schnake]

Hey Rob, 

The optimizer I'm using isn't the design framework, it's an internal code that we have here that uses a simplex. 

Hmm, bummer. I was hoping that I wouldn't have to tackle the scripting (I can script in Matlab, and to a very limited extent in Python, but the presentation that was shown at last year's workshop didn't look very straightforward). I do have v3 installed though, so I'll try to make it work with that version. Will I still be able to use the *.des file with the v3 scripting approach? The *.des file format is convenient for the way our optimization script does input file variable substitution.

The slices + trapezoid rule for calculating fuselage section volume is similar to an approach I've used before with RAGE, so that shouldn't be a big deal. Even better would be to simply give VSP the forward and aft axial stations and get, in return, the integrated volume of the fuselage (maybe in v4? =) ).

Before seeing your response I did discover the AWAVE slicing tool (which is why I had deleted my add-on question) and begin to tinker with that. I looked at the slope of the average area (5 rotational slices @ the cruise Mach angle) between each axial station of the entire aircraft to pick out some top candidates. I'm sure I could get more refined with this approach but for the purposes of a capability demonstration this seemed sufficient.

Lastly, the one question that I'm still not clear on was how to check the interpolated ellipse width and height at a given axial location. Let's say I have some cabin width/height restrictions but that particular location isn't ideal as a control point. I'll want to be able to get the ellipse dimensions, not just the cross sectional area, for each new design to check against my constraints. Is there a way to do that with slices or do I need a different tool?

Thanks for all your help Rob.

-Charles

[Rob McDonald]

Charles,

I promise the scripting will be really simple for your use case. And
yes, scripting does work with the *.des file. Your command line will
look like this:

vsp airplane.vsp3 -des airplane.des -script myscript.vspscript

Where myscript.vspscript is a text file like this:

void main()
{
ComputeCompGeom( 0, false, NO_FILE_TYPE );
ExportFile( "Components.i.tri", 0, EXPORT_CART3D );
}

The zeros are the Set #. Zero is the All set. The false tells VSP to
not create a half mesh. The NO_FILE_TYPE tells VSP to skip writing
out the wetted area/volume report during CompGeom.

Adding a handy volume between stations calculator would be a pretty
simple thing to add. I'm also pretty sure you could accomplish the
same thing in the scripting (:. Perhaps I'll make that an exercise
for myself -- and an example for everyone.

The AWAVE Slicing in VSP has some bugs in it that Michael discovered
while doing his work. I don't remember what they are off the top of
my head, but I wouldn't rely on it as-is. I'll try to get Michael to
chime in and clarify the problems and any workarounds.

We don't have an API means to interrogate a surface at arbitrary
points. You can't really count on being able to ask for intermediate
width/height -- what if a section is transitioning from square to
circle, what would you report?

So, some sort of interference checker would really want to use a mesh
of the two objects, and then calculate a minimum distance between
them. In my experience, this works well if you modify the distance
function to be positive when there is no inteference, but then it
switches to the negative of the volume of overlap when objects
intefere. This provides a smooth continuous function appropriate for
optimization...

We've thought about adding more support for this kind of thing, but it
hasn't yet risen to the top of the priority stack.

Rob

[Michael Waddington]

Hi Charles,

I'll jump in here to offer my two cents on the AWAVE slicing tool. As Rob mentioned, I've done a bit of work in this area and found a couple of bugs in the Awave Slicing tool that may cause you some troubles:

1) there is a vehicle transformation procedure undertaken that does not fully agree with the slicing planes, resulting in these planes slicing the aircraft at a different rotation angle about the x-axis than intended;

2) there is a bug in the computation of the Mach plane angle that results in the Mach angle of the slicing planes being incorrect (sometimes barely incorrect, sometimes very incorrect).

If you are on V3, my recommendation would be to utilize the Planar Slice tool in the Analysis tab. This equates to the Mach 1 condition of Awave Slice, which will give you the cuts down the aircraft parallel to the Y-Z plane. This, in my opinion, offers the most intuitive feel for the area distribution. In V2, I believe you can access the same Planar Slice capability from within the Awave Slice tool by checking the 'Planar' radio button at the top of the GUI.

If it is truly the Mach >1 slicing planes of Awave in which you are interested, my first answer would be to hang tight until we can get my work released for August's workshop; if that is a no-go, we might be able to work out some type of workaround to get you by in the mean time (I would have to ponder it).

Please feel free to follow up with any questions, I would be happy to help.

Best,

Michael

[Charles Schnake]

Hi Rob,

Well, you make a good point for the arbitrary case. For my geometry, however, the fuselage is simply a series of elliptical sections so I think the interpolated sections should always be able to be defined by major/minor axes & a center point (right?). 

I'm not sure I understand your reference to the interference checker. In this case there really aren't 2 objects, there is only the fuselage (well okay, there are also the wing and nacelles, but those aren't relevant to the fuselage width/height constraints). Perhaps you're saying that I should build a thin ellipse inside the fuselage with the minimum dimensions @ the constrained stations and use the gap measurement between them and the fuselage as my constraint function? I'm not sure how to do that, is there a built-in function for computing distance between two components? If so, I couldn't find it.

Sorry for being dense. Unless I can figure out how to constrain the fuselage width & height @ certain x-locs I think my only recourse will be to set my design parameters @ at each constrained location with the corresponding UBs/LBs, and obviously that would undermine the effort to identify the most valuable control points.

-C

[Charles Schnake]

Also, even in the arbitrary case, even though you might not be able to define the cross-sectional geometry nicely, surely you can always identify the width (y-axis) and height (z-axis) at a given x plane? That would be sufficient for me to apply my constraints.

-C

[Rob McDonald]

On Tue, Jul 7, 2015 at 1:58 PM, Charles Schnake
<csch...@desktopaero.com> wrote:
> Well, you make a good point for the arbitrary case. For my geometry,
> however, the fuselage is simply a series of elliptical sections so I think
> the interpolated sections should always be able to be defined by major/minor
> axes & a center point (right?).

I agree that a simple geometry will produce simple cross sections. I
mainly meant that a general feature to monitor 'ellipse' parameters
for interpolated cross sections doesn't really work. In general, we
try to steer VSP development to work for the general case, this isn't
the sort of feature we would have already developed.

That said, I do believe it is something that should be doable for your use.

> I'm not sure I understand your reference to the interference checker. In
> this case there really aren't 2 objects, there is only the fuselage (well
> okay, there are also the wing and nacelles, but those aren't relevant to the
> fuselage width/height constraints). Perhaps you're saying that I should
> build a thin ellipse inside the fuselage with the minimum dimensions @ the
> constrained stations and use the gap measurement between them and the
> fuselage as my constraint function? I'm not sure how to do that, is there a
> built-in function for computing distance between two components? If so, I
> couldn't find it.

We don't have such a checker. I was implying that this is the general
approach I would take if I was developing such a capability. In my
scenario, you would define a 3D keep-out zone(s) to represent the
constraint(s). It could be a cylinder, or a representation of the
engine, pilot, fixed equipment, etc. Ideally, you could give the
optimizer some control to move those components around if it really
wanted to...

> Sorry for being dense. Unless I can figure out how to constrain the fuselage
> width & height @ certain x-locs I think my only recourse will be to set my
> design parameters @ at each constrained location with the corresponding
> UBs/LBs, and obviously that would undermine the effort to identify the most
> valuable control points.

I agree.

> Also, even in the arbitrary case, even though you might not be able to
> define the cross-sectional geometry nicely, surely you can always identify
> the width (y-axis) and height (z-axis) at a given x plane? That would be
> sufficient for me to apply my constraints.

There are a couple of approaches that you might want to take in this direction.

Either way, you're going to have to use VSP to output a representation
of the geometry and then write your own program to interpret that
representation in a way that constitutes the constraint for your
problem. You might be able to do this entirely in scripting, but for
argument sake, we'll just say it needs to be done.

The two file formats that immediately come to mind as 'easy' to use
for this are 1) the XSec *.hrm file (a simple wireframe format), or 2)
the DegenGeom format.


The XSec file is just the x,y,z coordinates of the wireframe you see
on screen. You can take those points and do whatever you need with
them.

The DegenGeom file (either *.csv or Matlab) includes different
representations. The 'Stick' representation calculates a 'chord' and
'toc' for any shape -- including fuselages. The 'chord' will
represent the width or height -- toc*chord will represent the other
one.

When you degenerate a wing to a plate, there is an obvious direction
to prefer -- and then to a stick, there is a clear chord and thickness
direction.... For a fuselage, it isn't clear which direction you
would prefer, so we do both! So, for each component, you will find
there are two degenerate sticks -- the first is smashed one way, the
second the other. In this case, one's 'chord' will be the width, the
other 'chord' will be the height.

At present, the DegenGeom data is not made available to the Scripting
via the API. So, you're probably best off using either the *.csv or
Matlab format to process and come up with your constraints.

Rob

[Charles Schnake]

Awesome, that'll get me started. Thanks!

[Charles Schnake]

Hi,

I'm encountering what appears to be a bug when I try to load my *.des file into VSP. VSP seems to drop a few of my design variables so that, when I've loaded the *.des file, only 16 out of my 19 variables are shown in the Design Variable editor window. Have you seen this before? Am I hitting some type of limit? I'm also going to try to use a nicer geometry and see if the problem replicates itself, because currently the values I've used aren't sensible, but I still would've thought that all of the variables in the *.des file would at least show up in the editor...

Thanks,

  Charles

-

[Charles Schnake]

I realized that I needed to be running this on Linux to simplify the interface with my optimizer, which is tied together with shell scripts. So I set out to follow the VSP website instructions for compiling OpenVSP on Linux. I made it almost all the way to the end, so I can now run vsp by navigating through a bunch of folders and launching the vsp executable, but the 'make package' command stymied me, so I don't think things are nicely ordered the way they are in my Windows installation.

Anyway, I thought I had done enough to get back to running the script you gave me. I tried running: vsp SBJ_OptDemo.vsp3 -des DesignVars.des -script myscript.vspscript and ended up with the following errors:

VSPAERO solver not found.

VSPAERO viewer not found.

ReadExecute (1, 1) : ERR  : Unexpected token '<unrecognized token>'

Error ExecuteScript GetModule 

I wasn't sure what was causing this, but for good measure I tracked down the vsp_aero & vspviewer executables (in the "solver" and "viewer" folders, respectively) and added them to PATH. That didn't seem to do anything, so instead of continuing to guess at solutions for a problem that I don't understand I thought I'd ask for help.

Thanks in advance for any guidance you can provide.

-Charles

[Charles Schnake]

Hold up, I just figured something out (by guessing at a solution yet again)

I had added a comment line to the script you provided me (I used '#' to start my comment line, I guess I should have used '//'??). I deleted this and now the only errors I get when launching the command below are:

VSPAERO solver not found.

VSPAERO viewer not found.

I'm not sure if this matters or not, since I'm not trying to run VSPAERO, but perhaps you can answer that.

Anyway, lesson learned as far as comment lines go.

-Charles

[Rob McDonald]

Charles,

Thanks for the information that 'make package' doesn't work on Linux,
I'll have to check that out.

Yes, it is somewhat annoying that CMake just leaves all the built
files wherever they are built...

You should be able to ignore the VSPAERO messages -- they are simply
warnings telling you that the solver isn't where the GUI expects it.
However, since you aren't going to use the VSPAERO solver, that won't
matter for you. VSP expects to find the VSPAERO solver and viewer
programs in the same directory that the VSP executable is in.
Anywhere else will throw the 'not found' message.

The remaining messages are actually syntax errors spit out by
AngelScript. The (1,1) is a (line, column) number for your script.
So, it doesn't like things right from the start.

I haven't tried what you're describing, so it may take me a bit to get
set up to try this myself...

Rob






On Tue, Jul 14, 2015 at 2:28 PM, Charles Schnake

[Rob McDonald]

Looks / Sounds good (see my other reply).

Yes, the *.vspscript is very C-Like, so comments are // blah or /* blah */.

Rob


On Tue, Jul 14, 2015 at 2:35 PM, Charles Schnake

[Rob McDonald]

While you're at it, you might want to try using the 'vspscript' executable.

It should be able to run any script you write exactly like VSP, but it
doesn't have any of the graphics libraries or other dependencies. So,
if you need to run it on a HPC machine with strict system
administration, it should do the trick.

Rob

On Tue, Jul 14, 2015 at 2:35 PM, Charles Schnake