Extension spring search failures & special cases

[grumpyinca]

It has become apparent that the extension spring model has multiple special (a.k.a. "pathological") cases that require further investigation. Specifically, these cases need to be isolated & traced back to a "root cause".

These cases sometimes cause search failures or sometimes cause the search to converge to a point that is OBJ < OBJMIN feasible but is really an invalid spring. Perhaps adjustment in the current validity configuration will be sufficient. Perhaps it will be necessary to make changes in extension spring's eqnset.js.

Areas of concern

• Wire diameter = 0 causes Objective Value = infinity. Search cannot resolve the situation.
• Wire diameter is small. For example, start with initialState, set Wire_Dia to smallest entry in table. If Wire_Dia is Free, Search succeeds. If Fixed, Search fails with Force_1 & Force_2 inverted and %_Safe_Deflect ~ 0.
• Wire_Dia is twice OD_Free. ID_Free = 0. OBJ = infinity.
• The entire "regime" where the Max Safe force is less than initial tension. The attached export file shows a situation where %_Safe_Deflection flips sign and exponent with a tiny change in OD_Free. As noted in File : Properties: "Change OD_Free from 0.3793 to 0.3792 to flip the sign on %_Safe_Deflection".

WhyPC_SafeDeflectNegative2.json.txt

[grumpyinca]

Today's discussion touched on a number of numeric issues and led to #764.

It seems that it will be appropriate to make changes in both initialState and include additional division-by-zero protections in eqnset.

For example, in initialState, for OD_Free, Wire_Dia and Coils_T, "validmin": 0.0 needs to change to "validmin": Number.MIN_VALUE and perhaps an "engineering realistic" value that much, much larger.

It was observed that in computing the Objective Value, taking the difference between two extremely small numbers and then squaring the result can produce a value that is outside the floating-point limits.

[grumpyinca]

Background on JavaScript alternatives for handling divide-by-zero: https://stackoverflow.com/questions/8072323/best-way-to-prevent-handle-divide-by-0-in-javascript

[grumpyinca]

Today's discussion raised concern about the use of smallnum in order to mitigate divide-by-zero "corrupting" the design equations. The preferred approach is to validate user input such the risk of divide-by-zero is eliminated.

While conceptually attractive, there are issues:

• In addition to a simple range check, how do you handle relationship violations and how do you communicate to the user that the entry of value "A" caused a relationship problem between values "B" and "C" ?
• Suppose it is the exploration moves of the search algorithm that are generating inputs that result in Objective values of either "infinity" or "NaN". How does (should) Search respond to "infinity" and "NaN" Objective Values ?

Examine PCyl & Solid for how they respond to extreme user inputs and determine if they need divide-by-zero mitigation. Perhaps those solutions can be an alternative to the approaches investigated in this branch.

Consider testing Objective Value at the conclusion of Search, Seek and Trade. If not valid (infinity or NaN) put out an appropriate Alert (or pop-up).

Separately, when Search returns without a feasible solution, there may also be an opportunity to guide the user by creating an alert (or pop-up) that asks if it is possible that the design is over-specified.