Add option to export properties aggregated by element group

[daniel-thom]

This PR satisfies a feature request made by the DISCO team. They want to collect PVSystem power outputs at every time point for a large number of simulations. They don't need the values for every PVSystem. They want the values aggregated by customer type in order to save storage space. Customer type is obviously not a property of an OpenDSS or PyDSS element.

Here is what the team plans to do:

• DISCO will analyze the OpenDSS circuit to determine which load shares a bus with each PVSystem. The load shape profile for each load encodes the customer type in its name (at least for SMART-DS datasets). Record a mapping of PVSystem to customer type.
• DISCO will assign the sum_groups field of an export property as defined in this PR.
• PyDSS will collect aggregated values by customer type.
• DISCO will read the values after the simulation.

Here is an example of what the Exports.toml file would look like:

[[PVSystems]]
property = "Powers"
store_values_type = "all"

[PVSystems.sum_groups]
com = [ "pvgnem_mpx000635970", "pvgnem_mpx000460267",]
res = [ "pvgnem_mpx000594341", "pvgui_mpx000637601", "pvgui_mpx000460267",]

[daniel-thom]

This looks good to me. The only concern I have is this: having customer type lists ("res" and "com") explicitly defined in the toml file could "pollute" the latter in cases with a large number of PV units. Can this toml file entry be the name or path of a file containing these lists instead?

I like the suggestion. I'll implement it. Might even be able to easily support both options. Thanks.

[daniel-thom]

This looks good to me. The only concern I have is this: having customer type lists ("res" and "com") explicitly defined in the toml file could "pollute" the latter in cases with a large number of PV units. Can this toml file entry be the name or path of a file containing these lists instead?

I like the suggestion. I'll implement it. Might even be able to easily support both options. Thanks.

This is now implemented.

[KwamiS]

This looks good to me. The only concern I have is this: having customer type lists ("res" and "com") explicitly defined in the toml file could "pollute" the latter in cases with a large number of PV units. Can this toml file entry be the name or path of a file containing these lists instead?

I like the suggestion. I'll implement it. Might even be able to easily support both options. Thanks.

This is now implemented.

Awesome! Thank you, @daniel-thom