Outstanding issues with the new scaling tools

[dallan-keylogic]

1. Scaling factors for Expressions have been deprecated. I have a system of scaling hints for Expressions available on a branch Scaling hints are available on the scaling_toolbox feature branch.
2. The team decided that the distinction between mutable class attributes scaler.DEFAULT_SCALING_FACTORS and scaler.UNIT_SCALING_FACTORS and their local copies scaler.default_scaling_factors and scaler.unit_scaling_factors should be handled via documentation. This documentation needs to be written.
3. The scaling API doesn't allow us to filter scaler.default_scaling_factors for unused inputs (either because a modeler forgot to perform scaling or because a user wanted to set some default value), nor does it allow us to apply all default scaling factors automatically.
4. The scaling API doesn't give us an easy way to communicate to the user which scaling factors they need to set on their own. On the scaling_toolbox feature branch, we can add entries to the DEFAULT_SCALING_FACTOR` dictionary that either we recommend the user scale a property on their own, or that a user is required to set a scaling factor or else an exception is thrown.
5. In order to do handle property packages of any complexity, we need scaling factors for more than just the state variables, yet the scaling API doesn't give us a method to solicit the user for such scaling factors, and the reliance on CustomScalerBase.propagate_state_scaling prevents us from rolling out such scaling factors in a general manner. The user will be solicited for these scaling factors via the DEFUALT_SCALING_FACTOR dictionary. There is still the problem that the user needs to create a scaler object for their property package, then create a ComponentMap telling every unit model scaler object to use that property package scaler object.
6. Order-of-magnitude scaling for variables is harmful, yet the entire API guides the user towards using it.
7. Scaler objects rely on a ComponentMap to handle submodel scalers. However, this means that, if we want to scale several units in series or parallel in the same way, we need to create fresh component maps for each unit.
8. There is no validation that every submodel scaler in the ComponentMap is called. That means that, if a user were to try to apply the same scaling to several units with the same ComponentMap, the submodel scalers would not be used and the user would not be alerted to this fact.
9. Pyomo currently issues warnings if an element of a scaling suffix is not exported. However, this applies not just to Expressions but also fixed Vars and deactivated Constraints. This means that the user is going to be bombarded with warnings if they use a scaled model during initialization. We could turn off these warnings globally, but that raises the question about why they exist in the first place. Any fix will have to happen from @jsiirola or others on the Pyomo side of things.
10. Presently get_scaling_factor works by getting the parent block's suffix directly and looking for scaling factors set there. However, Pyomo allows for scaling factors for a component to be set in any block. Furthermore, get_scaling_factor returns a value regardless of whether the scaling suffix has been deactivated or not. Also, Pyomo allows the user to set scaling factors for indexed variables/constraints, but if get_scaling_factor is called on a VarData/ConstraintData child of an indexed variable/constraint, no value will be returned. Updating get_scaling_factor to use the Pyomo suffix finder should solve all of these issues.
11. The scaling tutorials encourage the user to set scaling factors on the suffix directly. We should encourage them to use the set_scaling_factor function instead.
12. Related to (7) and (8), submodel scalers cannot be given for indexed Blocks but must instead be given for BlockData children. That means submodel_scalers[m.fs.unit.control_volume.properties_in] = PropertyScaler() results in that property scaler being silently ignored.
13. Scaler objects have config settings for maximum and minimum scaling factors. These config options are necessary to accommodate the autoscaling methods. However, they also silently override user scaling. This is guaranteed to cause problems in PrOMMiS, where variables and constraints need extreme scaling factors when expressed in SI units.
14. Presently, the get_default_scaling_factor method uses the component finder on the component's parent block when screening for default scaling factors. However, this method runs into a problem when we try to scale a submodel's variables. For example, the HeatExchanger1D has both the unit.area variable for the heat exchange area as well as unit.hot_side.area and unit.cold_side.area for the cross sectional area for fluid flow. Right now all of these will look at the default_scaling_factors["area"] entry, when we'd like the latter two to look to default_scaling_factors["hot_side.area"] and default_scaling_factors["cold_side.area"] instead.

[dallan-keylogic]

For the record, (1), (3), (9), and (10) were issues with the old scaling tools too. For (4), the old scaling tools let get_scaling_factors warn the user if no scaling factor was found, but these warning were universally ignored. (2), (5), (6), (7), (8), (11), (12), and (13) are entirely new problems.