Question-and-Answer Resource for the Building Energy Modeling Community
 | 1 | initial version |
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.
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.
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).
