Webel: SysML4Mathematica: POLICY: Handle flow sign changes via a single negative (not duplicated and "adjusted" algebra). This strategy may come at a very slight performance cost (for benefit of more robustness).

Webel IT Australia promotes the amazing Mathematica tool and the powerful Wolfram Language and offers professional Mathematica services for computational computing and data analysis. Our Mathematica tips, issue tracking, and wishlist is offered here most constructively to help improve the tool and language and support the Mathematica user community.
DISCLAIMER: Wolfram Research does not officially endorse analysis by Webel IT Australia.
Icon class
far fa-sticky-note
far fa-sticky-note
Note kind
Policy level
Specification keywords
UML keywords
SysMLv1.x keywords
Click on the image to view it full size

This policy for the Webel Psy library for Psychrometrics (humid air physics) in Mathematica is very easy to apply in the Wolfram Language code (indeed much easier than not applying it), and comes only at a very slight performance cost, for a great advantage in robustness. From the point of view of the SysML modelling for SysML4Mathematica it involves a bit more lower-level modelling fuss, but is still worth doing, and makes higher level SysML modelling easier (and more robust).

From the Mathematica code point of view

Consider this Psy library Mathematica code for rate of water vapour added TO humid air going from a State1 with humidity ratio 'w1' and State2 with humidity ratio 'w2', and with 'mDot$a' the mass flow rate of the dry air portion ("fraction"):

psy$E$mDot$wat$i[mDot$a_,w1_,w2_] := mDot$a (w2 - w1);

For the convenience of coding and modelling at higher levels (and to avoid having to use negation at higher levels), a version of the function that gives the mDot$wat$o (out) could be used. It might be tempting to implement such by just reversing the 'w1' and 'w2' as:

psy$E$mDot$wat$o[mDot$a_,w1_,w2_] := mDot$a (w1 - w2);

But what if there was an error in the rest of the formula in the above approach? You'd have to change the algebra for some reason (and potentially fiddle with the signs also) in 2 separate places, which does not respect [util: ssot_dry_]. It is also more error prone.

The policy described here, however, advocates that - given we already have mDot$wat$i - the mDot$wat$o should be implemented instead with reuse by introducing simple numerical negation without any more algebra:

psy$E$mDot$wat$o[mDot$a_,w1_,w2_] := 
 - psy$E$mDot$wat$i[mDot$a,w1,w2];

For this very simple case it might not seem to be such a big deal, but it pays off for more complex systems.

From the SysML modelling point of view

For reasons described here (a better way using Mathematica as external maths engine is given here), each Mathematica function is encapsulated in the SysMLv1.x model as both a ConstraintBlock and a Behavior, preferably as a simple OpaqueBehavior with a simple mathematical Constraint given in an opaque language (and requiring no further modelling), or as an Activity.

In the case of the SysML Parametrics approach, a simple ConstraintBlock for psy$E$mDot$wat$i has been used (as a constraint property) in a wrapping and negating ConstraintBlock psy$E$mDot$wat$o together with a usage of a simple ConstraintBlock @neg to perform the flow direction negation. Implementing the wrapping ConstraintBlock psy$E$mDot$wat$o requires modelling of an extra SysML Parametric Diagram, but it's very simple to do.

In the case of the SysML Activities approach, a simple OpaqueBehavior for psy$E$mDotWatIn has been used (via a CallBehaviorAction) in a wrapping and negating Activity psy$E$mDot$wat$o together with a usage of a simple OpaqueBehavior @negQ (that can handle a Quantity) to perform the flow direction negation.

In both cases, there is no need to "repeat and adapt" the formula algebra of the Constraint of the psy$E$mDot$wat$i ConstraintBlock or of the 'body' of the psy$E$mDot$wat$i OpaqueExpression. From the SysML side, it does, however, introduce this small risk:

One has to be careful in the wrapping diagrams that perform the negation not to get parameter wires crossed!

But overall, it's well worth applying this policy strictly. At higher levels of modelling, it quickly pays off.

Relates to
Related notes
Related notes (backlinks)
Related snippets (extracts)
Visit also
Visit also (backlinks)