Question-and-Answer Resource for the Building Energy Modeling Community
Get s tarted with the Help page

# does openstudio reverse translator only collect curve objects?

So, just curious. The file vrf_library.idf contains a whole bunch of EnergyPlus objects.

However, I observe the following:

library = OpenStudio::Workspace::load("#{File.dirname(__FILE__)}/resources/vrf_library.idf").get

# UNFORTUNATELY, the following ONLY captures curves from the library file!!!

reverse_translator = OpenStudio::EnergyPlus::ReverseTranslator.new
library_model = reverse_translator.translateWorkspace(library)

puts "Start Translation!"
puts library_model
puts "Stop Translation"

library_curve_linear = library_model.getObjectByTypeAndName(OpenStudio::Model::CurveLinear::iddObjectType,"OS Default Cooling Cycling").get.to_CurveLinear.get
library_curve_cubic = library_model.getObjectByTypeAndName(OpenStudio::Model::CurveCubic::iddObjectType,"OS Default Heating Combination").get.to_CurveCubic.get

puts "Start Curve Linear!"
puts library_curve_linear
puts "Stop Curve Linear!"

puts "Start Curve Cubic!"
puts library_curve_cubic
puts "Stop Curve cubic!"



The line "puts library_model" literally only prints curves, none of the other objects. Is that an inherent limitation in OpenStudio?

edit retag close merge delete

Sort by » oldest newest most voted

### TL;DR / Your specific case

No, it collects more than just curves, including most (if not all) of the geometry, as well as a bunch of other objects (eg: here's the ReverseTranslator I wrote for Generator:MicroTurbine when I added it to the SDK).

You're loading a file where the only objects that are able to be reverse translated are the curves, that's all.

### What objects are Reverse Translated?

The openstudiocore/src/energyplus/CMakeLists.txt is a good place to start looking at which classes appear to have a ReverseTranslator method implemented: see CMakeLists.txt#L395:L519.

That being said, it's not because a given object has a ReverseTranslator method that it is actually used by OpenStudio... In fact, ALL of the methods ReverseTranslator::translateClassOfObject are private, and they are called or not by the public method ReverseTranslator::translateWorkspace. That also means you cannot even force OpenStudio to try to translate something that does have a RT written out while it's not called by translateWorkspace

To see what is actually reverse translated (or trying to be reverse translated at least), you need to look at ReverseTranslator.cpp#L271:L993 and look for actual calls to translateClassOfObject.

### Example

This probably seems still a bit obscure, so to illustrate let's take an example: AirLoopHVAC.

CMakeLists.txt#L395 will build the file ReverseTranslator/ReverseTranslateAirLoopHVAC.cpp which holds a single method called ReverseTranslator::translateAirLoopHVAC.

As you can see translateAirLoopHVAC actually exists, and has about 400 lines of code.

Yet it will never actually be called by the ReverseTranslator::translateWorkspace method, see ReverseTranslator.cpp#L273:L277, you'll see that it is commented out, so when it encounters an AirLoopHVAC it just does nothing.

You might wonder why there are 400 lines of code that just aren't used.

If you want the Reverse Translation of an AirLoopHVAC to work, then you need to handle all possible objects that may appear on an AirLoopHVAC, which means write a ReverseTranslator for each and every single one, which isn't the case currently.

Implementing ReverseTranslation of all IDF objects that are implemented in OpenStudio SDK currently is not impossible (I don't think it'd even be an awfully complicated task), but it would be quite daunting to do everything in terms of man-hours: you need to write it out, and if you do write it out then you probably want to add unit tests to ensure it does work and will keep working in time.

I don't think there was ever any funding for ReverseTranslation, and it imposes more maintenance, so that's probably why it isn't near complete right now.

(Building ReverseTranslation of all objects in the SDK has been a fantasy of mine for quite some time as it would allow almost perfect round-trip to and from IDF, but obviously the problem is purely monetary... I'd love to be able to load E+ examples files directly in OpenStudio for example).

more

@Julien Marrec How many hours you estimate for that?

( 2018-06-06 08:52:11 -0500 )edit

Thank you kindly, Julien Marrec. The links you provide indeed do not mention anything at all about VariableRefrigerantFlow components, and apparently not even something as simple as a FanOnOff. So, as you suggest, I just happen to have a case where the reverse translator is just "blind" to most of my .idf entries - the curves are indeed the only common denominator.

( 2018-06-06 09:15:51 -0500 )edit

@Avi, I'm not sure really. A metric shit-ton perhaps? In more seriousness, this would require spending time figuring out which RT are missing (and then there are probably some unknown unknowns on top of it). That part could be done in a couple of hours max in a naive way by parsing the src/model/ classes and trying to match them to the src/energyplus/ReverseTranslator/ classes.

( 2018-06-06 16:14:01 -0500 )edit

Then to get a ballpark I'd guesstimate something like 4 hours on average per class to write the RT and a unit test (for the object only, not taking interaction with other objects etc). That's a guess, take it like a physicist: the order of magnitude is the important part here...

( 2018-06-06 16:14:15 -0500 )edit

I'm swamped lately, so I won't spend the two hours on this exercise, but if you do I'm interested. :)

( 2018-06-06 16:14:41 -0500 )edit