Add missing list of choices/keys and auto validate object types in PlantEquipmentList, CondenserEquipmentList and Branch objects

[Nigusse]

Parent objects with missing valid (supported) components type choices:

(1) AirLoopHVAC:OutdoorAirSystem:EquipmentList (2) Branch (3) PlantEquipmentList (4) CondenserEquipmentList (5) Identify other objects with missing choices or object keys.

On 11/13/2015 10:08 AM, Bereket Nigusse wrote:

While working on another project I came across "Component 1 Object Type" input field in the object below but does not show the object types allowed.

AirLoopHVAC:OutdoorAirSystem:EquipmentList, \memo List equipment in simulation order A1 , \field Name \required-field \type alpha \reference AirLoopOAEquipmentLists A2 , \field Component 1 Object Type \required-field A3 , \field Component 1 Name

Shouldn't this input field "Component 1 Object Type" defined as a choice field and all allowed objects types be listed as Key for users to choose from?It is hard user to tell which objects are allowed or not.

Shall I add this as bug issue as a suggestion to update the IDD?

Thanks, Bereket

Mike's response: Technically yes. There are also other places that need a list of choices, namely, the Branch object and maybe others. The object names should also have a valid object list name associated with it. I'd like for that to be sensitive to what was chosen for object-type, but we don't do that yet. Mike

Edwin's response: Makes sense to me.

[mjwitte]

I'm ok with this for most places except maybe the Branch object. There the list would be very long, which begs for a different approach.

[Nigusse]

AirLoopHVAC:OutdoorAirSystem:EquipmentList object valid choice keys can be extracted from the source code. This is not the case for plant and condenser equipment lists.

The only option I can think is to extract the valid choice keys from the test files. If I remember correctly the plant loop and condenser loop implementation has been unified during plant upgrade, so the CondenserEquipmentList and PlantEquipmentLists can use the same key choices. Is this not the case? @mjwitte @Myoldmopar @EnergyArchmage

[mjwitte]

@Nigusse @JasonGlazer I've always thought these hard lists of object types were unnecessary when we've already got \references that identify the legal objects (in some cases). On the one hand, the current approach of a list of key choices is very straightforward, e.g.:

Coil:Heating:Desuperheater,
  A5 , \field Heating Source Object Type
       \required-field
       \type choice
       \key Coil:Cooling:DX:SingleSpeed
       \key Coil:Cooling:DX:TwoSpeed
       \key Coil:Cooling:DX:TwoStageWithHumidityControlMode
       \key Refrigeration:CompressorRack
       \key Refrigeration:Condenser:AirCooled
       \key Refrigeration:Condenser:EvaporativeCooled
       \key Refrigeration:Condenser:WaterCooled
  A6 , \field Heating Source Name
       \required-field
       \type object-list
       \object-list DesuperHeatingCoilSources

This is fine for a single field that has a limited set of valid object types. But for things like ZoneHVAC:EquipmentList, there's a long list of key choices and not even a corresponding \reference list:

ZoneHVAC:EquipmentList,
  A2 , \field Zone Equipment 1 Object Type
       \begin-extensible
       \type choice
       \key ZoneHVAC:TerminalUnit:VariableRefrigerantFlow
       \key ZoneHVAC:AirDistributionUnit
       \key AirTerminal:SingleDuct:Uncontrolled
       \key ZoneHVAC:EnergyRecoveryVentilator
       \key ZoneHVAC:EvaporativeCoolerUnit
       \key ZoneHVAC:FourPipeFanCoil
       \key ZoneHVAC:OutdoorAirUnit
       \key ZoneHVAC:PackagedTerminalAirConditioner
       \key ZoneHVAC:PackagedTerminalHeatPump
       \key ZoneHVAC:UnitHeater
       \key ZoneHVAC:UnitVentilator
       \key ZoneHVAC:VentilatedSlab
       \key ZoneHVAC:WaterToAirHeatPump
       \key ZoneHVAC:WindowAirConditioner
       \key ZoneHVAC:Baseboard:RadiantConvective:Electric
       \key ZoneHVAC:Baseboard:RadiantConvective:Water
       \key ZoneHVAC:Baseboard:RadiantConvective:Steam
       \key ZoneHVAC:Baseboard:Convective:Electric
       \key ZoneHVAC:Baseboard:Convective:Water
       \key ZoneHVAC:HighTemperatureRadiant
       \key ZoneHVAC:LowTemperatureRadiant:VariableFlow
       \key ZoneHVAC:LowTemperatureRadiant:ConstantFlow
       \key ZoneHVAC:LowTemperatureRadiant:Electric
       \key ZoneHVAC:Dehumidifier:DX
       \key ZoneHVAC:IdealLoadsAirSystem
       \key ZoneHVAC:RefrigerationChillerSet
       \key Fan:ZoneExhaust
       \key WaterHeater:HeatPump:PumpedCondenser
       \key WaterHeater:HeatPump:WrappedCondenser
       \required-field
  A3 , \field Zone Equipment 1 Name
       \required-field

And then there are others with lists of keychoices and lists of references:

