Grey-box Models

This article is about planned development or proposed functionality. Comments welcome.

The idea of 'grey-box' models would be to give some way in which complicated sub-models could be expressed with intermediate variables, without needing to change the system's higher-level structure.

To some extent this is like explicit 'tearing' of the system of equations, as it delimits a block in which any internal variables must be solved before the higher-level system gets to see the remaining variables referenced by that block.

The current ASCEND system for dealing with 'black box' elements would be a suitable API for allowing the solver to deal with these, hence the name 'grey box': the modeller can see the equations but the top-level solver can not, and must deal with the equations as though they were a black box.

Example

Perhaps we wish to solve a problem involving the radius of a circle

<math>r= \sqrt{x^2+y^2}</math>

We could just write

MODEL circle;
  x,y,r IS_A solver_var;

  r_eq: r = sqrt(x^2 + y^2);

MODEL;

but what if that r_eq were more complicated. Perhaps then we would like to write it separately and include some intermediate values in the calculation:

MODEL radius;
  x,y,r IS_A solver_var;

  x2,y2 IS_A solver_var;
  x2 = x^2;

  y2 = y^2;
  r = x2 + y2;

END radius;

MODEL circle;
  r_grey IS_A radius;

  GREY(r_grey,'QRSlv');
END circle;

The GREY(r_grey) statement would add the instance of type radius to the 'grey' list for the present model. When the problem analysis phase came along, the grey model would be found and encapsulated as a sub-model using the external libraries technique of 'black box', but instead of arbitrary black box code, the encapsulation would be of a sub-model solved using the QRSlv solver (in this case -- as specified).

The GREY statement would simply be an specialisation of the proposed LINK statement.