Manually specifying an inverse link

[niveK77pur]

Problem

An inverse link is theoretically not required to be manually defined because the absolute value of the heat exchange is identical in both directions. The thermalmodel.py's _addInterfaceLinks() method takes care of this and generates an inverse link automatically for you.

However, what to do when an inverse link happens to be defined manually? Either by mistake or intentionally? You will see that it impacts the numbers being produces, so this needs to be taken care of.

Solution

The solution will most likely be happening inside thermalmodel.py's _addInterfaceLinks() method.

You will find the givenLinks variable here, which simply keeps track of any links that were provided in the model description. Any link in this list will have its inverse link generated. This variable is most likely what will allow implementing the solutions.

Brute force

Before creating the link, check in the list of links if the inverse link is already present. If it exists, throw an error to inform the user that the link already exists (and that the inverse link has automatically been generated).

More concretely, if the link ( (nameHSN, nameIFN), (nameTargetHSN, nameTargetIFN), nameLink1 ) is being created, ensure that ( (nameTargetHSN, nameTargetIFN), (nameHSN, nameIFN), nameLink2 ) doesn't exist yet.

NOTE: nameLink1 and nameLink2 are not relevant for this and should not be considered. We are only interested in the link itself, not what label it has attached.

Graceful

We do the same as in the brute force method. Instead of throwing an error however, we create the link, but remove its inverse from the list of givenLinks. Removing a link from this list will effectively avoid the creation of an inverse link.

Let the user specify how to handle this

Ideally, one would implement both solutions. A setting could be specified by the user to indicate how to handle explicit definition of inverse links. Let the user specify if they want an error to be raised, or if the inverse link shall be explicitly defined.

Default behaviour of raising an error seems like the better choice to avoid unintentional mistakes.