Adding different HVAC systems

Erikbeeren · April 20, 2021, 8:37am

When adding different HVAC systems to different rooms, rooms get multiplied. In the rest of the workflow (adding programs, assigning constructions) aligning properties with rooms works perfect. Is it possible to implement this also here?

Asisnath · April 20, 2021, 9:15am

Hi @Erikbeeren what if we graft the input values before attaching that to room. Do we still get 9 rooms?

Erikbeeren · April 20, 2021, 9:18am

Thanks @Asisnath that was the one.

chris · April 26, 2021, 9:29pm

I just wanted to add an explanation for why we make you graft the data here. Many times, you want to assign the same HVAC template to a group of rooms. For example, I have a 4 story building and each story is composed of 33 Rooms but I want each story (or group of 33 Rooms) to get it’s own VAV air loop. Doing this is easy with the current setup of the component:

FYI, the Honeybee HVAC templates are smart enough in this case that they will give a separate air loop to each story but connect everything together on the plant side, which is almost always what you want.

Erikbeeren · April 28, 2021, 8:42am

Hi @chris,

I have still some problems with adding different HVAC systems to a building. Somehow the data is not interpreted in the right way by OpenStudio.
In a old hospital we want to define 17 seperate airloops.
I wanted the give a name to every airloop so they are recognisable. (see input below)

In open studio I now expect 17 airlops with the appropriate names added to it.
The 17 airloops are generated but the names are messed up.
Then it is difficult to find out which airloop belongs to which group of rooms.

chris · April 28, 2021, 4:09pm

Nice! 17 air loops! Always pushing the scale limits.

Your data trees all look correct and it sounds like the simulation is executing correctly but, yes, that looks like a bug with the names. In all likelihood the bug has something to do with these lines of code and me not understanding something about the OpenStudio SDK or standards gem:

github.com

ladybug-tools/honeybee-openstudio-gem/blob/master/lib/to_openstudio/hvac/template.rb#L80-L93


# create the HVAC system and assign the display name to the air loop name if it exists
os_hvac = openstudio_model.add_cbecs_hvac_system(standard, equipment_type, zones)
os_air_loop = nil
air_loops = openstudio_model.getAirLoopHVACs
unless air_loops.length == $air_loop_count  # check if any new loops were added
  $air_loop_count = air_loops.length
  os_air_loop = air_loops[-1]
  loop_name = os_air_loop.name
  unless loop_name.empty?
    if @hash[:display_name]
      os_air_loop.setName(@hash[:display_name] + ' - ' + loop_name.get)
    end
  end
end

Can you upload a file with the minimum that’s needed to recreate this issue and I’ll investigate?

FYI: I still have not forgotten about the other bug that you found here. It’s just that you are a pioneer in terms of the scale of some of these models and so you have found some bugs that no one else has. I promise I’ll get them all investigated and fixed as best I can over the next month.

Erikbeeren · April 28, 2021, 4:19pm

FYI I also checked the output of the HVAC component. Here everything seems to be done correctly.
You can find the HBJson object in the 7z file.

testHVAC.7z (174.3 KB)

chris · April 28, 2021, 4:30pm

Thanks @Erikbeeren .

Looking at my code now, I am pretty sure that OpenStudio SDK getAirLoopHVACs method just returns the air loops in an unordered list. Man I really wish the OpenStudio SDK had documentation about all of these idiosyncrasies somewhere. In any case, I think that I should be able to fix this quickly if I can find a better way of pulling the correct air loop from the model.

chris · April 28, 2021, 6:37pm

Ok, I just merged a fix:

It seems to be working correctly with your model:

Thanks for reporting this one, @Erikbeeren . Let me know if you experience any other issues like this.

Erikbeeren · April 29, 2021, 6:34am

That was realy quick! Thank you @chris

Erikbeeren · April 29, 2021, 6:53am

For the other bug (IntersectMass): We now use the intersectMassII component. It works fast and it is very reliable. As it acts just befor rhino geometry is turned into LBT geometry, there is no problem combining them and use them in one pipeline.