Calibration values are different in PAT than OS app (AKA IDF sort order)

[DavidGoldwasser]

Not huge difference, but more than rounding error. I do not have any always run measure on the baseline. This is with installed version of 1.1.1 run locally.

[DavidGoldwasser]

Just an update I made some changes to the baseline model,but this time I'll show both the side by side calibration view from OS app and PAT, and the ABUPS end use table. It does appear the simulation results have changed. In another post I'll try to diff the IDF's (we'll see how well sorted they are).

In OS app total site energy is 75.87 GJ In PAT same model is 76.23 GJ (not an insignificant difference)

[evanweaver]

It is my expectation that the values received from the backend are really different between the 2 software packages. That is, I believe that it is highly unlikely that the GUI number formatting is the root cause of the discrepancy that you have noticed.

[DavidGoldwasser]

@macumber OSM file and two resulting IDF's are on network Y:\5500\5500 HPBldg\davidg

I used an AMY weather file and a partial year run, but wouldn't expect that to be an issue. We had a old issue with varying simulation results in the past. Not sure if it was open or not, but it was running multiple of the same design alternatives and seeing different results. I have not had a chance yet to run the IDF's from the zip through EP Launch. The idea being to confirm if the issue in in translation, or if it is how something is happening after that.

[DavidGoldwasser]

FYI - running the IDF's through EPLaunch produced the same discrepancy. So it does look like an IDF sort order issue. In a quick compare the main order change I saw was some internal mass objects. Other than that there were unique UUID values for objects like schedule week.

[Myoldmopar]

I haven't confirmed anything, but I have a suspicion of what is causing some of this. Initially it seems the order of objects in the idf shouldn't cause differences in results. The input processor reads the entire idf at once so that is hidden from the simulation code. However, some order is still maintained within the code. Individual managers and simulation models still keep an array of objects. For zones, this could be an array of surfaces, or an array of zone hvac equipment objects. For air loops, it could be an array of coils spread around the HVAC system.

For HVAC and plant equipment, the simulation order is determined based on control logic (component staging) and loop topology (flow-wise simulation). Thus, the order found in the input file won't have an effect, as long as it results in the same loop topology and control logic.

In zones, the simulation will loop over all surfaces in the zone. The order is just the order they sit in the array, which is likely just the order they were retrieved from the input processor, which will be the order they exist in the input file. If the simulation model is looping over surfaces (such as the internal mass objects mentioned above), and converging on a specified condition, it is possible that convergence will be attained slightly different from one order to another. This could cause these small diffs. I wouldn't expect more than 1-2 percent, but it could be more sensitive in specific cases.

One test you could make for this specific case is cranking down the convergence tolerance for zones/surfaces, and see if the results come together. Would be interesting to confirm.

[macumber]

@DavidGoldwasser @Myoldmopar I think the issue with order of internal mass objects is specific to this model, I was not able to reproduce that issue with a model having simpler geometry. The images below show the model David was working with, he had shading set to FullExterior. Somehow changing the order of internal mass objects in this model changed results, somewhat not surprising because the zones (specifically the big green zone) are fairly complex and are not convex.

[macumber]

@DavidGoldwasser @Myoldmopar , I finally tracked this down. Here is the substantial difference between the two models:

outOSApp.idf:

InternalMass, Interior Partition Surface 2, !- Name 000 Interior Floor, !- Construction Name Thermal Zone: First Floor - Plus, !- Zone Name 24.1250323950002; !- Surface Area {m2}

out_PAT.idf:

InternalMass, Interior Partition Surface 4, !- Name 000 Interior Ceiling, !- Construction Name Thermal Zone: First Floor - Plus, !- Zone Name 24.1250323950002; !- Surface Area {m2}

The first model uses floor for the construction of this internal mass object and the second model uses ceiling. My fix will prevent this, however it is not the best way to determine which construction to use for the internal mass. Maybe we should add a surface with 1/2 area for each construction?

[DavidGoldwasser]

@macumber good catch. This brings up an old issue. What is the proper area for the internal mass object in this situation. If EnergyPlus only treats on side of the area as exposed, but in reality both sides are exposed, should the area be doubled? but if we do that we have too much mass, but the right amount of exposed area? Or is there another option.

This is probably in the weeds, but something to look at some time. I think the fix you implemented is probably fine for 1.1.3. It is a bit of an edge case, and probably only happens when stacked spaces are part of a zone, as internal walls are typically modeled as symmetrical constructions.

Should I close this after I test your fix, or do you want to leave this open for a future enhancement.

[macumber]

@DavidGoldwasser I think we should close this for now but make another ticket to discuss this with Edwin and figure out a better approach