customized Energy+.schema.epJSON

asked 2019-02-11 01:01:06 -0600

ngkhanh
2156 ●1 ●4 ●13

updated 2019-02-11 08:11:32 -0600

From this question's answer How to change idd file, I wonder is it possible to modify the Energy+.schema.epJSONdirectly in order to get a customized reference list during EP run instead compiling EP?
in the old Idd format, the objects like ZoneTerminalUnitList might have a max number of extensible fields but iI could not see any limit config inside new Energy+.schema.epJSON. Is that limit removed in new scheme ? i did some parsing and got this:

with open('Energy+.schema.epJSON') as f:
    data = json.load(f)
pprint(data["properties"]['ZoneTerminalUnitList'] ,width = 240)

{'extensible_size': 1.0,
 'legacy_idd': {'alphas': {'extensions': ['zone_terminal_unit_name'], 'fields': ['zone_terminal_unit_list_name']},
                'extensibles': ['zone_terminal_unit_name'],
                'extension': 'terminal_units',
                'field_info': {'zone_terminal_unit_list_name': {'field_name': 'Zone Terminal Unit List Name', 'field_type': 'a'}, 'zone_terminal_unit_name': {'field_name': 'Zone Terminal Unit Name', 'field_type': 'a'}},
                'fields': ['zone_terminal_unit_list_name'],
                'numerics': {'fields': []}},
 'memo': 'List of variable refrigerant flow (VRF) terminal units served by a given VRF condensing unit. See ZoneHVAC:TerminalUnit:VariableRefrigerantFlow and AirConditioner:VariableRefrigerantFlow.',
 'min_fields': 2.0,
 'patternProperties': {'.*': {'properties': {'terminal_units': {'items': {'properties': {'zone_terminal_unit_name': {'data_type': 'object_list', 'object_list': ['ZoneTerminalUnitNames'], 'type': 'string'}},
                                                                          'required': ['zone_terminal_unit_name'],
                                                                          'type': 'object'},
                                                                'type': 'array'},
                                             'zone_terminal_unit_list_name': {'reference': ['ZoneTerminalUnitListNames'], 'type': 'string'}},
                              'required': ['zone_terminal_unit_list_name'],
                              'type': 'object'}},
 'type': 'object'}

pprint(data["properties"]['Fan:SystemModel'],width = 240)

{'is_required': True, 'reference': ['Fans', 'FansCV', 'FansCVandOnOff', 'FansCVandOnOffandVAV'], 'type': 'string'}

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2019-02-12 06:51:41 -0600

JasonGlazer

6905 ●26 ●12 http://www.gard.com/

For ZoneTerminalUnitList since it is extensible, you should be able to use as many fields as you want presuming that you are modifying the IDF or epJSON file using a text editor. If you are using IDF Editor, go ahead and make the changes to the IDD file so that more fields show up. You can also create customized reference lists directly in the IDD file and the IDF Editor will use those. EnergyPlus itself doesn't care if you add \reference or \object-list to the IDD file.

edit flag offensive delete link

add a comment

answered 2019-02-11 09:46:06 -0600

MarkAdams
1845 ●2 ●9 https://github.com/mbadams5

Since the Energy+.schema.epJSON is generated directly from the IDD then compiled into the executable, it is not possible to change it without recompiling EnergyPlus. The IDD and Energy+.schema.epJSON provided with the installer are for informational purposes only. Changing either of them will not alter the compiled schema.

In your specific instance, there is not a max number of extensible fields in the Energy+.schema.epJSON for ZoneTerminalUnitList. In the Energy+.schema.epJSON, look for minProperties, maxProperties, minItems, and maxItems; these are the only limits on the number of fields/items in the schema.

edit flag offensive delete link

Comments

@MarkAdams I've had reasons to modify the IDD in the past too (increase boiler efficiency limit to be greater than one), so wondering what the reason was for compiling it and whether it would be possible to go back to the old way in future versions.