hierarchical type system and common ways of transmitting structures.

[phlptp]

To support more complex domain specific API's Helics will need to support a underlying type structure, what this looks like will need to be defined and implemented probably based on structures of the well defined types in the application_api

[phlptp]

This will come more into play with the usability working group results.

[phlptp]

This will probably not make it into the 2.0 release initially, it has dropped in priority with more details from the HELICS-HLA effort

[phlptp]

We are considering using Conduit for this purpose

https://github.com/LLNL/conduit

[trevorhardy]

I've been thinking through this some and haven't been able to convince myself that these structured data types would provide significant utility. It would allow users to see from that outside that these, say 10,000 elements are all related voltages and it would allow us to define the message attributes as a block.

Any federate that subscribes to this structured data, though, would still have to map each of those 10,000 voltages into internal variables (presumably through the "info" field in the config file or some other mapping method) and thus has saved very little, if any, effort or lines of code. It doesn't seem like it actually would save the sender of the messages or the receiver much effort as all the individual elements in the structure would need to be configured to be useful.

Assuming we use something like Conduit, it would also introduce another software dependency, which, from a usability standpoint, adds another potential complication for installation and running.