Optimize Buoy Design Applet
Simple Buoy Design w/ Cargo: Physics-Based Problem Example
This is a BETA website for Windward Mark Engineering.
The site is currently being developed and should be considered experimental.
It should only be used for testing and development.
| Introduction |
|
Below is a simple, hypothetical scenario that uses the framework presented in the
Engineering Automation and Optimization page. Suppose there is
a client who needed a buoy designed in such a way that it could support a given cargo. The
technical expert needs to make sure the buoy can not only float, but also ensure the cargo onboard does not
get submerged if the cargo gets placed at the deck edge. |
|
Optimize Buoy Design Applet |
|
Simple Buoy Design w/ Cargo: Physics-Based Problem Example |
| Problem Definition |
|
The Cargo weight and size are assumed to be part of the design specification. The client will
establish this as part of their request to me as their engineer. It will be my job to use my
experience to anticipate load cases (which usually involves discussions with the client as well)
and I will define all aspects of the buoy size and construction to provide my client with a design
that can float while supporting their desired cargo. Designing a feasible buoy is the most important goal, but if I've done my job well, we should use our technical know-how to consume the fewest resources to create it. Again, keeping this example simple, we will focus on designing a buoy that uses the least amount of construction material to build. So, let's look at this simple problem as a Physics-based AI engineering problem, and use the flow chart to automate the process while creating an optimal design. Let's follow the flow chart for Physics-based AI below: |
 Logic Flowchart: Physics-Based Problem Solving |
|
For this example, we are going to bypass the data-analysis process often used in data-based AI. Instead, we will use a more reliable means of optimal design answers. We are going to use physics directly. This is a simple case, where we have the necessary physical definitions and equations used to make those predictions needed to reliably define a feasible, and then, optimal design -- all automatically. So, let's see how it might work to solve this problem directly with a physics-based approach. The most important physics equation for this problem is Archimedes' Principle. Stated simply, the weight of the displaced object is equal to the volume of the water being displaced. So, this requires calculation of two quantities: 1) the volume of water being displaced, and 2) the weight of the buoy itself. For now, let's leave the problem this simple. Let's not get bogged down (yet) on other concerns and focus on one objective: use the least amount of material to construct the buoy. |
| Goal Definition | ||||||||||||||||
| When referring to literature on formal design optimization, it is common to frame the problem in to two statements. The first statement is the Goal (or objective), and the second statement is a list of requirements and limitations (aka constraints). So, for the simple buoy design problem, the problem definition statements are as followed: | ||||||||||||||||
|
||||||||||||||||
| Design Variables |
|
All problems are defined by two categories of information: factors that we can change, factors that
we do not change (or can not change). Let's look at the variables we do change for designing our
buoy. |
| Independent Variables |
|
The changing variables for this problem belong in two categories of information. The first group is the
Independent variables that define the size and shape of the buoy itself. A casual observer
would ordinarily describe the buoy by these measurements. In this case, the buoy is a simple cylinder
which is defined by a diameter and a height. The horizontal cross-section is assumed to be
circular. |
  Principal Dimensions: Buoy Geometry Definition |
|
The buoy size dimensions will be used to calculate the weight of structure needed to construct the buoy (see below for details); and they will also be used to calculate the volume of the water being displaced. Another group of Independent variables, are the dimensions that define the orientation with respect to the displaced water. For this example, these are the vertical position, and rotation, of the buoy. These inputs are used by the model to calculate reaction forces and moments. Since the entire set of loads is governed by Archimedes' Principle, we need variables that establish how much water is being displaced, and, where the centers of the displaced volumes are located. The properly designed buoy will achieve Archimedean balance, along with Centers of Gravity & Buoyancy that are aligned. These variables allow the solver to search for these states of balance. |
 Principal Dimensions: Buoy Geometry Definition |
 Center of Buoyancy: Location wrt Rotation |
 Changing Variables: Horizontal Position of Vertical Loads |
