additional nonlinear equation in fluid flow models

[mwetter]

@Mathadon Your commit 4473487 causes
the test cases

Annex60_Fluid_Actuators_Dampers_Examples_Damper.txt
Annex60_Fluid_Actuators_Dampers_Examples_VAVBoxExponential.txt
Annex60_Fluid_Actuators_Valves_Examples_TwoWayValves.txt
Annex60_Fluid_FixedResistances_Examples_FixedResistancesSeries.txt

and various others to have more nonlinear equations than before.

This needs to be looked at and corrected or we need an explanation for why there are nonlinear equations that have not been present before.

[mwetter]

A simple model to check is Examples.Damper. This leads in dsmodel.mof to

  // Nonlinear system of equations
  // Nonlinear system of equations number = 2.
    // It depends on the following parameters: 
    //   res.dp
    //   res.m_flow_turbulent
    // It depends on the following timevarying variables: 
    //   res.kDam
    // Start values for iteration variables of non-linear system of 1 equations: 
    //   res.port_a.m_flow

  equation // Residual equations
    0 = res.dp-smooth(2, smooth(2, (if noEvent(res.port_a.m_flow > 
      res.m_flow_turbulent) then (res.port_a.m_flow/res.kDam)^2 else (if noEvent
      (res.port_a.m_flow <  -res.m_flow_turbulent) then  -(res.port_a.m_flow/
      res.kDam)^2 else 0.5*(res.m_flow_turbulent*res.port_a.m_flow+
      res.port_a.m_flow^3/res.m_flow_turbulent)/res.kDam^2))));
  // Analytic Jacobian was produced, but it is not listed here.
  // To have it listed, set
  //   Advanced.OutputModelicaCodeWithJacobians = true
  // before translation. May give much output,
  // because common subexpression elimination is not activated.
  // End of nonlinear system of equations

This section was eliminated earlier. Note also the smooth(2, smooth(2, ... which is wrong.

The best translation statistics for the damper test case is obtained with

LateInline=true,
smoothOrder=2,

Note that using smooth in the algorithm section causes Dymola to not simplify the model for the initialization problem.

[Mathadon]

This is as expected. See my comment in #279

However, when using Inline=true the function will always be inlined and therefore the function's inverse will not be used, where this may otherwise be possible (i.e. only for non-linear systems of 1 equation as far as I know).

This can be 'fixed' by switching from_dp in the component causing the non-linear system.

Is this a sufficient explanation?

[mwetter]

@marcusfuchs
Can you please address the fixme that I added to

/Fluid/BaseClasses/FlowModels/Validation/SecondDerivative.mo
/Fluid/BaseClasses/FlowModels/Validation/FirstDerivative.mo
/Fluid/BaseClasses/FlowModels/Validation/FlowFunctions.mo

The problem is that depending on the value of from_dp, only one of the implementations is tested.
I added tests for both branches in Inverting* and in BasicFlowFunction_{m_flow,dp}_DerivativeCheck{2}.mo. The latter also checks the second order derivatives for an input signal that has a non-zero second order derivative.

I am fine with removing FirstDerivative, SecondDerivative and FlowFunctions as these tests are now implemented in smaller unit tests that provide full coverage. If you like to keep them in the library, it would be good to address the from_dp so that the validation tests both settings.

Once this is address, I (or you) can issue a pull request towards the master. I updated all reference results and the implementation is from my point of view ready to be merged.

[mwetter]

Closed as this is now on the master.