Thermal wheels

[JayHuLBL]

This closes #3538.

[mwetter]

@JayHuLBL : What are the next steps, and who needs to act on them?

[JayHuLBL]

@mwetter The PR will be ready for your review when CI test passed.

One questions however is about the base class Buildings.Fluid.HeatExchangers.AirToAirHeatRecovery.BaseClasses.HeatExchagerWithInputEffectiveness. The class is similar as Buildings.Fluid.MassExchangers.ConstantEffectiveness, with the difference that the effectiveness espS and espL are inputs rather than parameter. Is it a good choice to duplicate the class and change the effectiveness to be inputs (as implemented here.)?
Or making the changes in Buildings.Fluid.MassExchangers.ConstantEffectiveness so that the effectiveness could be conditional inputs. But in this case, the class name ConstantEffectiveness will need to be changed.

[mwetter]

I think HeatExchagerWithInputEffectiveness is fine as I don't see an elegant way to change the effectiveness to be a conditional input, and remove the parameter if the input is enabled.

[mwetter]

I did a quick review and it is clear that this model is not yet ready for a final review. Please see comments and review first the code; afterwards I am happy to do a last review.

[mwetter]

@JayHuLBL : This still needs significant revisions, namely:

• The examples use sta_a and/or sta_b, but these are not defined at zero flow rate. No example should use these quantities. (We removed them in other models due to verification issues across tools.)

• The bigger change due to non-sound physics is as follows: EnergyPlus uses different efficiencies for heating and cooling because EnergyPlus uses a heating and cooling design flow rate. This Modelica model also uses different efficiencies, but it only has one design flow rate. From a heat transfer point of view, for the sensible wheel if the design flow rates are the same, there is no physical justification to use different efficiencies. For the latent wheel, however, cooling also has latent exchange so the sensible cooling efficiency may be different from the (sensible) heating efficiency.

  Moreover, I don't understand what a "latent heating efficiency" is. Therefore, epsLatHea* needs to be removed (or clearly explained what it is).

• Another change is that all efficiency parameters should be in a data record. That is, for the wheels with bypass dampers, the thermal efficiencies for the wheel, and for the wheel with variable speed, the thermal efficiencies plus the speed correction and motor characterization need to be in one data record. This will allow building up a Data package with different wheel characterizations.

  Currently, the users sees the Data package, but these data only have part of the thermal characterization, and only for some wheel (the ones with variable speed). It would be much clearer if all data is in the record as we do for other components.

[SenHuang19]

@JayHuLBL : This still needs significant revisions, namely:

• The examples use sta_a and/or sta_b, but these are not defined at zero flow rate. No example should use these quantities. (We removed them in other models due to verification issues across tools.)
• The bigger change due to non-sound physics is as follows: EnergyPlus uses different efficiencies for heating and cooling because EnergyPlus uses a heating and cooling design flow rate. This Modelica model also uses different efficiencies, but it only has one design flow rate. From a heat transfer point of view, for the sensible wheel if the design flow rates are the same, there is no physical justification to use different efficiencies. For the latent wheel, however, cooling also has latent exchange so the sensible cooling efficiency may be different from the (sensible) heating efficiency.
  Moreover, I don't understand what a "latent heating efficiency" is. Therefore, epsLatHea* needs to be removed (or clearly explained what it is).
• Another change is that all efficiency parameters should be in a data record. That is, for the wheels with bypass dampers, the thermal efficiencies for the wheel, and for the wheel with variable speed, the thermal efficiencies plus the speed correction and motor characterization need to be in one data record. This will allow building up a Data package with different wheel characterizations.
  Currently, the users sees the Data package, but these data only have part of the thermal characterization, and only for some wheel (the ones with variable speed). It would be much clearer if all data is in the record as we do for other components.

@mwetter Thank you so much for the edits and comments. I’m working on addressing the points above and will submit a PR for @JayHuLBL’s review shortly.

[mwetter]

@SenHuang19 : Looking at https://www.drirotors.com/wp-content/uploads/pdfs/HRW-MS-200-Tech.-Specification_1.pdf I think it makes sense to also put a design mass flow rate and pressure drop in the data record. Then the wheel can be fully characterized by a data record.