|
This brings up a very important, yet non-intuitive, observation. The obvious Goal of the design problem is to make the lightest hull possible. However, a strict execution of an optimization program with respect to the hull dimensions alone would immediately chase a solution of Diameter = 0 & Height = 0. Yes, this is absurd. But, in the world of Optimization, it is important to use the knowledge you have to frame the problem properly. A stupid computer will tell you the lightest hull is no hull at all. Our engineering intuition knows there's more to the problem. So, refer to the 'such that' portion of the problem definition above. There are Constraints on the problem; specifically, the buoy hull must displace enough water to support the cargo. It seems trivial, but it is actually very important to remember. It's often the Constraints that you are designing too, not necessarily the Objective Function. But it's also the very essence of Optimization, as described by LaGrange with his novel concept of using gradient matching embedded into a single Objective Function (aka the 'LaGrangian'). Very literally, there are restrictions on how small the Objective Function can realistically be, due to the dimensional and positional Constraints. The entirety of these Objective Function and Constraints becomes the Optimization Function. In this example, the cylinder's vertical position must beget the matching displacement with respect to the weight of the buoy itself. Similarly, there is a rotational position that must match the vertical load positions. See the diagram above. As the buoy rotates, the Center of Buoyancy (the 3D centroid of the wetted volume) shifts laterally and eventually aligns with the Center of Gravity of the Cylindrical Hull and the Cargo on deck. Therefore, it's important to recognize that the vertical position and rotation position are also Independent variables that vary during the optimization process. Part of the Objective Function is achieving Archimedean balance. |
| Non-Optimized Design Variables (Constant wrt Objective) | ||||
|
When defining the problem and its constraints, it is also important to determine model variables which
do not get optimized. These 'variables' are inputs used during the design modeling process, but they
do not change during the search for the optimal design. These non-varying inputs may be defined initially by
the user, and may be essential to defining the behavior of the numerical models that serve as the
Objective Function, but, they will not change during the search for the best design. These non-changing factors fall into several categories. The list below are just a few types considered for this example, but the list is certainly not exhaustive:
|
||||
For this simplified design example, the two most important non-changing variables used are:
|
|
Another non-changing variable is the Cargo itself; but, it is actually part of the problem definition itself.
For this example, it is stipulated that the Cargo properties do not change once it is loaded onboard the
deck of the hull. That said, there are several assumptions made by the example applet when defining the cargo. In actual practice, these sorts of details should be specified, but for simplicity in creating an example applet the following is assumed to be defined by the 'customer':
|
| Constraints |
|
Constraints are the limitations on a problem that often make the problem difficult to solve. In fact,
the constraints are the most important part of the Objective Function. It is the combination of Constraints
that usually force problem-solvers to seek the 'creative' approach, and often work against the ideal solution.
(it's also where Engineer's earn their money.) For this example, it's even possible to argue the constraint IS the problem. If the buoy didn't sink when too much cargo was sitting on the deck, then an infinitesimally small buoy design would suffice. Physics Archimedes' principle makes life much more complicated. |
| Archimedean Constraints (Equality Constraints) |
|
As stated above, without the constraints,
the ideal (and yet impossible) solution to the minimal hull size would be no hull at all. The only part
of the problem definition that requires there to be a hull in existence is the Archimedean balance. A hull
must be of a sufficient size to displace enough water to float the specified cargo. And if any hull is required, it would necessarily have its own self weight to then consider in Archimedean balance. Fortunately, even though the material used to make the hull is far more dense than the water it floats in, there is a void space formed within the hull (interior of the hull plating). Fortunately, this void is generated at a faster rate than the hull principal dimensions, so there is a limit to how much hull is required to have sufficient buoyancy for the cargo AND the hull itself. This excess rate of generating interior void space is the answer to the archetypal question: 'why do boats float?'. In this example problem, we will vary the Hull Diameter and Hull Height until we strike a balance between the hull's weight and the hull's displaced volume. As discussed above, the LaGrangian will also include the hull's position in the set of changing variables to seek a balance of the Displaced Volume * Water Density to be equal to the weight of the Hull & Cargo. Note: It's important to understand this balance is not guaranteed. If the hull's volume is not great enough to displace enough water to equal the weight of itself and its cargo, then the hull will sink. The LaGrangian form of the Optimization Function will also include the hull's rotation in the set of changing variables to gauge alignment of the generated vertical loads. The Cargo's placement at the deck edge will necessarily shift the horizontal center of gravity outboard of the hull's centerline. The rotation will then change the shape of the submerged cylinder, and that changing shape will have a Center of Buoyancy that will also shift outboard from the hull centerline. If the Center of Buoyancy shifts outboard enough to align with the location of the Center of Gravity, then the hull rotation will also achieve (CoB::CoG) Archimedean equilibrium. Like the observation above with respect to displacement, it's important to understand this shift in buoyancy center is not guaranteed to ever align with the shift in mass center. The hull's maximum shift in buoyancy is (approximately) achieved when the deck corner is submerged and outboard at its maximum with respect to the origin. If the Center of Buoyancy does not shift outboard enough to encounter the shift in the Center of Gravity, then the buoy will be insufficiently stable, and will roll over. From a theoretical standpoint, these constraints are both equality constraints. Their necessary implementation takes this simple optimization scenario from the relatively benign realm of Unconstrained Optimization to the much more complex world of Constrained Optimization. Considering the technical requirements explained above, and the significant chance that a solution isn't viable, or a non-feasible solution will be encountered during the search for the optimum, the problem is much more complex than might be encountered with a simple Algebraic optimization problem. |
| Operational Constraints (Inequality Constraints) |
|
To add to the complexity of the practical example, we will add another requirement for study. Let's also
stipulate the need to keep the cargo dry under maximum rotation. There is reserve buoyancy in further
rotation (as the deck slips below the waterline, the Center of Buoyancy can continue to shift outboard),
however, this characteristic is undesirable from a pragmatic standpoint. What good is placing your
cargo on the buoy, if there isn't also the expectation that the cargo will stay dry. |
 Dry Cargo Constraint: Geometry of Maximum Allowable Hull Rotation |
