First time here? Check out the Help page!
1 | initial version |
You can read an OSM file similar to an IDF file. The OpenStudio Model mirrors EnergyPlus input objects fairly closely.
One of the biggest differences is the "long string of {alphanumeric-string}". These are UUIDs which allow each object to be universally unique. In EnergyPlus, the object's name must be unique among all similar types of objects. OpenStudio takes this further and makes all objects universally unique through the UUID. This is advantageous when you bring objects from another model into your model through clone
. If these two objects had the same name then in EnergyPlus you would get an error.
In EnergyPlus you can reference other objects within a parent object, for example a unitary system references a heating coil and cooling coil. In EnergyPlus, you put the name of the child object in the parent object field. While in OpenStudio, you put the child UUID, or handle, in the parent object field.
Unlike eQuest and EnergyPlus, manipulating the OSM file directly is usually fraught with danger. Any time you create a new object you need to generate a new UUID and it must be universally unique otherwise bad and undefined things can happen. What this means in practice is that you should use the OpenStudio App, plugin, measures, or API bindings to interact with your OpenStudio model. These approaches make sure the model is generated correctly as well as provide helpful abstractions over the more tedious parts of EnergyPlus (connecting nodes in HVAC systems for example).
I would advise against "working/operating only on idf files and import/export these as needed" IF you are wanting to use these within OpenStudio. OpenStudio does not import all EnergyPlus objects, especially HVAC systems. It is best to stay within OpenStudio if you want to use OpenStudio.