noDerivative annotation not used according to spec

[modelica-trac-importer]

Reported by jmattsson on 18 Mar 2013 15:25 UTC Ch 12.7.1 of the current working revision of the 3.2r2 spec (as well as 3.3) says the following about noDerivative:

---

• noDerivative(input_var2 = f(input_var1, ...) ) The derivative function is only valid if the input argument input_var2 is computed as f(input_var1, ...). The derivative of input_var2 is excluded from the argument list of the derivative-function. [Assume that function fg is defined as a composition f(x, g(x)). When differentiating f it is useful to give the derivative under the assumption that the second argument is defined in this way:

  
  function fg
  input Real x;
  output Real z;
  algorithm 
  z := f(x, g(x));
  end fg;

function f input Real x; input Real y; output Real z; annotation(derivative(noDerivative(y = g(x))) = f_der); algorithm ... end f;

function f_der input Real x; input Real x_der; input Real y; output Real z_der; algorithm ... end f_der;

This is useful if g represents the major computational effort of fg.]

----

Quite apart from this definition being messy and hard to read, all uses of this annotation in the MSL are instead on the form noDerivative=y.

Uses in MSL:
 * Modelica
  * Blocks
   * Sources.mo (2 matches)
    * 1 738: annotation (derivative(noDerivative=q_qd_qdd) = position_der,  
    * 1 751: annotation (derivative(noDerivative=q_qd_qdd, order=2) = position_der2,  
  * Mechanics
   * MultiBody
    * Frames.mo (4 matches)
     * 131: annotation (derivative(noDerivative=R) = Internal.resolve1_der,  
     * 142: annotation (derivative(noDerivative=R) = Internal.resolve2_der,  
     * 156: annotation (derivative(noDerivative=R1, noDerivative=R2) = Internal.resolveRelative_der,  
   * Rotational.mo (2 matches)
    * 5 109: annotation (derivative(noDerivative=q_qd_qdd) = position_der,  
    * 5 123: noDerivative=q_qd_qdd,  
   * Translational.mo (2 matches)
    * 3 757: annotation (derivative(noDerivative=q_qd_qdd) = position_der,  
    * 3 770: annotation (derivative(noDerivative=q_qd_qdd, order=2) = position_der2,  
  * Media
   * Water
    * IF97_Utilities.mo (10 matches)
     * 967: derivative(noDerivative=bpro) = hvl_p_der,  
     * 1 022: derivative(noDerivative=bpro) = rhovl_p_der,  
     * 6 468: derivative(noDerivative=properties) = rho_ph_der,  
     * 6 518: annotation (derivative(noDerivative=properties) = T_ph_der,  
     * 6 566: annotation (derivative(noDerivative=properties) = s_ph_der,  
     * 6 927: derivative(noDerivative=aux) = rho_pT_der,  
     * 6 954: derivative(noDerivative=aux) = h_pT_der,  
     * 7 335: derivative(noDerivative=aux) = h_dT_der,  
     * 7 383: derivative(noDerivative=aux) = p_dT_der,  
     * 7 806: annotation (derivative(noDerivative=aux) = isentropicEnthalpy_der,  

----

Migrated-From: https://trac.modelica.org/Modelica/ticket/1035

[modelica-trac-importer]

Comment by hansolsson on 18 Mar 2013 15:40 UTC This was discussed before adding it to the specification.

The form used currently in MSL is that it does not work reliably. You just tell the Modelica translator to ignore some variables when differentiating for no clear reason.

With the form in the specification you state that you ignore variables under certain conditions, and allow the Modelica translator to verify this. Compare with zeroDerivative which clearly state that the variables have zero derivative.

If you look at a typical use case you have:

function h_dT 
...
algorithm 
  h := h_props_dT(d, T, waterBaseProp_dT(d, T, phase, region));
end h_dT;

function h_props_dT 
...
algorithm 
  h := aux.h;
  annotation (
    derivative(noDerivative=aux) = h_dT_der);
end h_props_dT;

-- Thus it seems this ticket is for MSL instead; and as indicated it is possible to find those expressions in most cases.

[modelica-trac-importer]

Comment by jmattsson on 18 Mar 2013 16:02 UTC I have no opinion of where it should be fixed (MSL vs spec).

However, it would probably be a good idea to update the text in the spec to at least allow several inputs to be listed in noDerivative, and perhaps to allow a general expression instead of a function call with at least one input, as it is now.

[modelica-trac-importer]

Comment by hansolsson on 18 Mar 2013 16:42 UTC I looked more closely at the non-Media cases.

They are more problematic, both the ones that use q_qd_qdd (the relation is given by an equation instead) and the ones in Mechanics.MultiBody.Frames (the noDerivative apply to all R-records provided they satisfy the precondition that skew(R.w)=R.T*der(transpose(R.T)); and if that is not satsified everything breaks - however, there is no common formula for R).

The simplest solution would be to allow the "noDerivative=R" as well, and state that it is dangerous, and the other variant should be used if possible. (And of course that multiple noDerivative are allowed, and they must all be satisified.)

[modelica-trac-importer]

Comment by jmattsson on 19 Mar 2013 09:21 UTC Additionally, in all the examples in 12.7 and 12.8 with both annotation and algorithm, the annotation is before the algorithm (and not last in the class as the spec now requires).

[modelica-trac-importer]

Comment by jmattsson on 12 Apr 2013 09:17 UTC Updating to blocker since it concerns an incompatibility between MSL and the spec.

[modelica-trac-importer]

Comment by otter on 18 Apr 2013 17:02 UTC Had a look at Modelica.Blocks.Sources.KinematicPTP2:

Here, a simple optimization problem is solved analytically and the result is s, v=der(s), a=der(v) and all three variables are computed analytically. Via the noDerivative annotation this information is reported to the tool.

In this case, this is not necessary. I rewrote the code so that "s" is computed and the tool computes v and a by differentiation. In Dymola the generated code is identical to the previous (noDerivative) version. So, there is no efficiency issue. The code has been committed in r6265. Additionally, a test model in ModelicaTest has been extended to test the new implementation with another implementation (KinematicPTP with two integrators).

[modelica-trac-importer]

Comment by otter on 19 Apr 2013 06:33 UTC Had a look at the cases in the Rotational and Translational library:

Modelica.Mechanics.Rotational.Sources.Move, Modelica.Mechanics.Translational.Sources.Move

The goal of the Move blocks is to move a flange according to a predefined motion, given s (position), w (speed), a (acceleration). There are two applications:

1. In an external program the motion is computed (e.g. a path planning program for a robot). The result might be provided as linearly interpolated tables on s,w,a, level. So the relationship between s,w,a is only approximately fullfilled.
2. Only certain terms of a differential equation shall be computed. For example, a multi-body system is described by M(q)*qdd + h(q,qd) = u. If only the mass matrix M shall be computed then this can be performed by moving the joints according to the predefined motion q=q(t), qd=0, qdd=unit-vector. Then the i-th column of M is computed by providing the i-th unit vector to qdd and computing u. In this application, q,qd,qdd are by purpose not consistent to each other.

To summarize, for the Translational and Rotational library it is a must that the noDerivative annotation can be used as defined in the MSL, because otherwise some existing applications at DLR and other organizations would no longer work.

[modelica-trac-importer]

Comment by otter on 19 Apr 2013 06:38 UTC Unfortunately, I do not yet understand the definition of noDerivative in the specification, chapter 12.7.1. Especially, I also do not understand the example given in this chapter. I think, the developers of this annotation should explain the specification and the example more clearly.

[modelica-trac-importer]

Comment by otter on 19 Apr 2013 06:46 UTC Replying to [comment:3 hansolsson]:

I looked more closely at the non-Media cases.

They are more problematic, both the ones that use q_qd_qdd (the relation is given by an equation instead) and the ones in Mechanics.[wiki:MultiBody].Frames (the noDerivative apply to all R-records provided they satisfy the precondition that skew(R.w)=R.T*der(transpose(R.T)); and if that is not satsified everything breaks - however, there is no common formula for R).

The simplest solution would be to allow the "noDerivative=R" as well, and state that it is dangerous, and the other variant should be used if possible. (And of course that multiple noDerivative are allowed, and they must all be satisified.)

Note, the record R has the two components T (transformation matrix) and w (angular velocity). The trick is to propagate both R and w through all connections and calculate both recursively. The cleanest way would be to only propagate R and compute w with the formula: skew(w) = T*der(transpose(T)). However, this computation is very unefficient and a tool has no chance to transform the resulting equations to the very efficient form where w is computed recursively (w(body_i) = w(body_i-1) + w(relative)). Therefore, here the noDerivative annotation is  used to enhance considerably the efficiency. However, it is not practical to state the relationship between T and w in this annotation, since a tool can most likely not figure out symbolically that the two expressions (recursive relations versus formula above) are the same.

Therefore, the only way seems to be to define the noDerivative annotation as in the MSL.

I have to say that I do not understand the Medium appliciations of noDerivative. Especially, I do not understand whether it is possible to rewrite the noDerivative annotation in the safer form as defined in the Modelica specification. If this is not possible, one should eventually ONLY define the noDerivative annotation according to the usage in MSL.

[modelica-trac-importer]

Comment by hansolsson on 19 Apr 2013 13:17 UTC The sub-parts of the derivative indicate various forms of assumptions the modeler make.

The zeroDerivative indicate that some argument usually has zero derivatives; and that the differentiation of the function is made under that assumption. If the assumption is false the function itself is still valid, but we cannot use the derivative.

So what about the noDerivative – what is the assumption, and what happen if it is false?

For the Medium cases one typical case is:

function h_dT 
...
algorithm 
  h := h_props_dT(d, T, waterBaseProp_dT(d, T, phase, region));
end h_dT;

function h_props_dT 
...
algorithm 
  h := aux.h;
  annotation (
    derivative(noDerivative=aux) = h_dT_der);
end h_props_dT;

This derivative is here only valid if aux=waterBaseProp_dT(d, T, phase, region) – anything else indicates that the function is used incorrectly. A tool could potentially verify that aux was computed in this way – except that h_props_dT lack some arguments.

Note that if aux has another value it is as far as I understand a modeling error, e.g. h_props_dT(d1, T1, waterBaseProp_dT(d2, T2, phase, region)) is just wrong – even if we do not differentiate it.

It is similar for the ones with properties – for the ones with bpro it is more complicated, since the formula is correct both if bpro is given by the boilingcurve and the dewcurve. One solution would be to have two different hvl_p variants.

Thus the Media-library could use the aux=... variant after some minor changes in the library (the changes are in lower level functions; and ideally this should not influence users).

So in conclusion:

• Variants with q_qd_qdd: – not possible to verify; need to trust end-user.
• Use of R – very difficult to verify; need to trust modeler.
• Use in Media-library; straightforward to describe (after some changes) – might be verified.

Thus if we want to have both forms of noDerivative I would propose:

noDerivative=input_var2 or noDerivative(input_var2=f(input_var1)) The derivative of input_var2 is excluded from the argument list of the derivative-function (if there are multiple noDerivative elements all arguments are excluded). The second variant indicates that the function (and its differentiation) is based on the assumption that input_var2=f(input_var1).

Skipping the 2nd variant is also possible; and we could then later think of having some other mechanism for specifying assumptions. (Assertions are not appropriate due to issues with floating point precision etc.)

[modelica-trac-importer]

Comment by jmattsson on 4 Jun 2013 08:55 UTC Needs decision for spec to match MSL.

[modelica-trac-importer]

Comment by hansolsson on 4 Jun 2013 16:12 UTC Conclusion: Change specification to be consistent with MSL.

State that this relies on assumptions on the call of the function (regardless of whether it is differentiated or not); and that the function should document these assumptions.

We might later add some form of assumption-checking in function. -- Seems to be agreement.

[modelica-trac-importer]

Comment by hansolsson on 5 Jun 2013 13:32 UTC Added in r6604