MMV not working for HotelLarge

[nheeren]

The function mmv.get_zone_number() fails when trying to run HotelLarge.idf with MMV. The actual problem seems to be that change_idf_objects() looks for Mech_Flr_1 in zone_dict_hvac.

https://github.com/nheeren/BuildME/blob/d8df6bdfb0037339d2a18647cab73cde48a0e6cf/BuildME/mmv.py#L257

I wasn't fully able to grasp the problem. I believe Mech_Flr_1 is in the zone_dict_**non**_hvac and the script shouldn't look for it in zone_dict_hvac anyway. Can you have a look at this @kamilitsa ?

The full error:

Traceback (most recent call last):
  File "/Users/n/code/BuildME/main.py", line 83, in <module>
    run_new()
  File "/Users/n/code/BuildME/main.py", line 13, in run_new
    pre.create_mmv_variants(comb=settings.debug_combinations)
  File "/Users/n/code/BuildME/BuildME/pre.py", line 66, in create_mmv_variants
    idf_mmv = change_archetype_to_MMV(idf_f, occ_type)
  File "/Users/n/code/BuildME/BuildME/mmv.py", line 31, in change_archetype_to_MMV
    idf = change_idf_objects(idf, xlsx_mmv, zone_dict_hvac)
  File "/Users/n/code/BuildME/BuildME/mmv.py", line 257, in change_idf_objects
    zone_no = get_zone_number(zone_dict_hvac, obj.Zone_Name)
  File "/Users/n/code/BuildME/BuildME/mmv.py", line 326, in get_zone_number
    zone_number = list(zone_dict_hvac.keys())[zone_list.index(zone_name)]
ValueError: 'Mech_Flr_1' is not in list

Also, could you maybe make sure I didn't do anything stupid in d8df6bd?

[nheeren]

It is possible I haven't pushed all necessary changes yet for running HotelLarge.idf. Please let me know if anything is missing / unclear.

[kamilakrych]

The solution is very simple - it is written as a comment in the code (maybe it should be caught as an exception and displayed to the user). See line 71 of the mmv.py: # if no people in the zone, MMV cannot be implemented -> zone is treated as non-hvac

The zone called Mech_Flr_1 simply doesn't have a 'People' object assigned to it. The solution is to add it 😉

[nheeren]

Thanks. So why isn't it treated as non-hvac as the comment says, but raises an error?

[kamilakrych]

Oh, good question 😅 That's because later on I assume that all IdealLoads objects are hvac-zones. I'm going to add a patch now.

[kamilakrych]

Should work now with the fix I added in my branch!

Edit: There's sth more missing, trying to figure it out now...

[nheeren]

Excellent. I merged it.

[nheeren]

Damn – overlooked your edit

[kamilakrych]

Okay, I found the bug - there were actually a few of them. I fixed them all, so the MMV routine is okay now (I tested it a few times).

However, the replace.xlsx file needs some improvements. After I resolved the MMV issues, I was still getting weird results for this HotelLarge archetype - the cooling for the MMV decreases compared to HVAC (as expected), but the heating increases A LOT (see below, scaled to 100%).

It took me a long time to find out the reason. It turns out the issue was the replace.xlsx file, which sets no infiltration (ACH=0) for all energy standards of HotelLarge archetype. And I happened to test it using 'non-standard' one which gave huge differences....

[nheeren]

Great! I will merge now.

Yeah. Ventilation still needs a good solution. I never found an easy way to represent air-tightness in another way, unfortunately.

[nheeren]

Oh. I see now. Sahin's script has fixed the infiltration rates to zero.

[nheeren]

A bit unrelated, but can you confirm that MMV-files were only created if they were missing? I changed that in c9666b4, because calculation is speedy and changes in the (non-MMV) file would not carry over otherwise.

Do you agree with this change?

[kamilakrych]

Yes, that's right! So now they are calculated at the beginning of every simulation run, so that if we have e.g. 12 combinations of the same archetype, it would only convert it once and not 12 times? If this understanding is correct, then I definitely agree :) Sounds like a good trade-off!

[nheeren]

Yes. Exactly what happens now. But now I realize replace_mmv.xlsx gets appended over and over again. It should also be deleted every time, right? See also cab33c2.

[nheeren]

@kamilitsa

