Optimization Constraints - edwardkort/WWIDesigner GitHub Wiki

Optimization Parameters

WIDesigner is, at its heart, a parametric optimizer in which the parameters are various dimensions of a woodwind instrument geometry, and the optimization target is the tuning accuracy of that geometry. These parameters might include the size and position of the tone holes, bore characteristics, or any other parameter that is part of the instrument's design model. To constrain the optimizer's choice of values for these parameters so we get an instrument useful to its intended players, we configure lower and upper bounds for each parameter.

The optimization parameters need not be identical to dimensions of the geometry. To make the constraints more physically meaningful, there may be a transform involved that maps parameters to the physical instrument. For example, hole position parameters typically specify the spacing between holes, rather than the absolute position. Spacing constraints ensure the holes remain in the same relative order, and can accommodate the physical limitations of the player's fingers. Similarly, parameters for bore point position and diameter generally specify ratios, rather than absolute values. This allows constraints to control the relative appearance of the bore, or the direction of taper.

An optimization parameter can even determine more than one dimension of the geometry, as illustrated by the grouped hole optimizers of the NAF study model. These optimizers maintain equal spacing between finger holes, for aesthetic effect, and a single optimization parameter controls the spacing between neighbouring holes for all holes in a group.

The world before Constraints

The optimizers in WIDesigner use plugins, called objective functions, that define the design strategy to be performed by the optimizer. There are a number of such strategies defined, such as:

  • Vary only the tone-hole sizes
  • Vary tone-hole sizes and positions
  • Vary bore profile
  • Vary tone-hole sizes and positions, and include simple bore perturbations
  • As above, but also specify that the spacing of defined groups of tone holes are uniform

Each of these strategies may be applied to different instrument types, with various number of tone holes. The associated parameters and bounds similarly proliferate.

The objective function serves two arrays of numbers to the optimizer, one each for the lower and upper bounds. The array size must match the number of parameters, and the order must be the same as the order the parameters are presented to the optimizer. This level of obfuscation is tolerable when the bounds were supplied programmatically but is impossible for the user to understand when that user is allowed to edit the bounds.

What are Constraints?

Enter the concept of a Constraint. A Constraint is associated with a single optimization parameter and contains:

  • A description of the associated parameter
  • A unit of measure for the parameter and its bounds (meters, centimeters, inches, feet, dimensionless)
  • A lower bound, in the unit of measure specified
  • An upper bound, in the unit of measure specified

Constraint instances are grouped into categories, and multiple categories may be grouped under one objective function. A grouping of Constraint instances is called Constraints.

With this bottom-up approach, Constraints are "owned" by a specific entry in the Optimizer list, known as the objective function. (The Constraint instances are defined within the objective function class and are not interchangeable between objective functions, although they may be shared by different MergedObjectiveFunction-derived classes.) In practice, an optimizer uses a specific instrument instance for creating Constraints, to:

  • Determine and set the number of tone holes
  • Extract tone-hole names as part of the Constraint description
  • Set the unit of measure for each Constraint

The study model also plays a role, defining the bounds for creating default and blank Constraints, which are expected to be different in each study.

Organizing Constraints

A categorical hierarchy grouping Constraints instances would then be: number of tone holes => objective function name => study model name. As implemented under the NafStudyModel, the UI attempts to help the user in creating and selecting the appropriate Constraints for the instrument and optimizer (really the objective function) being used for a given optimization. The next paragraphs describe these UI features.

Menu support for Constraints

The Options dialog allow customization of the base directory for Constraints files. The UI uses this base directory to build a file path that reflects the categorical hierarchy described above. The UI offers 4 new menu items in the File menu specific to Constraints handling:

  • Open constraints... is only enabled when the base directory is set in the Options dialog, and an Instrument and Optimizer are selected in the Study View. When selected, this menu item invokes an Open dialog set to the appropriate constraints directory. Exiting the dialog resets the "lastDirectory" value of the UI to its prior value.
  • Save-as constraints... similarly opens a Save dialog in the appropriate directory. This menu item is enabled whenever Constraints are selected in the editor pane.
  • Create default constraints and Create blank constraints are enabled under the same conditions as the Open constraints menu item. Create default constraints builds a new Constraints file with bounds values defined in the current study model. If no appropriate default Constraints are defined, a blank Constraints is created. A blank Constraints has zero set for all the bounds.

Because a Constraints file is just an XML file, distinguishable only by its contents, the standard Open..., Save, and Save as... menu item also work, but without the directory-location support.

Constraints Files in the NAF Study Model

If a Constraints file is opened with the standard Open... menu item, the following Study behavior will be invoked:

  • The Constraints will be displayed in the editor pane, as expected
  • If the Instrument selected in the Study has the same number of holes as the Constraints, or if no instrument is selected, the Constraints will be displayed in the Constraints branch, and the associated Optimizer will be selected.

Multiple Constraints files may be open in the editor pane at any particular time. These Constraints won't necessarily represent the same optimizer or number of tone holes. The Constraints section of the Study will show only those open Constraints files that match the currently-selected Optimizer and the number of tone holes of the currently-selected Instrument.

Programmatically, the NafStudyModel maintains a hash of Constraints Category lists, keyed by the Optimizer and number of tone holes. The appropriate list is swapped in when the Instrument or Optimizer selection changes.

Constraints Files in Other Study Models

Each Constraints file identifies a specific objective function from the Optimizer list. To optimize an instrument, you can select one of the standard objective functions from the Optimizer list, and use its default constraints, or you can use Create blank constraints or Create default constraints to open those constraints in the editor pane, and customize the lower and upper bounds. Each open Constraints file appears as a new entry in the Optimizer list. When you select one of these entries, the optimizer will use the corresponding objective function, and the customized lower and upper bounds. Unlike the NAF Study Model, other study models do not have a separate branch in the Study tree for Constraints.