Kyle Benne's profile - activity

It is possible to get the E+ output from the OpenStudio CLI, the OpenStudio App is using the CLI behind the scenes after

Manipulating the connection object directly is not something we support in the OpenStudio Model API. I think Eric is giv

OpenStudio does not have universal support for HVAC components downloaded from the BCL. Only the VRF indoor and outdoor

The bug has been fixed.

Your air handler does not have any zones attached to it. The problem should go away once you add some zones, and if it doesn't then here is the expanded checklist for that error.

I certainly won't rule out a bug, but I haven't been able to reproduce it. OpenStudio does not have special handling or filtering of the exhaust fans from the zone equipment list.

For reference here is the OpenStudio code that generates that part of the idf.

Would you like to share a model with me kyle.benne@nrel.gov for me to investigate further?

There is a problem involving the space in the default installation location. Try reinstalling openstudio to C:/openstudio-2.0.1.

Was this model created using the OS API or did you make it through the OS Application? I'm wondering about the origin of the terminal unit. If it came from drag and drop in the app then it suggests a problem with the App's built in HVAC library.

also.

require 'irb/completion'

then modelObject.<tab><tab>

will cycle through possible methods. This also works if you type part of the method name to narrow down the options.

modelObject.rem<tab><tab>

where tab tab means press the tab key twice.

ah. So you have isolated it to a coil in the unit heater? I do not know of a confirmed bug, but the code is not particularly generic in this area. We have to add a piece of code to check all the types a coil can be in. From your post I was wondering something was added (like UnitHeater) that did not update the containingHVACComponent. I'll take a look at the unit heater related code in particular and see if I see something.

containingHVACComponent is supposed to do the job. But I confess we might uncover a bug here. If you send me a model I'll find it for you if it exists. kyle.benne@nrel.gov.

I think your code is pretty much on point. Here are a couple of thoughts.

coils = model.getCoilHeatingWaters
coils.each do |coil|
  # This is the one method your example didn't check.
  # Since the water coil sits between the air and plant loops, check for both air and plant loops,
  # you might have a half connected coil.
  if coil.plantLoop.empty?
    ...
  elsif coil.airLoopHVAC.empty?
    ...
  elsif coil.containingHVACComponent.empty?
    ...
  else
   # you might get here. In which case the coil might be in the model, but not hooked up to anything.
   # The other possibility is that it is inside a piece of zone hvac or terminal unit that containingHVACComponent
   # does not know about. This would be a bug in OpenStudio if found to be the case. 
  end
end

The other key method I would like to draw your attention to is this...

plants = model.getPlantLoops
plants.each do |plant|
  coils = plant.demandComponents(OpenStudio::Model::CoilHeatingWater::iddObjectType)
  coils.each do |coil|
     ....
  end
end

I filed a bug about setting the model type field, here. I will commit a fix to that issue shortly, but in the meantime until the fix works into the next software release, you can edit the idf manually or with an E+ Measure in OpenStudio.

Sorry I missed the fact that was an osm snippet. The reason it doesn't look consistent with E+ input is because E+ structure has changed since that feature was introduced in OpenStudio. In order to keep the OpenStudio API consistent, we typically handle this kind of change in the OS -> E+ translator, as is the case here. As Eric pointed out, the only valid ground temperature model is "KusudaAchenbach". I think if you switch to that model the E+ idf will look closer to what you expect, however I think I might see a bug in the translation related to setting the model type field.

I feel like I'm not understanding something because the idf snippet does not seem to match the content of the error file you posted. That said there was a change in the structure of this object some time back. The change was handled in OpenStudio by me in this commit. This change has been in OpenStudio since version 1.9.3. Is there any chance you are using an older version of OpenStudio, but using a newer version of EnergyPlus for simulation?

One thing I did notice when reviewing the above linked code change is that while OpenStudio is setting the ground temperature model name, it does not appear to be setting the model type. That might be a lingering issue that nobody has uncovered until now, because this model does not get a lot of exercise.

If you send me, kyle.benne@nrel.gov, your idf I can debug further.

The node configuration you have labeled as "Stream 2 Source Node", "Temperature Setpoint Node", and "Pump Outlet Node" are the OpenStudio defaults. If you leave those input fields blank in the TemperingValve object, as you might have, your idf file will automatically be created with settings like you have illustrated.

You could try overriding the OpenStudio defaults since they were not anticipating a component between the plant mixer and the outlet node. I'm not confident it is the source of your error, but consider adding a setpoint manager to the node immediately after the mixer and then setting the tempering valve's Temperature Setpoint Node field to the node immediately after the mixer. You do this by clicking on the tempering valve icon and then selecting the node name from the drop down menu.

By the way the logic for the OpenStudio default setting is located here in the source code if you would like to inspect it. If you have left empty settings then this logic will fire when OpenStudio creates the idf file.

Ok this issue is now resolved with the following change... https://github.com/NREL/OpenStudio/co...

This will roll out with the upcoming 1.14.0 release.

Yes our current installers require you to provide these libraries. In our upcoming 2.0 installers, we are bundling the required libraries in the OpenStudio package.

@jessep I sent your repaired model back via email.

I repaired your model by doing two things. First I removed three dangling zone exhaust nodes by manually editing the osm file. Second, I removed then re-added the terminals.

The repaired file is here.

I cannot say exactly why these dangling exhaust nodes ended up in your model. The API is supposed to prevent this kind of thing, but there have been past reports of it happening, and not necessarily related to the four pipe induction terminal, but always related to one of the terminal types that have induced air from the zone exhaust. I can say that after repairing your model I am able to remove the terminals cleanly, and add them back cleanly without issue in 1.7.0.