|
From a theoretical standpoint, this constraint is an inequality constraint. No specific condition is required, but rather a limit on a maximum condition is placed. The optimal solution to the buoy design does not force a rotation that is submerged; it merely is a possibility. As such, the "dry cargo" constraint is an inequality constraint. This constraint may, or may not, be active in the final solution. This implementation of a non-equality -- but possibly needed -- constraint, takes the already challenging class of Equality-Constrained optimization, to the far more complicated class of Inequality-Constrained optimization. This requirement compounds the challenges that increase the likelihood of a non-feasible solution will be encountered during the search for the optimum. This addition to the real-example problem is now far, far more complex than might be encountered with a simple algebraic optimization problem. Again, this is why this problem is such a good example to explore, for all its technical challenges not ordinarily encountered in a pedestrian 'numerical methods' text. See the explanation of some of the technical details here. |
| Feasibility Limitations (Implied Constraints) | ||
|
Not all constraints are explicitly defined by the model maker. Many constraints are implied (although
often explicitly defined to be consistent). Other implied constraints are captured when the search
domain is defined (see the next section). For this particular example problem, the following limitations are implied. However, most of these considerations are contained within the models, and will return an 'infeasible error' flag if these conditions are encountered during the search. The decision to include these constraints explicitly is a tradeoff: each explicit constraint adds complexity to the LaGrangian Objective Function, but also automatically guides the search away from infeasible answers. But it can also create domain regions that 'trap' a solution search within a feasible, but unrealistic (or ultimately still infeasible) regime. |
||
|
1a: Diameter > 0, Height > 0 (not possible to have negative dimensions)
1b: 100% > % Submergence > 0% (if < 0%, not displacing water; if > 100%, the buoy sinks) 1c: Rotation > 0 (Cargo weight at the deck edge should not beget negative rotations) 2: Height > (Top + Bottom) Plate Thickness & Stiffeners 3: Diameter > 2 * Bottom Plate Thickness & Stiffeners 4: Diameter > Nominal Cargo Footprint (Cargo footprint is fixed & defined by user) |
||
| Feasible Domain Definition | ||
|
The algorithm used to perform the search must be given the guidance of where to search, and where not
to search. Defining these boundaries is often the most critical part of assessing the problem. It is
important to properly fence the search. A search that is too broad may explore infeasible, impractical,
or technically impossible solutions. Ironically, this same freedom is one of the most important features
of Physics-based AI. There is no pre-conceived answer, or notion of "silly" answers. The computer
does have biases based on experience, or aesthetics, or superficial desires. If the answer is
feasible and optimal, it should be considered for design. At the very least, the end user should
learn from the result (see the Weight model lesson below) and identify what did, and did not make the
answer viable. The feasible, yet unexpected, result is potentially a disruptive answer. Do not dismiss
them lightly. For this example, the following approach was used to initialize a feasible domain that was sufficiently wide to capture unexpected results, while excluding design combinations that would simply not be possible or desired for practical reasons. |
||
| Domain Bounds Logic for Hull Diameter & Height | ||
|
||
| Domain Bounds Logic for Max Displacement & Rotation | ||
|
||
| Modeling and Execution |
| Models |
|
The two portions of the Archimedean balance being sought require two very important calculations. The models need to be tested over the domain of anticipated possible solutions (see above). For cases where the model is not feasible (for instance when the calculated weight would exceed the available buoyancy) then the model needs to return an error flag, preferably with some guidance on how to handle the error. |
| Volume Geometry Model |
|
The Volume, and the corresponding Center of Buoyancy, is calculated using the model found in the applet
here. |
The applet looks for three geometric conditions, each based on how the waterline slices the
cylindrical shape.
|
 Volume Geometry Model: Output Example |
