I've previously mentioned the interoperability course at PAE in brief, but it deserves a lot more attention. Its a pretty awesome course taught by Jonatan Schumacher and Ben Howes (both PAE alum) that introduces object oriented programming and interoperability via VB.NET.

When I mention VB.NET to actual computer scientists, they sort of make a bitter beer face. Apparently, in the wider world of computer science, its looked down on a bit, but for our purposes of programming in windows based programs, its been working perfectly. 

We began the term scripting macros in Catia, using its visual basic editor. This was a great way to start. I've never enjoyed or excelled at programming, but I was immediately able to understand the power of programming in regards to geometry generation. We then transferred our CATvba scripts to VB.NET in SharpDevelop, a free script editor (a great substitute for Microsoft Visual Studio). This was fascinating to me. I could write out instructions in SharpDevelop, press play, sit back and relax and watch hundreds of individually rotated arcs generated and then lofted in Catia.

All that was just to get us warmed up. Once we established that we could import the object class of an outside program into SharpDevelop, we then got cracking on our first interoperability script. We created a simple program that would send names of geometry from Catia to Excel where they would be filed into a spreadsheet, would then pause and ask the user to rename the geometries, and then would send those names back to Catia and rename the geometries with the new names, all within seconds. Very basic, not the most powerful function, but it was our "Hello World" program for interoperability (I felt like Neil Armstrong for a split second taking on small step for architects on the barren landscape of Excel). We had ushered data from one program to another and back all from SharpDevelop.

For our midterm we developed proofs of concepts for final projects. Two of my classmates and myself decided to tackle a Grasshopper to EnergyPlus interoperability tool. We spent last spring simulating energy models in IES and it has left us forever scarred. Its drafting system is severely outdated and frustrating, especially after spending all of our other time in advanced geometric software such as Grasshopper and Catia. EnergyPlus is a free energy modeling engine that was developed with a focus on performance and an intentional neglect of user interface. In the documentation for EnergyPlus they make it clear that their intention is for other software developers to create the interfaces (ie. eQuest, OpenStudio), and they have made all the documentation that is necessary to do so available to the public. Thus an opportunity to replace IES as the energy modeler of choice at PAE.

We decided to use Grasshopper as the modeling environment because it is the ultimate interoperability tool itself. It is the perfect vehicle to relay data, whether it be geometric, numeric, or strings, because behind all the pretty nodes and wires, it is just an object oriented programming solver. In addition it has access to another great interoperability tool in Rhino, for which it is very rare that I come across a file type that it can't open. Its really the perfect match, as evidenced by the intense following of and production in grasshopper by its community.  

The task is fairly simple. EnergyPlus reads an IDF file (a text file with an .idf file extension), which contains all of the geometry, orientation, materials, location data, energy meters, and so on that are required for the energy model. All we needed to do is format that data into a string and write the text file. The hardest part has been figuring out the user interface. EnergyPlus is a deep program that can provide energy model results as accurate and detailed as they come. The question that keeps popping up is, what variables and results do we make accessible to the user, if we only have one term to work on it. 

By midterm we had developed a very stringy and messy proof of concept utilizing some VB nodes that took a user generated BRep, formatted and compiled an IDF file, and than initiated an EnergyPlus simulation with a user selected weather file and returned interior and exterior temperatures as well as heating and cooling loads. The real fun however, has just started. For the past two weeks we have been collapsing our messy grasshopper definitions into concise and neatly packaged grasshopper components.

Its pretty cool to see your custom nodes up on the grasshopper toolbar or pop up as an option when you double click in grasshopper and type for a node. It has also brought the user interface aspect of the project to the forefront. At first we attempted to put as much functionality into each node as we possibly could, but we soon realized that's not the grasshopper way. Grasshopper's success has been in its usability and I think a big part of that is creating very simple building blocks that can be used to realize anyone's imagination rather than large pre-fabricated blocks which limit the user's ability to create their own definitions. Hopefully we can develop a very usable set of components which we can publish on the Grasshopper website.

Before: midterm proof of concept

After: custom grasshopper components