SysML4Mathematica: Example 05: Sensible heating: 'qSen' (+ve): energy transfer TO humid air

Click on the image to view it full size

At the top we see a SysML Parametric Diagram representing a network of equations for the psychrometric properties obtained from low-level CoolProp wrappers for Mathematica, and a `Psy` library function for calculating the sensible heat in the case where there is no exchange of water. Note how the humidity ratio 'w' for calculation of 'hda2' (for State2) is bound to the humidity ratio 'w1' of initial state State1, because the water vapour content does not change.

In the middle and bottom Activity Diagrams we see how the problem can be setup instead using Webel `MPsy` objects, which encapsulate the lower level CoolProp calls. Together, they represent this Mathematica invocation:

``````
ex5\$psy1 = newPsy[asDegF[85], \$opt\$psy\$twb -> asDegF[75]];

psy\$qSen[
ex5\$psy1,
asDegF[100],
100 unit\$lb,
\$opt\$psy\$doShowAsIP->True
]

371.80468520770614 Btu
``````

Here `unit\$lb` is a pre-built Mathematica `Quantity[1.0, "Pounds"]`, and `asDegF` similarly creates a Quantity for °F.

The option directive `\$opt\$psy\$doShowAsIP->True` specifies that the return value should be a Quantity in Imperial Units (IP):

Note how in the Activity for function `psy\$qSen` the pressure 'p' and humidity ratio 'w' for object `psy2` are supplied by `psy1`.

Note also that:

So it does not matter that the temperatures are supplied here in °F and the sea-level atmospheric pressure is supplied in Pa.

If you are not a SysML expert please proceed to the next slide page.

For the SysML Experts

You may have noticed that the diagrams image shows modelling of a lower level approach using SysML Parametric Diagrams, but the `MPsy` approach (using MTools classes represented as SysML Blocks) uses SysML Activity Diagrams. To learn why, visit this explanation (then do come back):

This can, however, lead to maths maintenance issues across a model:

For example, the 'constraint' for `psy\$E\$HC\$qSen` as a ConstraintBlock and the 'body' for `psy\$E\$HC\$qSen` as an OpaqueBehavior are repeated in the model:

``qSen = m\$da * (hda2 - hda1)``

Changes to that equation in the ConstraintBlock don't propagate to the OpaqueBehavior (or vice-versa). But there is a workaround thanks to support for integration of Mathematica and Magic Model Analyst® (Cameo Simulation Toolkit®):

So both the ConstraintBlock `psy\$E\$HC\$qSen` and an OpaqueBehavior `psy\$E\$HC\$qSen` could just call the same function via Mathematica as:

``````
qSen = psy\$E\$HC\$qSen[m\$da,hda1,hda2]
``````

This is, however, not done in this tutorial, because the aim is to show how to model them directly in SysML (otherwise readers would not be able to see the actual formulae easily, although one could include screenshots of the function output from a Mathematica notebook).

You may also have noticed that not every InputPin on the CallBehaviorAction usages of the `newPys` Activity are connected, and some are greyed out. This is because only one of the options for 'w', 'r', or 'twb' are required (or allowed), and the optional pressure 'p' defaults to sea level atmospheric pressure. The custom stereotype keyword «MMA:opt» indicates that Mathematica options are used for these in the corresponding `newPsy` Mathematica function:

Notes
Snippets (quotes/extracts)