Setpoint manager DOAS templates

Hi @chris,

We are running now quite some simulations using the standard HVAC templates. The Idea of keeping it simple we like very much. There is only one thing which gives us structural problems with the results and that is the predefined setpoint manager of the DOAS system.

With higher ventilation rates, rooms get cooled or heated more than actually needed. with a setpoint of lets say 19 [C] for heating the room temperatures in winter still get up to 21/22 [C].

If I look at the incomming air overview the answer is clear:

I know Matthew Dahlhausen has made these templates, but is it somehow possible to add the option for a setpoint manager input in the standard templates? This would save us the need to re-running the simulation.
210602_Basis_main_model.7z (189.5 KB)

Hey @Erikbeeren ,

If you really wanted the templates themselves changed (or to understand why the setpoint manager has those default values), you really need to take it up with Matt by opening an issue on the openstudio-standards Github:

I really don’t want to expose loop setpoint temperatures on the LBT end since it will make the templates more fragile in the event that the setpoint manager for the standards gem DOAS systems ever change. It also makes it easy for people to create systems with nonsensical controls, meaning that it’s more of a job for ironbug than it is for these HVAC templates that are trying to be mostly foolproof.

If all that you want to do is tweak the setpoints, this really seems like a job for a measure. It’s really only going to take a few lines of Ruby with the OpenStudio SDK to grab the setpoint managers and change their setpoints. So that’s my best suggestion if you need a quick fix for the time being.

1 Like

Hi @Erikbeeren ,

I am happy to say that I have implemented something that should greatly lower the learning curve for making use of the OpenStudio SDK. After recognizing how difficult it is to put together even a simple OpenStudio Measure because of all of the boilerplate code involved and the difficulty in setting up the dev environment, I have added a module that allows you to load and dump OpenStudio models from and to .osm files.

So this is all of the code that you need in order to change the setpoints that you noted here:

from ladybug_rhino.openstudio import load_osm, dump_osm

# load the Model from the OSM
model = load_osm(_osm)

# get all of the SetpointManagers and set their properties
setpt_managers = model.getSetpointManagerOutdoorAirResets()
for setpt in setpt_managers:

# save the edited OSM over the original one
osm = dump_osm(model, _osm)

… and all that you have to do it copy/paste this code into a GHPython component like so: (63.7 KB)

Importantly, this new module IS ONLY AVAILABLE IN THE LATEST DEVELOPMENT VERSION OF THE PLUGIN that you get with the LB Versioner but it will be in the LBT 1.4 stable release. Also, the code above ONLY WORKS ON WINDOWS for now but we should eventually be able to support it on Mac.

I think we’ll also eventually add some routines to turn any GHPython component like this into an actual Ruby measure since this would make it easier to use this type of custom functionality outside of Grasshopper (eg. on Pollination). The only thing that’s needed for such a routine is to add the boilerplate Measure code and to translate the “real” code from Python to Ruby. So the rules for this would be that everything in the component would have to be using only native Python operators without any special modules (other than the OpenStudio SDK, of course). Also, the type hints would need to be set correctly on the component. But it seems like a lot of the custom things that people want to do are small tweaks like the setpoints here. So it would be easy enough to take a component like this and automatically make a measure from it.


THANKS @chris! A Realy helpfull feature!

Hi @chris,

I downloaded your file, installed Openstudio 3.3 but now the following error came up:

Hi @Erikbeeren ,

Thanks for letting me know. I wasn’t able to recreate the issue on my end and everything is working fine with OpenStudio 3.3:

It’s odd behavior like this that has made me recommend that people write measures in Ruby rather than trying to interact with them directly using IronPython as we are here. Invariably, editing the OSM like this is going to be a solution that doesn’t work on all machines and it’s really meant to be a stepping stone for people to write real Ruby measures.

Still, I think I know of a change that might solve this particular case for you. I just pushed it here:

You should be able to get the change on your end with the LB Versioner in an hour or so. Let me know if this solves the issue.

1 Like

Hi @chris,

Still the same issue.

Hi @Erikbeeren ,

It looks like you didn’t load in the updated libraries since it’s failing on the same line of code as last time. If it were to fail on line 49 instead of 46, then I would know if the new solution was not working.

Are you sure that you restarted Rhino/Grasshopper after running the LB Versioner?

Hi @chris,

