Open grumpyinca opened 1 year ago
Question: I don't understand why the following CalcInput values continue to appear when marked as "hidden": true in initialState:
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.
All values appear. See comment above about disabling the View.
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.
Is it possible that implementing a Force-Deflection chart would be more effective / preferable to implementing a Hooke's Law Only feature ?
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.
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:
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.
Split 792 branch into two other branches.
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.
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:
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.
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.
Screen shot of calculator
Latest screen shot
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.
There are (at least) two different approaches to implementing a Hooke's Law Only feature:
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:
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 ?