Broadcast channels are variables that exist on a given object, referred to in the interface as "parent", which means it lives on the objects parent, and "children", which means it is resident on the object itself, and broadcasts to the objects own children). The current implementation has these variables as simple aggregators, that is, if multiple objects broadcast values to the specific channel + variable_name, the broadcasted value will be added to the value of the variable. Note, the variable name is NOT specific to the broadcast channel, in other words, if 2 different broadcast "hub" objects are set up on a given object named "hub1" and "hub2", values broadcast to "hub1" with the broadcast name "Qup", will be added to values sent to "hub2" under the name "Qup". So in this way, the current behavior simply uses separate "hub" objects on a given object as a way of classifying the information coming in, not separating the values that are accumulated by the individual hubs. Future revisions may enable a function that adds a broadcast prefix to the broadcast variable on the hub parent.
Tasks:
[x] Conceptual designs
[x] hsf5 Data Model
[x] JSON import
[x] model handler class
[x] execution rendering
[x] Logging
Conceptual Design
These can be represented as simple "registers" in the hdf5/ts array, with specific hub addresses (resolved to the parent, or the selfs own path in the hdf5)
on preStep(), set these registers to zero: ts["/BROADCASTS/RCHRES_0001/hydroObject/ps_mgd"][step]
anything that sends on the broadcast simply performs an add to the register, i.e.: ts["/BROADCASTS/RCHRES_0001/hydroObject/ps_mgd"][step] += ts["/OBJECTS/OBJECT0001/ps_local_mgd"][step]
Require an existing entry in objects table describing the broadcast hub in preStep() method of any object writing to the broadcast or reading from, in order to avoid errors.
A broadcast send or read only actually requires 2 end points, the source and the destination:
Reads: the source is the broadcast "register", the destination is a variable on the object that is doing the read
Read is an instance of ModelLinkage with type 2 (path to state of the broadcast hub/register to read from)
Sends: the source is the object doing the sending, the destination is the broadcast hub and "register"
send is an instance of ModelLinkage with type 4 - "push to accumulator"
Note: A broadcast "send" must have a corresponding "read" object. In other words, sending broadcast data does nothin unless there is something configured to listen for it.
Class definition
Object Handler
This class will handle:
parsing a JSON array to add this to the model hdf5 database.
writing executable opcode for @njit simulation.
class ModelBroadcast(modelObject):
# is this a read or a send?
broadcast_mode = "send"
broadcast_params = {'Qout': 'Qtrib'}
hub_state_path = "/STATE/RCHRES_001/BROADCAST/[channel_name]" # this should be set at parse w/self.hdf5_expand()
# the local data source if this is "send", the target data source if this is read"
test = ModelBroadcast()
test.broadcast_params = [['ps_refill_pump_mgd', 'wd_mgd'], ['Qout', 'Qtrib']]
# []
# this yields nothing because the object is in "send" mode
Overview
Broadcast channels are variables that exist on a given object, referred to in the interface as "parent", which means it lives on the objects parent, and "children", which means it is resident on the object itself, and broadcasts to the objects own children). The current implementation has these variables as simple aggregators, that is, if multiple objects broadcast values to the specific channel + variable_name, the broadcasted value will be added to the value of the variable. Note, the variable name is NOT specific to the broadcast channel, in other words, if 2 different broadcast "hub" objects are set up on a given object named "hub1" and "hub2", values broadcast to "hub1" with the broadcast name "Qup", will be added to values sent to "hub2" under the name "Qup". So in this way, the current behavior simply uses separate "hub" objects on a given object as a way of classifying the information coming in, not separating the values that are accumulated by the individual hubs. Future revisions may enable a function that adds a broadcast prefix to the broadcast variable on the hub parent.
Tasks:
Conceptual Design
ts["/BROADCASTS/RCHRES_0001/hydroObject/ps_mgd"][step]
ts["/BROADCASTS/RCHRES_0001/hydroObject/ps_mgd"][step] += ts["/OBJECTS/OBJECT0001/ps_local_mgd"][step]
ModelLinkage
with type 2 (path to state of the broadcast hub/register to read from)ModelLinkage
with type 4 - "push to accumulator"Class definition
Object Handler
This class will handle:
hdf5
database.@njit
simulation.