Hooke's Law Only

[grumpyinca]

There are (at least) two different approaches to implementing a Hooke's Law Only feature:

1. Implement a separate Hooke's Law Only model for each of the spring design types
   • A mechanism to transfer values from and back to the full model would be desirable
2. Implement execute script(s) to modify the existing spring model(s) to disable default constraints and hide the undesired variables
   • Script(s) to reverse the process would be appropriate

This issue covers approach #2 - experiments to see what changes are required to have an execute script modify a model. The script will need to disable constraints and hide all aspects of the design model that go beyond Hooke's law. The notion is to determine if an execute script could enable Hooke's Law Only. A corresponding script could re-enable constraints and un-hide variables in order to return to normal behavior.

The only thing remaining should be forces, deflections, lengths and rate. No material properties, end type, wire diameter, coil diameters, number of coils, stresses, factor of safety or cycle life, etc. Specifically, the variables to be retained include:

• L_Free
• Force_1
• Force_2
• Rate
• Deflect_1
• Deflect_2
• L_1
• L_2
• L_Stroke
• Energy (optional)

Experiments can be done by customizing initialState. What capabilities (like hide / unhide) need to be added to the execute feature ? Are changes to Calculator View, Reports and Alerts required ? Does this approach provide a clean implementation or are there operational issues that come from the baggage of the larger implementation ?

[grumpyinca]

Advanced View

Question: I don't understand why the following CalcInput values continue to appear when marked as "hidden": true in initialState:

• Material_Type
• ASTM/Fed_Spec
• Process
• Life_Category
• %_Tensile_Endur
• %_Tensile_Stat

Calculator View

All values appear. Perhaps it would be expedient to simply disable Calculator View for the Hooke's Law Only feature. One possible approach would be to remove Calculator View from the View menu.

Reports

All values appear. See comment above about disabling the View.

Alerts

Changing values triggers alerts that refer to hidden variables. It appears that the Alerts facility would need to be made sensitive to the operation of Hooke's Law Only.

[grumpyinca]

Is it possible that implementing a Force-Deflection chart would be more effective / preferable to implementing a Hooke's Law Only feature ?

[1fifoto]

Re: "I don't understand why the following CalcInput values continue to appear when marked as "hidden": true in initialState: Material_Type, ..." It is because the init.js routine for different PROP_CALC_METHOD sets the hidden/visible flag in the code. See compression spring's init.js line 139 for PROP_CALC_METHOD = 1.

[grumpyinca]

Today's discussion of this issue highlighted a number of points.

The alternative of implementing a Hooke's Law Only feature as a View similar to the existing Calculator View was considered and rejected because a View should not make changes to the model. The current spring design types rely on computing Rate from the physical parameters (Wire_Dia, OD_Free & Coils_T). A Hooke's Law Only feature would get Rate as an independent variable or from the force / deflection specifications.

The Hooke's Law Only feature was considered a good match for the sub-problem notion that currently appears as disabled on the View menu. The design article Sub Problems provides some of the original thinking behind sub-problems. Also, see #170.

Sub-problems should be named. A possible set for coil springs might include:

• All (all sub-problems active = the current model)
• Physical (includes Wire_Dia, OD_Free & Coils_T)
• Force - Deflection (previously referred to as Hooke's Law Only)
• Stresses (a.k.a. "Other"; includes factor of safety)

The role of the rate equation has become a bit of a sticking point in visualizing how to implement sub-problems in coil spring design. Specifically, the current spring design types rely on computing Rate from the physical parameters (Wire_Dia, OD_Free & Coils_T). A Force - Deflection sub-problem (Hooke's Law Only feature) would get Rate as an Independent Variable, Calculation Input or from the force / deflection specifications.

The idea of "precedence" in sub-problems was considered. Specifically, a Fix on Rate could be a bridge to carry the result of work on the "Force - Deflection" sub- problem into the "All" sub-problem.

The idea of implementing a stand-alone "Hooke's law only" (approach #1 above) design type as a learning experience was mentioned.

[1fifoto]

Split 792 branch into two other branches.

• 792.1 creates a reduced/simplified initialState which only has L_Free, Force_1, Force_2, Rate, Deflect_1, Deflect_2, L_1, L_2, and L_Stroke based upon the topmost comment of this issue. This was done by BDW,
• 792.2 modified the initialState to hide all non-Hooke's Law symbol table entries except for L_Free, Force_1, Force_2, Rate, Deflect_1, Deflect_2, L_1, L_2, and L_Stroke. This was done by MKM.

The current 792 branch (the one without a suffix) is atrophied at the point this split took place. Later it can be used as a point to re-merge in either 792.1 or 792.2 branch if needed.

[grumpyinca]

From January 22, 2023 Slack conversation: "I have merged all changes from 792.1 into 792. I have deleted 792.1.eval and 792.2."

Testing of the current state of the update branch 792 is in progress. Today's discussion touched on a few missing pieces:

1. Are variations for extension (includes initial tension) & torsion (moment units) necessary ?
2. A Force - Deflection chart.
   See #466.
   Should that work be merged into this issue & branch ? Should the chart be placed on the Calculator View or in a separate tab ?
3. An improvement to the existing placeholder icon
4. Alerts
5. Documentation, including a description page
6. Specs for "bridging" (mechanism to transfer values from and back to the full model).
   Implementation of this mechanism may be delayed until a subsequent release.

[1fifoto]

Based upon comment 1 "Are variations for extension (includes initial tension) & torsion (moment units) necessary ? " in the above comment - this means we need to create three submodel directories for compression, extension and torsion.

[1fifoto]

Somehow a comment I made is missing...

Repeating myself: re: Item 1 above. I have updated the Hooke's Law model by adding subdirectories: Compression, Extension and Torsion. I have copied the Compression files into the new Extension and Torsion directories and made string and naming changes. The Compression Hooke's Law should work, but the Startup file in the DB must be recreated.

Now back to our regular programming...

New: I need help with creating the models for Extension and Torsion. Presently they are copies of Compression and need to be updated to be unique to Extension and Torsion. As part of this, new icons for Compression, Extension and Torsion need to be created.

[1fifoto]

Screen shot of calculator

[1fifoto]

[1fifoto]

Latest screen shot

[1fifoto]

Adding constraints to the force-deflection graph.

Tried use gray areas (Recharts' <RectangularArea> component) to define the infeasible bounds. This encountered problems when Force_1 and Force_2 both have overlapping constraints.

Next tried using error bars (Recharts' <ErrorBar> component). There is a different error bar at Force_1 versus Force_2 which do not conflict. This seems to work better.

Screen shot with error bars. Note: There is a problem with displaying horizontal error bars for deflection that needs to be solved.

Things that still need to be done or solved.

1. Fix deflection error bars from vertical to horizontal.
2. Add checks for enabled constraints and skip error bars for disabled ones. Do this separately for min and max constraints.
3. Add Length error bars.
4. Upon loading a model the graph does not update to show the error bars.
5. The color of the error bars should match the color of the axis (for example defection error bars should match the color of the deflection axis, length error bars to length axis, etc.)
6. Copy all changes into Force-Deflection View #466. OR Consider adding this graph to Compression/Extension/Torsion Spring Calculator.
7. Consider adding a rectangle showing constraints by visualizing the deflection width and force height as a gray area.