I sorted out the node connection issue related to your terminals in the above linked file, but I found other issues in your plant systems. Some of these may have been intentional on your part, but when I run the model I am seeing run away plant temperature. On your hot water plant I found a chiller which seems a little odd - I replaced the chiller with a boiler. The chiller I removed was connected to a condenser system - I removed this condenser system because it was left with no demand components. The chilled water condenser system had a ground hx on it - I replaced the ground heat exchanger with a cooling tower. The fully modified (and running) model is here.

I will keep an eye on this exhaust node issue. Please report back here if you have any more issues with that.

* Update on 10/28/2016 **

Here is an OpenStudio script I used to repair the model from Jesse Perreault. It might be helpful to other people.

https://gist.github.com/kbenne/109965...

I can take a look. Can you send your model to kyle.benne@nrel.gov?

Yeah I don't have a lot to add here. I think Eric's comments echo my own thoughts pretty well. If folks really want to see AirLoopHVAC.clone built into the OpenStudio SDK I'd pile on in this thread. It is something I've advocated for myself, but never really had the justification to spend time on it. I think it would be great feature for making air system libraries.

In 2.0 we are focusing on making things more compact. To that end we are repacking the Ruby API into a single binary file called openstudio.so which has the all of those dlls and resource files that openstudio.rb depends on, statically linked. We create the .so in such a way that when you require 'openstudio' Ruby knows what to do. Loading a binary file like this is not unique to OpenStudio. This is commonly referred to as a Ruby native extension. Typically people create these types of extensions for performance reasons or to gain access to a large C/C++ API like OpenStudio.

That is not exactly correct. In the OpenStudio 1.x series, openstudio.rb is the entry point to load up the API. I say entry point because openstudio.rb does not contain hardly any of the actual API methods. Instead openstudio.rb just loads up a series of dlls and resource files that encapsulate the core C++ API and make it available in Ruby.

In other words the vast majority of the OpenStudio API is not implemented in ruby (.rb) files at all. OpenStudio Ruby API is a big "native" extension writing in C++ and exported to ruby.

You might start learning your way around the OpenStudio API by reading select portions of the Measure Writing Guide. Much of this is specific to using the OpenStudio API inside the structure of a "measure", but there is some content that will explain the API itself. From the link, pay particular attention to the section titled "What Methods Are Available".

The API is ground zero. You will probably need to devise your own scheme to expose this API through a web service that meets the needs of your application. With any luck there are people in this community who can share their experiences in this area.

Karthick has an early build of OpenStudio 2.0 from me. The openstudio.so he is referring to here is the OpenStudio ruby bindings as they have always been, just packaged up in a single portable binary file called openstudio.so. In Ruby,require 'openstudio' works the same as it always has with this package, it is just much more compact with no more external dependencies.

Knowing that openstudio.so is just the OpenStudio Ruby bindings of the future perhaps folks can chime in with any experiences building web application on the OpenStudio SDK.

Yes there is. The standard OpenStudio installer for Windows is created by the NSIS installer tool. These installers have a built in command line interface to install silently. All you need to do is pass the /S option.

$ .\OpenStudio-1.12.0.ef50b89958-Win64.exe /S

You can also pass /S /D=C:\Custom\Install\Path if you want to install to a custom path. You should be an administrator to run this command or you will probably get a Windows prompt to authenticate. Finally note that the installer command returns almost immediately however know that the work is still being done in the background. If you watch the install directory you will see that files are still being installed several seconds after the command has returned.

The availability schedule of a fan in the context of AirLoopHVAC is ignored by design in OpenStudio. This is to avoid conflicts and confusion with the availability schedule.

The logic that is enforcing this behavior is located here, where OpenStudio converts the osm model into energyplus idf.

This is a little misleading on OpenStudio's part because it is showing the availability schedule in the inspector. This is because in the context of ZoneHVAC the fan availability schedule is in play, and the inspector policy that controls what fields you can access is not currently designed to be conditional based on the context of the fan you are looking at. Ideally OS would show the fan schedule when viewing Zone HVAC and not show it when you view a fan in AirLoopHVAC.

If there is a particular use case that OpenStudio's behavior is blocking, then I would like to hear more about what you are trying to accomplish.

I've filed a bug and will make fixing this a priority.

https://github.com/NREL/OpenStudio/is...

I reviewed the model sent to me offline and I believe this is a bug in the clone method for the coil. I have filed a bug here.

require 'openstudio'

m = OpenStudio::Model::Model.new
plant = OpenStudio::Model::PlantLoop.new m

splitter = plant.supplySplitter
mixer = plant.supplyMixer

branchInletNodes = splitter.outletModelObjects

branchInletNodes.each do |node|
  # get the components between the branch inlet and the mixer
  branchComponents = plant.supplyComponents(node.to_Node.get,mixer)
  # the last component is going to be the mixer so pop it off
  puts branchComponents
end

@rraustad any ideas here? Julien and I talked about this offline, but I didn't have any suggestions.

The page load times seem to keep getting longer. Is the server getting saturated?

I think these are two independent issues. For the HPWH I think you have found a bug, because I don't think we have a test for the HPWH located outside, only inside the zone. I have filed a bug here.

For the no air flow issue, if you don't have an oa requirement then you are going to need a zone load to request flow and get things moving. Do you have a thermostat in your zone? Is there load on the zone?

Yep. It is done now.

Those node names are certainly obnoxious. They happen when a node isn't explicitly given a name. In other words they are the guaranteed unique name generated by the low level OS gears. I've tried to root many of them out, but obviously some remain. Generally they are related to internal nodes of zone hvac, terminals, and unitary systems. You shouldn't need to interact with them often.

Automatic node naming is tough. If we set the node name to a derivation of the system name, what happen when you change the system name? What if you write your own custom name that you want to stick?