I have downloaded the new Honeybee.
It really looks good.
In a previous post (see link above) you mentioned that other side coefficients would be possible to ad to constructions with this new version.
Is this already possible or is it still in development? I could not find it in the “construction” components.
It is still under development but I know exactly how it should be implemented (and how it should be exposed on Grasshopper components). I opened an issue that you can use to track if I make any progress on it:
There are some other higher priority things I need to tackle first but I’ll get to this eventually.
2 years is a long time to wait for this so I’m going to see if I can implement it quickly today. Just to make sure that what I am implementing will be able to satisfy your needs, I’m planning to only expose the following parameters, which will both be optional:
constant temperature on the other side of the geometry
convective/radiant coefficient on the other side of the geometry
If the constant temperature is not provided, the outdoor temperature will be used. If the convective/radiant coefficient is not provided, it will be set to zero.
If this those two parameters are all you need, I should have it by the end of today. Otherwise, if you badly needed some of the other inputs, I could probably add them except for the temperature schedule, which would really complicate things (for that, I would just write a custom post-processing component with the OpenStudio SDK).
You’ll be able to get the new capabilities and component with the LB Versioner in an hour or so. After that, you’ll be able to create boundary conditions with a constant temperature on the other side, which you can assign to Honeybee Faces like so:
I apologize for bringing this issue up again several years later.
Recently, I have received more and more requests regarding the coupling of indoor and outdoor thermal environments. There are many indications suggesting that some users can obtain relatively accurate building surface temperatures through certain CFD methods, and this temperature output is based on a time series.As far as I know, the open-source solver urbanMicroclimateFoam (UMCF) of OpenFOAM can achieve this.
That is to say, if this “Schedule” option can be made available, it might further enhance the connection between LBT and other tools.
I know it’s quite challenging, but I still would like to know your current perspective on this matter.
Technically speaking, assigning a schedule of temperature values is far easier to do by post-processing the OSM output from the “Model To OSM” component using the OpenStudio SDK like what you see here.
So you could set up your honeybee model using the regular-old “Other Side Temperature” boundary conditions and then make a component that takes the resulting OSM, adds your various schedules for temperatures, and then post-processes the other side boundary conditions already in the OSM to use these schedules.
You can see here in the honeybee-openstudio source code that the “Other Side Coefficient” objects get named using the identifier of the parent Face (just with _OtherTemp added to it):
So you can use this to match specific “Other Side Coefficient” objects to their corresponding schedule if you have one schedule-per-face or something like that.
If you try doing this on your own and you hit a road block, let me know and I can help you out if you provide me with a sample .gh file with your temperature schedules and corresponding geometry in it.
But I’m pretty confident that changing honeybee-schema for this purpose is not worthwhile at the moment. It just makes too much of a mess of the honeybee source code and also makes it more complicated for other software developers to use honeybee-schema while only addressing a small fraction of simulation use cases. Or, maybe a better way to put it is that the people with these types of simulation use cases (like yourself and others running OpenFOAM simulations) are usually advanced enough to try alternative strategies for getting the E+ simulation the way that you want (like editing things via the OpenStudio SDK). So I want to make sure that we have thoroughly tried the alternatives before considering schema changes.