search

open229 / ruleset-model-description-schema

Developing a schema for ASHRAE Standard 229P.
Other
9 stars 3 forks source link

`Boiler.efficiency`: `≥0, ≤1` #279

Open JacksonJ-KC opened 2 months ago

JacksonJ-KC commented 2 months ago

Modeling tools (such as eQUEST) may allow the boiler efficiency to be modeled greater than 1. In these cases it seems important that the RPD file should be able to accurately represent the modeled efficiency. I suggest removing the limitation that the efficiency has to be ≤1.

JasonGlazer commented 4 weeks ago

@JacksonJ-KC it seems like allowing the efficiency to be greater than 1.0 is simply a workaround for an air to water heat pump and those really need more performance information based on air temperature than a boiler's typical performance curves plus has other heat pump characteristics such as defrost. Overall, it doesn't seem like a good idea to me.

JacksonJ-KC commented 4 weeks ago

Maybe correctly setting the boiler efficiency greater than 1 would be a workaround for a heat pump. But the issue I am raising is that eQUEST does not prohibit a modeler from entering an efficiency greater than 1. If it is modeled greater than 1 (even as a mistake) what should I do for the RPD file if I am not allowed to report it greater than 1?

JacksonJ-KC commented 4 weeks ago

The fact that it is possible to model it incorrectly greater than 1 I think is reason enough for the schema to allow the efficiency to be reported as greater than 1, and a ruleset can decide whether or not that is correct.

JasonGlazer commented 3 weeks ago

Seems like that logic would imply that no data element should have a maximum and minimum

JacksonJ-KC commented 3 weeks ago

While that is not what I am suggesting, I do see your point and understand that making an exception for boiler efficiency only because of eQUEST is not ideal justification.

Currently if this is modeled greater than 1 the RPD will fail validation and RCT evaluation will not run. Although I don't think this is ideal, maybe this is the appropriate feedback to give when the efficiency is modeled greater than 1.

JacksonJ-KC commented 1 week ago

Seems like that logic would imply that no data element should have a maximum and minimum

Coming back to this, my suggestion is more that the logic should be based on whether it is possible to be modeled. There are data elements that have clear and necessary min/max values like airflow cannot be less than 0 because that would not make sense and should not be possible to model.

Since it is possible to model efficiency greater than 1 without breaking the simulation and without breaking the RCT, I think it should be possible to describe it in the RPD exactly as it was modeled.

The eQUEST GUI input is heat-input-ratio. It is an easy and common mistake for someone to input their 96% efficient boiler as 0.96 heat input ratio, which results in an efficiency greater than 1. I really don't like the solution of voiding RCT evaluations with a validation error for any eQUEST models that mix up this input.

JacksonJ-KC commented 1 week ago

I'm not sure that imposing a maximum value helps with anything but it does cause difficulties for eQUEST users/RPD Generation.

JasonGlazer commented 9 hours ago

I still believe that your argument is more generic and that almost all minimums and maximums should be removed based on your logic. Who knows what a simulation program might allow as an input for a specific parameter? I'm not saying that it is wrong but if we do make this change, we need a solid rule of thumb for why a minimum or maximum should be included. My original rule of thumb was simply related to physical possibilities. Since you suggest that software programs may allow input values beyond the normal physical limits, I don't think it is reasonable to check every possible software program's minimum or maximum.

The only practical solution to this that I can think of is to use the physical limits on an input unless a software program reports that it can go beyond that limit. Wearing my data modeling hat, I would not be happy with that solution, but perhaps it is the most practical.