Open Design Optimization Platform (ODOP) - Coil spring design app; mechanical springs; compression spring, extension spring, torsion spring

View the Project on GitHub thegrumpys/odop

Procedure to implement a new design type

This entry describes how to implement a new ODOP design type (a.k.a. "design problem").

Each design type gets its own sub-directory within the source code. The design equations for a specific design type are contained in a source code file named eqnset.js.

Files required for all design types:
  ( * = may be stub)

Additional (or non-stub) files may (optionally) be utilized by some design types.
For example, coil spring design types utilize:
  ( ** = non stub)

Modify template files:

---- Using an existing load.sql file as an example, overwrite the initialState section with the new initial state json.
---- {need more detail here} ...
---- See also: Making changes to initialState.js

Build a new GitHub repository ?



Notes as of early September, 2018 ...

The replacement for CONTNT is named init.js. It is called on every change to (any variable?, not just) a "Calculation Input" (every keystroke).

Regarding properties of Elements (entries, members, variables) in initialState.js:

Elements with the property ("input": true) are inputs to the design equations and go into the p vector. Fixed elements are compressed out and not operated on by Search. Elements with the property ("Input": false) are output from (modified by) either init.js or eqnset.js and go into the x vector. The d vector has been eliminated. Those elements are now distributed between the p and x vectors. The current implementation for the compression spring design type has essentially all of the former members of the d vector appearing as elements in x. This is partially for simplicity. Note that changes to the p vector are not saved into the state of the design. Thus, unexpected results (stale data) can occur if elements are moved into p and they later change. This stale data issue is not a concern for elements of x.

Elements with the property ("type": "equationset"), are fixable and constrainable ("unrestricted" in the terminology above). Elements with the property ("type": "calcinput"), are members of the previous d vector ("restricted" in the previous terminology).

Elements with the property ("hidden": true) are not visible in the user interface.

The rules for defining elements (entries, members, variables) in initialState.js:

Any variable on the left of an equals sign in either init.js or eqnset.js must be ("input": false) ... in the x vector.

Any variable appearing only on the right of an equal sign in both init.js and eqnset.js may be ("input": true) ... in the p vector. Note that x variables may also appear on the right of an equals sign. This has no relevance to their assignment as ("input": false). When in doubt, it is generally safe (safer) to assign an element as ("input": false).