Adopt broadcast mechanism into CAPE-OPEN

[bcbooo]

Google Android system has an useful mechanism named Broadcast, for example, when you turn off the screen the system will send out a message, then any module could receive this message, then the module could do something if he needs.

----------------------------------

The simulators who adhere to CAPE-OPEN have some shortages, for example, user has selected some compounds(for example SC) in a unit operation module as the reactant compounds , then user changes the SC name in compound selection window. For Aspen Plus and other simulators, UO could change the SC name automaticly in this UO; But for CAPE-OPEN, the simulator just could call the Invalidate() method of this UO, then UO check the compound list, then he doesn't know whether compound name changed or compound list changed, then this UO what only could do is remove SC from reactant compounds. This is not rational.

So here I advise CAPE-OPEN adds two new interfaces named ICapeBroadcastSender and ICapeBroadcastReceiver, for example Simulator fufills ICapeBroadcastSender and UO fulfills ICapeBroadcastReceiver, when compound name changed, Simulator could tell UO compound name changed; when compound removed, Simulator could tell UO compound removed, then UO could do something refer to specified broadcast message.

[jasper]

A CAPE-OPEN unit operation must be re-validated prior to running after any thermo change, including renaming a compound.

It is advised (but alas not required) to have (material-) objects connected to ports to be functional during a call to Edit, so that also at that point a unit operation can re-obtain information like compound names, etc.

A generic event handling system is not currently present in CAPE-OPEN, nor would it likely be implemented by a number of simulators, as they lack the internal structure to fire such events. In addition, the event would have to come with additional information (this particular compounds got renamed to that particular name), otherwise such a system would not carry additional value over the unit operation re-checking things like compounds lists on Validate.

[bcbooo]

Sorry Jasper I don't agree with you. Broadcast interfaces will be independent with other interfaces, have no negative effect on current CAPE-OPEN interfaces. Simulator is responsible for sending out events, and specified modules just listen to it. The current interface standard UO and other modules still could run well in new standard simulators.

It's not difficult to define events, I prefer to divide events into different classes, like the following:

(1) Compound Messages.

Code Id: CAPE_EventMsg_Compound.

Subclass message Id list:
1- One of the compounds changes it's name, please care here just one compound changes it's name. Then UO receives this event, and compares old compound list with new compound list, to check which one compound's name changed, it's very easy. If multi compounds changed their name, should send out this event once when each compound name changed.

2- Remove one of the compounds. Similiar with compound rename.

3- Add one new compound.


(2) Run Control Messages.

Code Id: CAPE_EventMsg_RunCtrol.

Subclass message Id list:
1. Return to initial status, clear all cache datas.

2. Return to initial status, but still use all cache datas.

2. Input value changed after a successful calculation.

(3) Reaction Messages.

Code Id: CAPE_EventMsg_Reaction.

Subclass message Id list;
1. One of the reactions changed it's name.

2. Remove one of the reactions.

3. Add a new reaction.

4. One of the reactions adds/removes a kinetic equation.

And so on.

[jasper]

Messaging has been discussed on several occasions within the various SIGs. The same conclusion is reached each time: it is not likely that main stream simulators will provide support for this, as they lack the internal machinery. Consider this scenario: the PME uses an external property package. The user edits it. The user deletes one compound, adds an other and renames a third one. Only after the PME is done control returns to the PME. How is the PME supposed to break this up in individual events that describe what actually happened? It cannot reasonable be expected to distinguish the delete + add compound from a rename compound (in addition compounds may have been re-ordered).

If there is no guarantee the PME will support this, the PMC cannot depend on such a mechanism.

And, as mentioned, I do not see the added value over re-obtaining the compound list each time Validate is called - which is the current mechanism.

[bcbooo]

Hope in the next CAPE-OPEN version, Simulator could achieve the IBroadcastSender interface, and Property Package and UO could achieve the IBroadcastReceiver interface, then all the modules could communicate better.

The following picture shows how the broadcast mechanism works. The Property Package holds the IBroadcastSender of Simulator, and simulator holds the IBraodcastReceiver of Property Package; UO is similiar. IBroadcastSender has a method named ReSendMessage(int msgCode), and IBroadcastReceiver has a method named ReceiveMessage(int msgCode). When a compound's name in Property Package changed, Property Package could send out a message by ReSendMessage() of IBroadcastSender of Simulator, then Simulator re-send out this message by ReceiveMessage() of IBroadcastReceiver of other modules.

At the current CAPE-OPEN specifications this mechanism is not possible, but I hope the next version will take this mechanism into consideration.

[img]broadcast.jpg[/img]