| Buoy Hull Weight Model (Very Simple) |
|
The weight model has not been converted into a specific applet. The initial weight estimate for the buoy hull
consisted of simple shell plates, whose thickness were defined as a proportion of the buoy's height. Typically,
the actual shell plate thickness of floating
structures is driven by the hydrostatic pressure (plus some dynamic loading) and the plate is
thicker at the bottom, with an trapezoidally-increasing thickness between the top plate and bottom
plate. Additionally, the interior void of the buoy hull will be filled with 5% internal structure.
The internal structure will be located at the centerline, with the vertical center applied at the same
vertical location as the side-shell. |
 Weight Model: Simplified Assumption |
|
Lesson Learned: When the model was run with these assumptions, the solution converged immediately on a flat disk, with enough thickness and diameter to generate the required buoyancy. Therefore, the model was updated to properly reflect dependency on the structure as actually needed for strength. (see the discussion below on Soft Assessment) The simple model did not account for the calculated hydrostatic stress from the water nor the bending and shear stress from the uneven forces induced by the cargo forces above, and the buoyancy pressure beneath the plate. These stresses are relevant, and cannot be ignored, even in a simplified modeling approach. |
| Buoy Hull Weight Model (More Detail) |
|
A new, more rigorous, structural model was developed. This model needed to reflect a more accurate, and realistic
estimate of the need for structure. Even in this very basic example model, the simple shell plate estimate proved too simple.
The model needed to consider the need for more structural modeling accuracy, even if the approach was still
simple, compared to a full structural design. The revised model made the following assumptions:
|
 Weight Model: Simplified Assumption |
|
A lower-bound interior void gap was also calculated by assuming typical stiffeners based on the following dimensional assumptions:
|
 Weight Model: Simplified Framing  Required Internal Volume: Non-Zero Height and Diameter |