AirLoopHVAC:UnitarySystem,
  A12, \field Heating Coil Object Type
       \type choice
       \key Coil:Heating:DX:SingleSpeed
       \key Coil:Heating:DX:MultiSpeed
       \key Coil:Heating:DX:VariableSpeed
       \key Coil:Heating:WaterToAirHeatPump:ParameterEstimation
       \key Coil:Heating:WaterToAirHeatPump:EquationFit
       \key Coil:Heating:WaterToAirHeatPump:VariableSpeedEquationFit
       \key Coil:Heating:Gas
       \key Coil:Heating:Gas:MultiStage
       \key Coil:Heating:Electric
       \key Coil:Heating:Electric:MultiStage
       \key Coil:Heating:Water
       \key Coil:Heating:Steam
       \key Coil:Heating:Desuperheater
       \key Coil:UserDefined
       \note Enter the type of heating coil if included in the unitary system.
  A13, \field Heating Coil Name
       \type object-list
       \object-list HeatingCoilsDX
       \object-list HeatingCoilsDXMultiSpeed
       \object-list HeatingCoilsDXVariableSpeed
       \object-list HeatingCoilsWaterToAirHP
       \object-list HeatingCoilsWaterToAirVSHP
       \object-list HeatingCoilName
       \object-list HeatingCoilsElectricMultiStage
       \object-list HeatingCoilsGasMultiStage
       \object-list HeatingCoilsDesuperheater
       \object-list UserDefinedCoil
       \note Enter the name of the heating coil if included in the unitary system.

For the much more general places like the ones to be addressed in this issue, I'd like to see a different approach that avoids the need to maintain these lists. This would require a new \code, something like this:

PlantEquipmentList,
  A2 , \field Equipment 1 Object Type
       \type object-type-list <-- new \code
       \object-list validPlantEquipment
  A3 , \field Equipment 1 Name
       \type object-list
       \object-list validPlantEquipment

Chiller:Electric:EIR,
  A1 , \field Name
       \type alpha
       \reference Chillers
       \reference validPlantEquipment <-- Individual objects are tagged as a memeber of the group, kind of like a base class for plant equipment
       \required-field

I'm not suggesting that we change all of the current one-off places like AirloopHVAC:UnitarySystem (at least not now), but just the general branch and equipment lists (including ZoneHVAC:EquipmentList) that are to be addressed in this issue. Adding @kbenne @macumber .

[JasonGlazer]

@mjwitte In the past, I added \reference-class-name to help solve the long list of \keys referencing the type of objects in the past but it doesn't seem be getting used anywhere. It is documented at the top of the IDD. Would that help solve part of this issue?

[mjwitte]

@JasonGlazer Yes, that would work. So, if I understand it correctly, the above proposal would then be:

PlantEquipmentList,
  A2 , \field Equipment 1 Object Type
       \type object-list <-- new \code
       \object-list validPlantEquipmentTypes
  A3 , \field Equipment 1 Name
       \type object-list
       \object-list validPlantEquipmentNames

Chiller:Electric:EIR,
  A1 , \field Name
       \type alpha
       \reference Chillers
       \reference-class-name validPlantEquipmentTypes <-- list of object types
       \reference validPlantEquipmentNames <-- list of object names
       \required-field

Might be better to rename this to reference-class-type to avoid confusion? I realize that would mean a corresponding change to IDF Editor.

[mjwitte]

Note I edited the last comment. \type object-list-type ..> \type object-list

[JasonGlazer]

Yes, just a regular \type object list would work then. And I don't mind changing the exact slash code name in IDF Editor if you think that would be clearer. I am pretty sure that when I put in \reference-class-name it was being used in the IDD but at some point they must have been removed. It is a nice feature to collect up the types of objects.

[macumber]

For what it's worth openstudio does not handle reference class names, don't think we knew they existed. Don't let that stop you just saying interface developers might not know about those things

[mjwitte]

@macumber Understood. What is OpenStudio currently doing to validate what can go, say, in a PlantEquipmentList? Would declaring these references in the IDD be helpful?

[Nigusse]

@mjwitte @JasonGlazer if I understand correctly, the "validPlantEquipmentTypes" and "validPlantEquipmentNames" are tagged to each of valid objects in the PlantEquipmentList. How is each individual object validated? Is it the IDF editor that validates them? In that case, do we need to list the choice Keys in the "Equipment 1 Object Type" field?

[mjwitte]

@Nigusse IDF editor will generate the lists automatically based on the objects that have the same \reference or \reference-class-name tag. Ultimately, determining which objects belong in "validPlantEquipment*" goes back to your initial question - and that's by looking at the case statements (or equivalent) in the code. A missing link here is that we don't currently have a way to test this other than opening various idf files and running the IDF editor validation check to see if anything gets flagged. Write a python script? Or add logic to input processor to check these early on?

[macumber]

@kbenne and @mbadams5 would know about references in plantloops, im not sure we use the idd markup for plantloops, maybe it is because it doesn't exist?

[mjwitte]

@macumber Correct - it doesn't exist. That's what this issue intends to add.

[Nigusse]

@mjwitte @JasonGlazer I made code change in the InputProcessor that checks for plant and condenser equipment list. But I have run into issues when I tried for Branch (air Loop Branch). The issue is the validation routine (ValidateObjectandParse) treats or identifies all branch the same (Air and water loop branches). This beyond the effort for bug issue. I am limiting this issue to plant and condenser equipment. The OA equipment is addressed using Keychoices instead of object-list.

[mjwitte]

@Nigusse I wasn't expecting you to go that far - adding input processor validation. Is that on a branch that I can look at? In theory, the input processor function should be generic and once it's in place it should work for any set of reference lists. The fact that branches are generic shouldn't be a problem. It just means lots of objects would get a \reference validBranchComponentType.

[Nigusse]

@mjwitte Yes, it is on a branch and I have to clean it before pushing it. The input processor is sort of generic but it is classified for each category (plant, condenser, and Branch). When I was testing I run into issue with \reference-class-name validBranchComponentType. The idf parser recognizes all branches (air or water loop) the same, and it throws error files. The plant and condenser equipment did not have any problem. Any ways I will push the branch in a little bit .

[Nigusse]

@mjwitte Fixed initialization issue that led to several unit tests to fail, now branch object lists are also auto verified/validated. I pushed the updated branch to remote and expect the CI machine to come all green.

[Myoldmopar]

Closed with #5727