However, the replace.xlsx file needs some improvements. After I resolved the MMV issues, I was still getting weird results for this HotelLarge archetype - the cooling for the MMV decreases compared to HVAC (as expected), but the heating increases A LOT (see below, scaled to 100%). It took me a long time to find out the reason. It turns out the issue was the replace.xlsx file, which sets no infiltration (ACH=0) for all energy standards of HotelLarge archetype. And I happened to test it using 'non-standard' one which gave huge differences....

So I changed the Air_Changes_per_Hour values in replace.xlsx to reflect the ones from the RT, but the result was absolutely identical. Therefore I implemented the following, because I thought the old values were still in replace-mmv.xlsx.

@nheeren

Yes. Exactly what happens now. But now I realize replace_mmv.xlsx gets appended over and over again. It should also be deleted every time, right? See also cab33c2.

But again I get exactly the same results, i.e. very high heat demand. Are you sure that is the reason?

[kamilakrych]

Yes. Exactly what happens now. But now I realize replace_mmv.xlsx gets appended over and over again. It should also be deleted every time, right? See also cab33c2.

Yeah, it makes sense to delete it together with the -auto-MMV.idf files.

So I changed the Air_Changes_per_Hour values in replace.xlsx to reflect the ones from the RT, but the result was absolutely identical. Therefore I implemented the following, because I thought the old values were still in replace-mmv.xlsx.

But again I get exactly the same results, i.e. very high heat demand. Are you sure that is the reason?

Infiltration might partly be the reason (make sure that replace.xlsx also changes the calculation method to changes per hour). But I found another thing, it's something bigger and also hotel-specific. The original HotelLarge.idf file has a complicated chain of objects decreasing the heating demand depending on e.g. if the room is vacant (see the schedules with setpoint values below). On the other hand, the MMV algorithm sets the heating and cooling setpoints to fixed 21 and 25 degrees. Quite sure it makes for the difference, not sure how to fix it though.

[nheeren]

• [ ] make sure that replace.xlsx also changes the calculation method to changes per hour

Will check...

But I found another thing, it's something bigger and also hotel-specific. The original HotelLarge.idf file has a complicated chain of objects decreasing the heating demand depending on e.g. if the room is vacant (see the schedules with setpoint values below). On the other hand, the MMV algorithm sets the heating and cooling setpoints to fixed 21 and 25 degrees. Quite sure it makes for the difference, not sure how to fix it though.

🤦 Oh no. I am going crazy facing so many edge cases with the different archetypes... Thank you for investigating!

[kamilakrych]

Some updates :) I have looked into this issue for real now. The archetype is complicated, so it was very difficult to pinpoint what was causing these issues with MMV. Finally, also thanks to discussions with @shnkn, I was able to find the problem.

The issue is fixed now, and it was done in 2 parts:

1. Fixing a small bug in the code, which was causing doors to be permanently open in the MMV archetype, making the air change rates very high

2. Adjusting the HotelLarge archetype, i.e. deleting a few windows which were causing high air change rates in two zones. This is a very primitive fix, but fast 😉 Read below for more details. @nheeren I hope such a brute-force solution is fine for you?

   Details on the HotelLarge archetype The archetype has a very specific geometry: we have two zones called "corridor" which have both northern and southern walls with windows (windows are marked in cyan in the screenshot below). The result is a very strong cross-ventilation, possibly also enhanced by the long corridors in between the windows. Please note: we're talking about high ACH caused by infiltration through cracks etc., not related to opening windows.

I don't have enough knowledge on building design and regulations, but possibly zones with such a design would have stricter rules on airtightness to avoid excessive cross-ventilation. The airtightness values that work in "normal" zones seem just too high in this one. Two solutions to this: 1) to create some exceptions in the MMV routine, detecting zones with such geometry and increasing the airtightness there, 2) edit the archetype and delete windows (most of the airflow is caused by cracks around windows). So far I went for the second, simpler one.

[kamilakrych]

And just some proof that the issue is fixed :) MMV slightly increases the heating demand (this is difficult to completely avoid also in other archetypes) but the overall energy demand is decreased

[kamilakrych]

Okay, forget everything I said above. I have tested this issue on a few other archetypes, and thanks to that I was able to identify a serious bug (and eventually fix it). In some archetypes (but not in the SFH or MFH that I mostly used for testing), there were zones which could not be classified as "MMV zones", i.e. the procedure with operable windows could not be implemented. In such zones, windows were set as constantly open!!! Hence the high ACH in these zones.

In the newest commit I fix that. The solution has been tested on several archetypes. And I also revert the deleting-windows-in-HotellLarge commit as well...

Anyway, case closed. Finally!

[nheeren]

🙏 Thank you so much!!