does openstudio reverse translator only collect curve objects?

edit

@Julien Marrec How many hours you estimate for that?

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.

@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.

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...

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

Well, it took me half an hour to estimate it. See the Ipython notebook (you can just view it, no need to run): https://gist.github.com/jmarrec/c7bc3...

So if you assume 1/hr/class missing: about 300 hours, if you assume 4hr/class: 1200 hours.

It'd be interesting to pick two objects (a simple one, and an awful one like VRF) and track the time needed to implement the RT + a unit test (you can skip child objects that don't have a RT, since one the RT for it is implemented it's really simple to add it to the parent) to see how much time that really takes on average. This time I will not spare the time, I'm off to sleep. (This discussion should really be on UH slack (see here on how to join), I'm polluting the comment area...

@Julien Marrec I am tempted to take it on since I feel like contributing some. I will try to understand how big is it since I am not sure it is not out of my league.

Feel free to swing by the Slack channel if you need some pointers getting started (setting up the project to compile, general ideas on how to implement a RT, etc). I'm usually on it from 9 AM to 6 PM CET.

@Matt Koch, please mark the answer as accepted if that solved your problem, so the thread gets marked as resolved.

@Matt Koch, in case it's helpful to you in the future on the OS website there is a quick summary of import/export options.

The Reverse Translator isn't very full featured because in the early days of OS, very few people were using EnergyPlus, which made import of IDFs much less important.

It seems to me Curve:Exponent is another object missing from the reverse translator at present.

So, in general, I am using IDF format to create and import equipment libraries. Couldn't one achieve the same using OSM format? After all, the OSM contents are ASCII as well and very similar to IDF in format. If so, what (other than replacing .idf with .osm) is the equivalent to:

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

Yes, you can absolutely use .osm files as a library source. The easiest way to do this is to make a new model in the OS App, add/edit all the curves/whatever you want, and save the model. Then, under preferences > change default libraries > add, pick your .osm library. Until a few versions ago, OS wouldn't load HVAC objects from the library, but now it does.

Assuming I want to reuse my .idf file, could I just change the extension from .idf to .osm, and then inside the file, add an OS: in front of all objects? Then use the following?

library_file = OpenStudio::Workspace::load("#{File.dirname(__FILE__)}/resources/vrf_library.osm").get
test = library_file.getObjectsByType("OS_ZoneHVAC_TerminalUnit_VariableRefrigerantFlow".to_IddObjectType)

Matt, adding "OS:" in front is definitely not going to work. There are differences in the E+ .idd and the OS .idd, the first of which is that all objects have an extra "handle" field at the first position. Also, child objects are referenced by their handle and not their name. Also, in some cases, there are extra objects that don't exist in one or the other format (eg: BranchList etc is a purely E+ convention, in OSM it relies on Connection objects). Generally speaking, editing an OSM in a text editor, unless doing something very basic is definitely not safe and will bite you at some point.

Yes, thank you, I realized that myself yesterday and decided I did not want to mess with handles. I also have gone too far down the road of .idf import now, so I developed a workaround to get my Curve:Exponent recognized, since the reverse translator does not do that. That was the only remaining hurdle to success on my side. I can now import a complete custom VRF system (indoor and outdoor) from an .idf file, which became necessary because Daikin does not offer such - they only do it for Trace-700 and eQUEST. How well it will work in terms of producing reasonable results, only time can tell.

Next time you want to do that, you should create an OSM library instead, you'll spend a bit more time creating the library perhaps, but import will be seemless from there.

Understood - is the way to do that to create a new .OSM file from within the OpenStudio application, then e.g. go straight to the HVAC tab and add, e.g. VRF systems and VRF terminals, edit the fields as necessary and save that file? And that then becomes the library?

Yes, that's exactly it.