Receptacle exceptions (Rule 12-4)

[weilixu]

Link to the PR discussion

A little more background for my thoughts:
The OSSTD-PRM model takes a user model and generates proposed and baseline model. When performing PRM automation, we made a decision to assume the receptacle schedules have taken credits in the user and proposed model. So when creating the baseline model, the schedule is recreated based on equation baseline = proposed / (1.0 - RPC).
Due to Eplus crashes on >1.0 multiplier, we have to set min(1.0, baseline) to ensure a successful baseline automation.

One way to look at it is a successful baseline automation does not mean a pass in RCT checking.

For that, i do need to have a clearer understanding on the EPSpro = EPSbas x (1-RPC). The part confuse me are 1. whether the user model should factor the credit and 2. how to calculate EPSbas to determine EPSpro.
Basically, should the EPSuser = EPSbas = EPSpro / (1 - RPC)? or Should the EPSuser = EPSpro = EPSbas * (1-RPC)?

Standard is not clear on this logic and that is the reason I suggest adding an undermined outcome for this rule.

[JacksonJ-KC]

If a tool that automates creating the baseline needs to set a limit of 1.0 for the multiplier schedule then so be it. But if a proposed model in this tool has an hourly multiplier value of 1.0 that means they did not apply any reduction to the schedule.

Any expected value greater than 1 for the baseline means that no credit was taken or less credit was taken than expected in the proposed, and it should be a fail.

[weilixu]

After digging, I found the PRM-RM has this:
Baseline Building: Same as proposed before the automatic receptacle control credit is applied.

So, my understanding is the baseline value should be equal to the user and the proposed take credits, which is handled by BEM automation logic.
In that case, OSSTD-PRM needs an update on its RPC logic.

I was not questioning the rule logic - it is clear as you stated, rather I was unclear about how software interpreted this rule since how baseline value was established was unclear (see OSSTD was one way to interpret the logic.), and how the RCT rule logic can help identify this issue by providing clearer message.

[mkarpman]

I thought that where there are receptacle controls in addition to the mandatory required minimum, the reduced schedule fraction should be modeled for both the user model and proposed design model.

[weilixu]

I thought that where there are receptacle controls in addition to the mandatory required minimum, the reduced schedule fraction should be modeled for both the user model and proposed design model.

I thought the same and in OpenStudio PRM measure, this is implemented as:

user = proposed
baseline = proposed / min(1.0 , (1-RPC)) # The min is to prevent multiplier go over 1.0 that crashes the EnergyPlus simulation

However, in PRM-RM, it is said Same as proposed before the automatic receptacle control credit is applied. This implies the way to do it is:

user = baseline
proposed = baseline x (1-RPC)

It seems this can go both ways. When automating the process, the automation software would have to provide user guidelines and probably collect enough information from users to determine the credit implementation.
I thought the rule could provide some useful message that would be helpful for end-user to know the issue - maybe I am overthinking it and should leave it to automation logic to handle it.

[mkarpman]

My interpretation for the schedule fractions is that
proposed=user
baseline=proposed/(1-RPC)

So essentially, the schedules modeled in the user model reflect modeler's estimate on receptacle loads runtime including all installed controls. Proposed design inherets these schedules. Projects with qualified receptacle controls get credit by modeling longer receptacle loads runtime in the baseline model based on equation provided in App G.