|
By making the structural weight dependent on bending and shear stresses (with those stress calculations being dependent on both Hull Diameter and Hull Height), the optimizer does not chase solutions that are unrealistically thin. This ends up being an important lesson: the parametric model needs to contain enough detail that the correct Objective is being sought. Without requiring the structural model (and therefore the weight model) to be dependent on the Hull Diameter and Height, the optimizer assumed a solution that wasn't practical. |
| Combined Objective Function Model |
|
Now the individual models have been generated, validated, and return either answers or guidance on
how to handle errors. The models now must be combined such that they return a single design option
for the inputs. The applet for the combined Weight and Forced Model can be found here. The model in this Applet takes in the Client-requested input (Cargo mass), as well as the four Independent Variables: Buoy Diameter, Buoy Height, Buoy Vertical Position, and Buoy Rotation. The model also takes in several non-changing inputs, to offer the user a chance to try other design scenarios. These options include Construction Material type and Displacement Water type. The overall idea is that a single 'snapshot' is generated for a given set of inputs, and the returned answer contains all the feedback needed to evaluate the design. |
 Combined Model: Output Example |
| Automated & Optimized Execution |
|
Referring to the picture below, the model returns all the necessary information for the AI engine to
process the design. The engine will generate numerical derivative matrices (Hessian and Jacobian), utilize
Newton's Method on the full LaGrangian Objective Function, and return an anticipated directional
step vector. The input design parameters will be incremented by the step vector, and the process will be
repeated for the next design scenario. Per Newton's Method, the process will be repeated until the
step size is small, and essentially no change is observed from one step to the next. When these values
are ~0, then the
Karush-Kuhn-Tucker condition is satisfied, and the Design process is complete. |
 Execution: Final Answer Example |
| Post-Execution Assessments | ||
Referring to the outline at the top of the page, the major steps of the design process have been completed:
|
||
| Hard Assessment | ||
|
The hard assessment process is the process of scrutinizing the automation steps. When the evaluation steps
do not converge on an answer, the steps should be traced. These step progressions should offer insight into
the design process itself. |
||
| Observations from the Solution Steps Animation | ||
|
The animation below shows the steps of each calculation, for each generation
of the Interior Point convergence. It is a typical result for this example problem, and it reveals some fundamental
challenges with this problem. The problem seems very simple, but examining the solution process
provides an interesting education on how solvers work on problems. Moreover, the over-capping observation
is that simple-looking problems often have deeper qualities that make them complex. |
||
|
||
 Execution: Typical Animation of Automated Buoy Design Steps |
||
|
Refer to the 2-dimensional slice of the 4-dimensional Solution Domain below. The solution is for the Cargo mass of 1111kg.
The slice is taken with respect to Height vs. Diam at the solution {Height: 1.85m, Diam: 3.57m, Rotation: 11.02deg, 77.3%sub} |
||
 2D Slice at the Solution: Hull Diameter vs. Hull Height with Constraints |
||
|
||
Observations Summary:
|
||
|
Upon further study of the 2D slice diagram above, there are some deep complexities hidden within. Cost Function Concerns
|
||
Cost Function: Literally measure of Volume of Construction Material
|
||
| Other Non-Convergence Issues | ||
Although this example does not have any of the following issues, these issues are common and should
be considered should you ever have convergence problems on your particular problem. Should you encounter
convergence problems, examine the step-by-step process (for example the animation provided above) to
see if any of the following are happening:
|
||
| Soft Assessment | ||
Checklist
Reminder of Weight Model Lesson... I found out the hard way on this very example, that my assumed structural model was insufficient, and the simplifications I made were giving misleading answers. |
||
| Learn & Adapt | ||
|
Details of Soft assessment... Reminder of Weight Model Lesson... I found out the hard way on this very example, that my assumed structural model was insufficient, and the simplifications I made were giving misleading answers.
|
| Success |
|
After scrutinizing with Hard and Soft assessments If the soft assessment fails, don't be afraid to go back to the beginning of the process. requires experience and human intuition. |
| Lessons |
|
Model of Geometry
Model of Structure
Essence of Stability
Practical vs. Ideal Solution |
| Improvements to Next Design Iteration |
|
Influence of Inertia & Friction
Influence of Mooring
More Detailed Structure |
