The order of SizingPeriod:DesignDay objects in IDF affects humidification. Converting to epJSON prevents humidification.

[ericmartinpe]

Issue overview

The two attached IDFs (working & non-working) are exactly the same, except for the order in which the SizingPeriod:DesignDay objects are listed. In the working IDF, the heating design day is listed first; in the non-working IDF the cooling design day is listed first. The working IDF results show humidification energy, as expected. The non-working IDF shows zero humidification energy.

When converting either IDF to epJSON format, the results of the epJSON simulation are consistent with the non-working IDF; zero humidification energy. Even if I change the order of the SizingPeriod:DesignDay objects in the epJSON, it still shows zero humidification energy. When converting epJSON to IDF, it always puts the cooling design day first, hence humidification does not work. Simply changing the order of the design days in the IDF (which was converted from the epJSON) restores the humidification functionality, and humidification energy is shown in the results.

This is a pervasive bug which prevents epJSON-formatted input files (and IDFs converted from epJSON) from accurately modeling humidification.

ASHRAE901_OutPatientHealthCare_STD2016_Tampa - notworking.idf.txt
ASHRAE901_OutPatientHealthCare_STD2016_Tampa - working.idf.txt

Operating System (Multiple choices)

Windows

Operating System Version

Windows 10 Enterprise. Also reproduced on Red Hat Enterprise Linux Workstation release 6.6.

Version of EnergyPlus

24.1

Unmethours link or helpdesk ticket number

N/A

Defect file

ASHRAE901_OutPatientHealthCare_STD2016_Tampa - notworking.idf.txt
ASHRAE901_OutPatientHealthCare_STD2016_Tampa - working.idf.txt

[mjwitte]

Comparing the eio outputs. "working" file is on the left.

Hmm, why are there diffs in the zone heating Temperature at Peak {C} and Humidity Ratio at Peak {kgWater/kgDryAir} for some zones and not for others?

The zones with zero heating load show the diffs.

The "working" file shows a winter condition which is the first design day. Not sure of the exact logic, but likely these zone peak load conditions get initialized for each design day, then set to the value of the first design day, then scan across the remaining design days looking for a larger load which never happens.

There are no diffs in the System Sizing or any other Component Sizing outputs.

So, why does this zero-load zone outdoor condition impact the humidifier sizing?

[rraustad]

I am guessing it has to do with how a peak design day and time are chosen when there is no load. See updateZoneSizingEndZoneSizingCalc7.

// IF heating flow rate is 0, this data may be used to size a HP so initialize DDNum, TimeStepatPeak, and sizing data
if (zsFinalSizing.DesHeatLoad == 0) {
    // Check HDDNum and TimeStepNumAtHeatMax value and default to 1 if not set, carried over from previous code
    if (zsCalcFinalSizing.HeatDDNum == 0) {
        zsCalcFinalSizing.HeatDDNum = 1;
    }
    if (zsCalcFinalSizing.TimeStepNumAtHeatMax == 0) {
        zsCalcFinalSizing.TimeStepNumAtHeatMax = 1;
    }

There are also these FirstIteration flags in updateZoneSizingEndDay which, if there is no load, would choose the time of lowest zone temp for each design day.

if (zsCalcFinalSizing.DesHeatLoad == 0) {
    bool FirstIteration = true; // declare as static to save for next iteration? but needs to be space/zone specific?
    for (int TimeStepIndex = 1; TimeStepIndex <= numTimeStepInDay; ++TimeStepIndex) {
        if ((zsCalcSizing.HeatZoneTempSeq(TimeStepIndex) < zsCalcSizing.ZoneTempAtHeatPeak) || FirstIteration) {
            zsCalcSizing.ZoneTempAtHeatPeak = zsCalcSizing.HeatZoneTempSeq(TimeStepIndex);
            zsCalcSizing.OutTempAtHeatPeak = zsCalcSizing.HeatOutTempSeq(TimeStepIndex);
            zsCalcSizing.ZoneRetTempAtHeatPeak = zsCalcSizing.HeatZoneRetTempSeq(TimeStepIndex);
            zsCalcSizing.ZoneHumRatAtHeatPeak = zsCalcSizing.HeatZoneHumRatSeq(TimeStepIndex);
            zsCalcSizing.OutHumRatAtHeatPeak = zsCalcSizing.HeatOutHumRatSeq(TimeStepIndex);
            zsCalcSizing.TimeStepNumAtHeatMax = TimeStepIndex;
            FirstIteration = false;

[mjwitte]

v25.1 defect files.

ASHRAE901_OutPatientHealthCare_STD2016_Tampa-working-v25-1.idf.txt
ASHRAE901_OutPatientHealthCare_STD2016_Tampa-notworking-v25-1.idf.txt

[ericmartinpe]

It appears that the SizingPeriod:DesignDay objects are being sorted alphabetically, and run according to their alphabetical order. In the epJSON file, I changed the design day names to "design day a" and "design day b", and it always does sizing runs in order b, a, b (regardless of their physical location in the file).

When design day a is cooling (humidity doesn't work):

When design day a is heating (humidity does work):

notworking.epJSON.txt

working.epJSON.txt