Remove IddObjectType limits from ReportingMeasure `energyPlusOutputRequests`

[eringold]

Enhancement Request

Currently, the energyPlusOutputRequests method in a reporting measure limits the types of objects that can be added to the workspace. This can create unweildy situations for reporting measures that might require adding, e.g. PythonPlugin objects, OutputDiagnostics objects, etc. that would otherwise need to be paired with an upstream ModelMeasure or EnergyPlusMeasure. Instead of keeping a running list of allowed object types, let energyPlusOuputRequests add whatever object to the IDF.

Possible Implementation

Remove the check for allowedObjects

[shorowit]

@eringold Did you see this discussion? #4830

[shorowit]

And NatLabRockies/OpenStudio-workflow-gem#147

[jmarrec]

There is a reason only specific objects are added, and that is because it's meant to be a reporting measure... something you wouldn't expect to modify your model in a way that changes the energy usage (eg: adding a new ElectricEquipment or something like this).

I understand the running list of things we allow is missing a few things you'd like to add.

So we have two choices:

1. Extend the list of accepted objects to include yours: vote with 👍
2. Remove it altogether: vote with 👎

Pros for 1 is that we maintain the contract that a reporting measure isn't going to do weird stuff. Cons is that we have to keep updating it from time to time.

@joseph-robertson @shorowit @eringold @kbenne @DavidGoldwasser can we put it to a vote?

[jmarrec]

I think @shorowit has a good point here: #4830 (comment)

I'm going to implement #4830, a new ReportingMeasure::modelOutputRequests(model, runner, argument_map). That'll bring some clarity.

[eringold]

I'm in favor of adding modelOutputRequests, but also think the IddObjectType restrictions should be lifted for energyPlusOutputRequests. We don't know all the possible uses for and requirements of a "reporting" measure, and having to add to a list of allowed objects every time a new use/requirement is identified is unnecessarily restrictive. As @shorowit says in the linked comment:

By choosing a hands-off approach, OS reduces maintenance and increases flexibility

It should be up to the modeler to know what their measures are doing and the implication of any 'output' request on the simulation results.

[jmarrec]

• I implemented Allow model instead of workspace in energyPlusOutputRequests #4830 in #4830 - Add a new ReportingMeasure::modelOutputRequests(model, runner, argument_map) that runs before E+ FT #5367

Implementing some sanity checks in modelOutputRequests is going to be too hard and not worth it.

I'm ok removing the IddObjectType limits from ReportingMeasure::energyplusOutputRequests... Even though that one will likely become kinda obsolete as we wrap most objects in the SDK that you'd want to use.