Update FT for space-level infiltration/ventilation objects

[shorowit]

Enhancement Request

EnergyPlus 22.2 will support space-level infiltration and ventilation. Since it did not previously support it, OpenStudio had to go through hoops to combine multiple space objects into a single zone object for EnergyPlus. Now there should be a 1:1 map and the code should be simpler. This will also help prevent bugs (like this one).

This is an important feature for us because we want to use output variables for individual space-level infiltration objects in the same thermal zone. That is not possible unless the EnergyPlus model maintains the individual space-level infiltration objects that we've defined in OpenStudio.

[tijcolem]

@joseph-robertson Let's prioritize the E+ 22.2.0 IO Freeze first and then if we have time we can slot this in.

[shorowit]

In hindsight, I realize that we don't actually need this capability after all. I was confusing this with something else. So it's probably still worth doing, but it's not a priority from our point of view.

[shorowit]

Apparently this may be a high priority for us again, but for a different reason. Mike Witte found that the E+ models we produce generate an error in E+ 22.2 because we try to (EMS) actuate a zone-level infiltration object (since that's all OS will produce), but when that zone has multiple spaces, E+ automatically converts the zone-level infiltration object into individual space-level infiltration objects. It does the same thing for equipment, lights, etc. It's possible there is a way to workaround this, but everything would be simpler, cleaner, and more consistent if OpenStudio translated objects 1:1.

[jmarrec]

We have SpaceInfiltration (so Space), but ZoneVentilationDesignFlowRate (so ThermalZone) in OS. For SpaceInfiltration, no problem.

But for the ZV:DesignFlowRate, do you want to have that map to a Space in the end? It'd be pretty weird to me. Unless we allow the OS:ZoneVentilation:DesignFlowRate to also connect to a Space... but that's not as light of a change

[jmarrec]

I'm glad this is going to go:

OpenStudio/src/energyplus/ForwardTranslator.cpp

Lines 319 to 364 in ce3ee50

	// We're going to have a bunch of troubles with the SpaceInfiltration objects as they cannot live on a Space in E+, they are on the zone
	// So we do the same as combineSpaces but only for those infiltration objects: we hard apply them to each individual space, then remove the
	// spacetype ones to be safe (make 100% sure they won't get translated)
	// TODO: Technically we could just find a smart way to convert the SpaceInfiltration:DesignFlowRate object to a Flow / Zone and use a ZoneList,
	// but it gets complicated with little benefit, so not doing it for now
	for (auto& sp : model.getConcreteModelObjects<SpaceType>()) {
	auto spi = sp.spaceInfiltrationDesignFlowRates();
	auto spiel = sp.spaceInfiltrationEffectiveLeakageAreas();
	auto spifc = sp.spaceInfiltrationFlowCoefficients();
	std::vector<SpaceLoad> infiltrations;
	infiltrations.reserve(spi.size() + spiel.size() + spifc.size());
	infiltrations.insert(infiltrations.end(), spi.begin(), spi.end());
	infiltrations.insert(infiltrations.end(), spiel.begin(), spiel.end());
	infiltrations.insert(infiltrations.end(), spifc.begin(), spifc.end());
	for (auto& infil : infiltrations) {
	for (auto& space : sp.spaces()) {
	auto infilClone = infil.clone(model).cast<SpaceLoad>();
	infilClone.setParent(space);
	}
	infil.remove();
	}
	// The ElectricEquipment:ITE:AirCooled only accepts a Zone or a Space, not a ZoneList nor a SpaceList
	// So similarly, we need to put them on the spaces to avoid problems. But we do not need to hardSize() them
	for (auto& ite : sp.electricEquipmentITEAirCooled()) {
	std::string name = ite.nameString();
	for (auto& space : sp.spaces()) {
	auto iteClone = ite.clone(model).cast<SpaceLoad>();
	iteClone.setParent(space);
	}
	ite.remove();
	}
	}
	// We also convert all SpaceInfiltrationDesignFlowRate objects to Flow/Space (Flow/Zone) because these may not be absolute
	// That includes the Space ones too.
	// SpaceInfiltrationEffectiveLeakageAreas and SpaceInfiltrationFlowCoefficients don't need it, they are always absolute
	for (auto& infil : model.getConcreteModelObjects<SpaceInfiltrationDesignFlowRate>()) {
	// technically we only need to hardsize if the space it's assigned to is part of a thermalzone with more than one space
	if (!openstudio::istringEqual("Flow/Space", infil.designFlowRateCalculationMethod())) {
	if (infil.space() && infil.space()->thermalZone() && infil.space()->thermalZone()->spaces().size() > 1) {
	infil.hardSize(); // translates to Flow/Zone
	}
	}
	}
	}

[shorowit]

We have SpaceInfiltration (so Space), but ZoneVentilationDesignFlowRate (so ThermalZone) in OS. For SpaceInfiltration, no problem.

But for the ZV:DesignFlowRate, do you want to have that map to a Space in the end? It'd be pretty weird to me. Unless we allow the OS:ZoneVentilation:DesignFlowRate to also connect to a Space... but that's not as light of a change

Not sure what to say. In E+ they are both prefixed with Zone even though they can now apply to Spaces too. I see that OS:SpaceInfiltration inherits from SpaceLoad while OS:ZoneVentilation inherits from ZoneHVACComponent, so yeah, I see the conundrum. For what it's worth, NREL-Residential doesn't use the ZV objects today so we don't have an immediate need for them to be coupled to spaces. But we might in the future, and other users might want this.

I don't know how much I like the idea myself, but would it make any sense to introduce new SpaceVentilation objects?

[jmarrec]

I'm moving the ZoneVentilationDesignFlowRate into a separate issue (for later?): #4682

Consider this one fixed via #4672