Search failures in demo & tutor scripts

[grumpyinca]

Recent testing with compression spring Demo & Tutor scripts shows a low-to-moderate frequency of Search failures. Specifically, this is a situation where Search converges on delmin without achieving anything close to the better (correct?) answer produced by the same search in v4.2.2.

If v4.3 is provided a start point that is a bit closer to the desired answer, it will converge (usually objmin) to something respectably close to that desired answer of v4.4.2. Perhaps this implies multiple minima in the objective function.

The problem was not observed in previous v4.3 testing of Demo & Tutor execute scripts. Thus, perhaps the problem is recently introduced. Also, this may be evidence that #702 is not the source of these failures.

Note that it is only compression springs searches fail in this manner. So, taking a huge leap, perhaps the undesired behavior was introduced by either #712 or perhaps #714.

Example of the failures in question are available in the searches at:

• demoDesignValidation - p7
• tutor3 - p9
• tutor7 - p10
• tutor8 - p3

[grumpyinca]

The code changes implemented today include removing the compression spring eqnset.js changes that were developed in #712 and switching the FDVL (dynamic validity level) in initialState from (Force_2 MAX = Force_Solid) to (L_2 MIN = L_Solid).

Additional testing is planned.

[grumpyinca]

The version containing the changes noted above is now named v4.3rc2.

v4.3rc2 test results show 31 of 32 compression spring searches producing what is considered to be "correct" results.

The search in tutor8 - p3 is supposed to converge on delmin. It does. The problem is that the v4.3rc2 result is dramatically inferior to the v4.2.2 result. If you tweak the v4.3rc2 result to be a bit closer to the v4.2.2 result and repeat search, it converges to something that is very close to the 4.2.2 result. So yes, this is the discussed "whack-a-mole" situation, but there may be hope.

Notice that the failing search in tutor8 - p3 converges to an objective value of 1.00419. I don't think that being this close to the value of 1.0 is a coincidence.

In /odop/client/src/store/middleware/pxUpdateObjectiveValue.js and UpdateObjectiveValue.js, the code following the comment: * This version reduces penalty of large fix violations. may be the key. Specifically, I am thinking that we may need to apply a similar reduction in penalty to the new validity penalty. I will save the details for conversation.

I have discovered that in v4.3rc2, replacing the tutor8 - p3 FIX Force_2 250 with a constraint (Force_2 MIN 250) allows Search to produce a "correct" result (~ matches v4.2.2 result). The starting value of Force_2 must be greater than ~100 in order to produce the "correct" result.

Similarly, replacing the default 3.000-inch value of L_Free with any value greater than 3.005 or in the range 2.1 to 2.995 allows the search on tutor8 - p3 to produce the "correct" result.

Similarly, replacing the default 10 coil value of Coils_T with any value greater than 10.1 or in the range 7.2 to 9.994 allows the search on tutor8 - p3 to produce the "correct" result.

[grumpyinca]

Regarding the previous comment:

• Review of the code determined that the penalty reduction already applied to validity penalties.
• Changes have made differences in the values required to switch between "correct" and "incorrect" behavior.

Changes were made to better structure the cycle life calculation in eqnset.js for all three spring types.

[1fifoto]

merged into master, closing