Yes I restarted Rhino after running the versioner. I synchronised the gh file you sent me, but still having the same issue. It looks like the folder and the are updated. (74.5 KB)

Hm. I am having difficulty figuring out what is going wrong for your case here.

Am I correct that you are not able to use the Legacy honeybee plugin to run OpenStudio simulations on your machine? The methods that I am using to manipulate the OpenStudio model here are the exact ones that we used in Legacy. Would it be able to confirm this by installing OpenStudio 2.9.1 in its default location and trying to run a Legacy sample file like this one?

Maybe it’s also worth a shot at just uninstalling your current OpenStudio that you’re using for the LBT plugin and then reinstalling it. Something clearly seems to be wrong with the OpenStudio C# bindings that are on you machine. Is this what your OpenStudio C# folder looks like?


As @chris pointed out, OpenStudio installer doesn’t install all the following DLLs in the same CSharp folder. You will have to manually copy all of those files from “lib” folder to here, or use our installer.

Hi @MingboPeng

This looks correct. The .dll are in the right folder. The only difference I see are that the .lib files are also in this folder.

The lib folder contains the following files:

@chris Legacy runs fine on my machine

Thanks for confirming @Erikbeeren, and for being patient while we test a few solutions.

I think I know what is causing the issue. I realized that we had been appending the whole OpenStudio C# folder to the IronPython path when we imported the C# bindings in Legacy. It’s possible that everything has been working on my machine because I already had this appended from earlier simulations.

I just pushed a change to the ladybug-rhino package that ensures this appending happens as part of the OpenStudio import process:

So, @Erikbeeren, can you run the LB Versioner, restart Rhino, and then tell me whether the original sample file works for you? :crossed_fingers:

Sorry that it’s taken a few iterations to nail down exactly what is going wrong.

FYI, @MingboPeng , I set up these modules that Erik is using to automatically copy the missing .dll from the lib folder when it isn’t found. So, assuming that my current fix makes everything ok, then components using the OpenStudio C# bindings with these modules should be able to work on several people’s machines, regardless of how they installed OpenStudio.

3 posts were merged into an existing topic: Ironbug Beta Release (outdated)

Hi @chris,

Unfortunately I am still getting the same error. However I noticed something else. After Updating and restarting Rhino, the documents and files in the Ladybug_tools folder do not change. The latest date is from 07-12-202.
I tried to update Ladybug tools for several times, but without succes.

Man, this is a tough one. You’re not running the sample script that I sent while you have any Legacy components on any of your Grasshopper canvasses, right? I imagine that could interfere with loading the C# bindings like this.

I might recommend completely uninstalling Legacy and the older OpenStudioa associated with Legacy just to make sure that this isn’t interfering.

I should also ask how you installed OpenStudio. Did you run the executable to install it in ladybug_tools/openstudio or did you manually copy it from somewhere?

If uninstalling Legacy still doesn’t work, can you open the following Grasshopper definition, run the component for the setpoints and let me know the printed output like so: (54.2 KB)

Another possible explanation is interference from IronBug so make sure that you don’t have any IronBug components on any canvases while you are running the sample script. If this is, in fact the issue, I should be able to tell from the output of the component in the screenshot I posted.

Hi @Erikbeeren, I tested @chris’s uploaded above, it works all fine with both Ironbug enabled and disabled. Meanwhile, I have the legacy installed as well.

So here is all that has been loaded to the Grasshopper on my side:

  1. LBT Honeybee uses: ladybug_tools/openstudio folder to load OS3.3
  2. Legacy plugin uses: C:\openstudio-2.5.0
  3. Ironbug loads OpenStudio from: C:\openstudio-3.0.1

Since each version of OpenStudio’s DLLs has its own signature, they won’t really conflict with each other in the same Grasshopper environment.

I am confident that @chris’s workflow would work as expected. Now I am thinking about the installation issue of OpenStudio. Have you tried to use our Pollination GH plugin’s installer: Pollination Grasshopper Plugin, which should help you solving with the most installing issues with the LBT plugin.

Please let us know if this works.


Hi @chris and @MingboPeng,

Sure a tough problem. I tried first to run “”. This gave the same error. Then I used the polination installer. Still the same problem. After disabling Ironbug it finaly worked. :smiley:

It could be that I have still an old version of Ironbug:


On the C-drive only Openstudio 2.9.1 is installed:


Thank you for all the help!

1 Like