Improve table design of Modelica.Mechanics.Rotational.Components.Clutch to use static tables instead of dynamic

[christoff-buerger]

Modelica.Mechanics.Rotational.Components.Clutch uses Modelica.Math.Vectors.interpolate() for table interpolation. The used tables are static, i.e., never changed throughout simulation time. But vector-interpolation is meant for dynamic tables – i.e., tables whose content is constructed out of simulated runtime values. I consider this a design bug.

Even more, the parameter mu0 is modeled as a variable. Its equation is

  // Constant auxiliary variable
  mu0 = Modelica.Math.Vectors.interpolate(mu_pos[:,1], mu_pos[:,2], 0, 1);

Thus, the equation itself comments that it is not a real equation, but a constant. It will never change at runtime. It is a static interpolation using a static table.

The logic for deciding the clutch mode is now mingled with table interpolation to define the friction torque tau. The rationale for this design seems to be that the desired abscissa value for the interpolation (the sign for w_rel) depends on the clutch mode; and likewise the ordinate value interpolation result (the sign of tau) depends on the clutch mode:

tau = if locked then sa*unitTorque else if free then 0 else cgeo*fn*(
    if startForward then 
      Modelica.Math.Vectors.interpolate(mu_pos[:,1], mu_pos[:,2], w_rel, 1)
    else if startBackward then 
      -Modelica.Math.Vectors.interpolate(mu_pos[:,1], mu_pos[:,2], w_rel, 1)
    else if pre(mode) == Forward then 
      Modelica.Math.Vectors.interpolate(mu_pos[:,1], mu_pos[:,2], w_rel, 1)
    else 
      -Modelica.Math.Vectors.interpolate(mu_pos[:,1], mu_pos[:,2], -w_rel, 1));

I propose to change this design to ordinary Modelica.Tables.Interpolation1Ds combi-tables, leveraging on the fact that the used interpolation table is static. Doing so will help to generate faster simulation code and clarify the design, making it explicit that static table interpolation is used and due to that only certain values can change.

The following is an alternative design based on combi-tables:

model ClutchNoDynamicTable
  extends Modelica.Mechanics.Rotational.Icons.Clutch;
  extends Modelica.Mechanics.Rotational.Interfaces.PartialCompliantWithRelativeStates;
  extends Modelica.Mechanics.Rotational.Interfaces.PartialFriction;
  extends Modelica.Thermal.HeatTransfer.Interfaces.PartialElementaryConditionalHeatPortWithoutT;

  parameter Real mue_pos[:, 2] = [0, 0.5]
    "[w,mue] positive sliding friction coefficient (w_rel>=0)";
  parameter Real peak(final min = 1) = 1
    "Peak for maximum value of mue at w==0 (mue0_max = peak*mue_pos[1,2])";
  parameter Real cgeo(final min = 0) = 1
    "Geometry constant containing friction distribution assumption";
  parameter Modelica.SIunits.Force fn_max(final min = 0, start = 1)
    "Maximum normal force";

  Modelica.SIunits.Force fn
    "Normal force (fn=fn_max*f_normalized)";
  Modelica.Blocks.Interfaces.RealInput f_normalized
    "Normalized force signal 0..1 (normal force = fn_max*f_normalized; clutch is engaged if > 0)"
    annotation (Placement(transformation(
      origin = {0,110},
      extent = {{20,-20},{-20,20}},
      rotation = 90)));

protected 
  final parameter Real mue0 = Modelica.Math.Vectors.interpolate(
    mue_pos[:,1],
    mue_pos[:,2],
    0,
    1)
    "Friction coefficient for w=0 and forward sliding"
    annotation(Evaluate = true);

  final Real table_signs[2]
    "Signs for sliding friction coefficient table interpolation:
     1: sign for table.y
     2: sign for table.u = w_rel";
  final eFMI.Tables.CombiTable1Ds table(
    table = mue_pos)
    "Sliding friction coefficient table.";

equation 
  // Relative quantities
  w_relfric = w_rel;
  a_relfric = a_rel;

  // Normal force and friction torque for w_rel=0
  fn = fn_max*f_normalized;
  free = fn <= 0;
  tau0 = mue0*cgeo*fn;
  tau0_max = peak*tau0;

  // Friction torque
  table_signs =
    if startForward then 
      {1,1}
    elseif startBackward then 
      {-1,1}
    elseif pre(mode) == Forward then 
      {1,1}
    else 
      {-1,-1};
  table.u = table_signs[2] * w_rel;
  tau =
    if locked then sa*unitTorque
    elseif free then 0
    else cgeo*fn*(table_signs[1]*table.y[1]);
  lossPower = tau*w_relfric;

  end ClutchNoDynamicTable;

This design uses annotation(Evaluate = true) to statically evaluate mue0. It also separates the interpolation sign decisions based on the clutch mode (dynamic) from the interpolation in the static table itself:

// Friction torque
  table_signs =
    if startForward then 
      {1,1}
    elseif startBackward then 
      {-1,1}
    elseif pre(mode) == Forward then 
      {1,1}
    else 
      {-1,-1};
  table.u = table_signs[2] * w_rel;
  tau =
    if locked then sa*unitTorque
    elseif free then 0
    else cgeo*fn*(table_signs[1]*table.y[1]);

The table_signs vector encodes the different modes of harmonizing the interpolation point (w_rel) and interpolation result (tau) with the clutch mode.

I tested this redesign and it is functional equivalent, but non-functional more efficient (at least in Dymola). Considering that Modelica.Math.Vectors.interpolate is an in Modelica implemented function -- and not C code -- this should be not surprising. Note, that the clutch does not leverage on the last index used for interpolation (iLast) to gain any faster lookup (regardless if such would help at all in the first place considering combi-tables are using an efficient binary search to speed-up lookup).