You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>In this particular setup, there are two design variables: wing area and cruise altitude. The objective is to minimize fuel burn, and there is only one constraint: fuel margin. The default inputs are defined in the following lines.</p>
<p>Each input parameter takes in 5 values; a tag (an identification to communicate between the optimizer and SUAVE), an initial value, set of bounds, a scale factor (many optimizers tend to be more effective when the input values are of order 1), as well as the units used.</p>
94
95
95
96
<p>The objective and constraints are defined in the lines below.</p>
96
97
97
-
<divclass="highlight_code"><divclass="highlight_code"><preclass="highlight_code"><code># [ tag, scaling, units ]
<p>Note that in this case, only a single constraint is used. Multiple constraints may be used using a list format, similar to the input variables.</p>
109
112
110
113
<p>This file also defines the “aliasing,” i.e. how the design variables, constraints, and objective map to the variables used in Procedure.py (which is where the problem is evaluated). The aliases for this problem are defined in the lines below. Note that the first entry refers to the tag defined in either problem.inputs, problem.objective, or problem.constraints.</p>
<p>Note that, sometimes, a single input can map to multiple outputs, such as the “wing_area” design variable; in this case, use a list for the outputs, as seen above. The use of a wild card “*”, can also allow values to map to multiple outputs. Values to be outputted cannot contain wild cards as that would be ambiguous to an optimizer.</p>
@@ -174,7 +178,8 @@ <h3 id="running-the-problem">Running the Problem:</h3>
174
178
<h3id="running-a-sweep-of-the-inputs">Running a Sweep of the Inputs</h3>
175
179
<p>Now try running a 2D sweep of the problem to observe the shape of the design space: comment <codeclass="highlighter-rouge">output = problem.objective</code> then uncomment the following (the next line down in the code).</p>
<p>From the default inputs, the terminal (or IDE output) should display an optimum of [ 1.08980937 1.02089232], which corresponds to a wing area of 109 m^2, and 10.2 km. It appears to have found the local minimum.</p>
206
+
<p>From the default inputs, the terminal (or IDE output) should display an optimum of [0.57213139 0.75471681] which corresponds to a wing area of 58 m^2, and 7.5 km. It appears to have found a minima. Keep in mind that in designing a real regional jet the desingers would incorporate additional constraints and analyses. These additional constraints change the final design considerably</p>
201
207
202
-
<p>Now try starting the optimization from a different initial guess. You can either modify the input parameters in the initial formulation (the relevant lines are repeated below with the modification)</p>
203
-
204
-
<divclass="highlight_code"><divclass="highlight_code"><preclass="highlight_code"><code># [ tag , initial, (lb,ub) , scaling , units ]
<p>This starts the optimization problem above the feasible region (wing area = 128 m^2, altitude = 13.8 km), and results in a fuel burn that is 30 kg lower than the result using the initial guess. This illustrates the important of choosing a starting point when running optimization problem. Additionally, this demonstrates SUAVE’s ability to handle infeasible cases, showing that it can converge to a feasible case even when starting from an infeasible set of initial inputs.</p>
223
-
224
210
<p>At this point, you can explore other starting points, or alter the vehicle or mission properties in Vehicles.py or Missions.py. Additionally, feel free to start using this as the basis for creating custom optimization scripts.</p>
<p>Next, you will setup the vehicle. This is very similar to the prior Solar UAV tutorial, so we will gloss over this. The one noticeable difference is that a lower fidelity energy network is used. This means that most components operate with prescribed efficiencies. For example:</p>
<p>So we can tell now that the battery energy doesn’t go all the way to zero. One thing to note, because we have a solar UAV the voltage is regulated differently and the C-rate doesn't apply in the same way.
305
309
306
-
<p>So we can tell now that the battery energy doesn’t go all the way to zero. Let’s look at how the solar flux varies throughout the day and how that affects the draw from the battery.</p>
310
+
Let’s look at how the solar flux varies throughout the day and how that affects the draw from the battery.</p>
0 commit comments