"Reading" .osm files

openstudio

asked 2015-09-15 12:13:00 -0500

All; Question I have had while learning OpenStudio is how have others gone about 'reading' the .osm files? In the past we have opened eQuest's .inp files in notepad++ and can 'read' these files to determine what is going on with constructions/spaces/hvac/etc. Example EnergyPlus .idf files that I have found/used are similar, with some [anticipated]changes in keywords/syntax/etc. But still 'readable' in determining what the code is doing. I have either not figured it out or not looked in the right place to be able to 'read' .osm files. I see the defined object[s], and the "! comments" explaining what the input is, but the actual input values are just a long string of {alphanumberic-string}. Can any one comment to what any of this means? OR a 'translator' that makes this usable by us mere mortals? Is this she wrong path and we should work/operate only on idf files and import/export these as needed? Thanks in advance for any & all assistance - DA

edit retag flag offensive close merge delete

add a comment

answered 2015-09-15 12:47:41 -0500

MarkAdams
1845 ●2 ●9 https://github.com/mbadams5

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.

edit flag offensive delete link

Comments

Loosely related to this there is a measure on BCL that will compare two OSM models. it ignores the UUID and diffs the human readable names and fields. This is very useful when you are using measure to create your model, since running the measures twice results in different UUID's for objects.

David Goldwasser ( 2015-09-15 15:18:18 -0500 )edit

Well, it is good to know that I hadn’t lost my mind when opening the .osm files in notepad++, ha. My 'new-ness' to OS bias my opinion and I am still excited about diving in and learning/using OS with its expanding capabilities and features - but the inability to open the .osm file and read it feels like a punch in the gut. Using a ‘find all’ for a UUID makes it potentially possible to trace what all is linked; but it is definitely not like ‘reading’ uniquely named objects. Given this construct, is the primary driver for using the BCL’s components and measure to make multiple edits to a model?