BEopt v3 MF modelling?

asked 2023-01-18 14:00:17 -0600

jpierce's avatar

updated 2023-05-09 07:07:40 -0600

There's a line on the BEopt web page describing the removal of modelling multifamily buildings as a new "capability"

The switch from modeling entire multifamily buildings to individual dwelling units

But I seem to be missing something, because I don't see how this helps the user. Are we now expected to generate separate model files to evaluate each apartment in a 30-unit building? How is that supposed to work for optimization, where (more or less) uniform options (esp. shell) should/would be used throughout a building? BEopt v2.8 already generated unit-level and building-level results,** and it's not clear from this description or the help file how one is meant to obtain equivalent behavior/results from version 3 without a lot more effort.

However, even with much more effort by the user to model each unit, I don't see how one can readily synchronize the optimizations across units... After all a top floor corner unit could optimize to have much more continuous wall insulation compared to a middle floor unit with only one exposed wall, yet you wouldn't want the wall detailing to vary from unit to unit, it would make for a very funky facade. The current per-unit approach also seems to mandate that every apartment have an ambient door, whereas in a building-level design under v2.8 it was possible to have entry via access corridors, which is much more common in larger buildings or colder climates.

** The latter being much more useful IMHO, but both were there to suit everyone's needs.

Edit: You can set the number of modeled doors to zero, which is roughly akin to it being adiabatic rather than ambient. This still does not solve the broader issue however,

edit retag flag offensive close merge delete

Comments

I am curious to understand the appropriate way to utilize the new MF functions for analysis. How should I separate a duplex and which MF zones should I select? @shorowit

  • Here is a model in v3 that results in error codes
  • 1.xml: Error: Expected InteriorAdjacentTo to be 'living space' or 'attic - vented' or 'attic - unvented' or 'basement - conditioned' or 'basement - unconditioned' or 'crawlspace - vented' or 'crawlspace - unvented' or 'crawlspace - conditioned' or '
muhl's avatar muhl  ( 2023-02-20 15:45:00 -0600 )edit

@muhl Sorry, I missed your question. Here is an example of how I recommend you model this duplex, and it runs successfully (at least in BEopt 3.0.1, I didn't try in BEopt 3.0.0).

shorowit's avatar shorowit  ( 2023-03-28 12:46:02 -0600 )edit

@shorowit It seems that the difference in the models is to treat all spaces as adiabatic for the adjacent duplex, except for the unfinished basement space. Is there any reason why the attic is treated differently than the basement?

muhl's avatar muhl  ( 2023-04-10 13:41:50 -0600 )edit

I'm afraid I don't understand your question, @muhl. In what way are you seeing that the attic is treated differently than the basement?

shorowit's avatar shorowit  ( 2023-04-17 12:34:06 -0600 )edit

@muhl Adiabatic means "same temperature," so one large unconditioned attic is the same as an unconditioned attic next to an "adiabatic" attic. Having the "x to adiabatic" for spaces other than the attic splits the other unit off. But an unconditioned attic has no special impacts, so there's no need for it to be split. Moreover, the new 2019 RESNET standards do not include an "unvented attic adjacent to adiabatic" option, therefore it's all just unvented attic. On the other hand, there is unfinished basement to adiabatic, unfinished basement to conditioned basement, etc.

jpierce's avatar jpierce  ( 2023-04-18 11:32:06 -0600 )edit