BostonTemplateLibrary_2.json incorrectly stores windows

[szvsw]

It stores the complete dict of windows, rather than a ref:

archetypal/tests/input_data/umi_samples/BostonTemplateLibrary_2.json

Lines 5487 to 5538 in 66dc6dc

	"Windows": {
	"$id": "179",
	"AfnDischargeC": 0.65,
	"AfnTempSetpoint": 20.0,
	"AfnWindowAvailability": {
	"$ref": "145"
	},
	"Construction": {
	"$ref": "57"
	},
	"IsShadingSystemOn": false,
	"IsVirtualPartition": false,
	"IsZoneMixingOn": false,
	"OperableArea": 0.8,
	"ShadingSystemAvailabilitySchedule": {
	"$ref": "145"
	},
	"ShadingSystemSetpoint": 350.0,
	"ShadingSystemTransmittance": 0.5,
	"ShadingSystemType": 0,
	"Type": 0,
	"ZoneMixingAvailabilitySchedule": {
	"$ref": "145"
	},
	"ZoneMixingDeltaTemperature": 2.0,
	"ZoneMixingFlowRate": 0.001,
	"Category": "Office Spaces",
	"Comments": "Base building definition for MIT 4433",
	"DataSource": "MIT_SDL",
	"Name": "B_Off_0 windows"
	},
	"DefaultWindowToWallRatio": 0.4,
	"YearFrom": 0,
	"YearTo": 0,
	"Country": [
	"USA"
	],
	"ClimateZone": [
	"5A"
	],
	"Authors": [
	"Carlos Cerezo"
	],
	"AuthorEmails": [
	"ccerezo@mit.edu"
	],
	"Version": "v1.0",
	"Category": "Office Spaces",
	"Comments": "Base building definition for MIT 4433",
	"DataSource": "MIT_SDL",
	"Name": "B_Off_0"
	},

This means that when loading building templates, it will create a new window object every time, since L336 will always error out:

archetypal/archetypal/template/building_template.py

Lines 335 to 341 in 66dc6dc

	try:
	window = window_settings[window_data["$ref"]]
	except KeyError:
	window = WindowSetting.from_dict(
	window_data, schedules, window_constructions
	)

This is normally handled fine, but in the realtime-graphs setup that I am working on right now, this leads to errors.

I'm pretty sure it's just an artifact of an old call to save() a template library, since current template libraries appear to save windows at the building template layer as refs, so it's just a matter of fixing the json.

[szvsw]

As a follow-up, I notice that BostonTemplateLibrary_nodup.json does store windows as refs, so perhaps this is intentional and BostonTemplateLibrary_2.json is meant to store nested objects for testing purposes - if so, is this considered a supported format for a serialized template library?

[szvsw]

Alright, I was able to set up try catch handling to deal with the case that I am working on, but still would like to make sure that it is valid to store nested objects in a template lib serialization.

[samuelduchesne]

For reference, objects should not be stored in a nested way. BostonTemplateLibrary_2.json is an example of a library ad returned by the UMI Template Editor. I believe there is a bug in there which creates nested WindowSetting in each BuildingTemblate object and adds a ref in the WindowSettings array. That should not be the case in our implementation of the serializer