As someone who does compliance and research building performance energy modeling with EnergyPlus on a daily basis: here is my wish list for next Christmas, nice and early.
My main wish is related to geometry creation for energy modeling. This is the foundation of an ASHRAE 90.1 model, and remains essentially the same for baseline and proposed models. This is always my first step in modeling. The under-development OpenStudio plugin for Sketchup is phenomenal, and a step in the right direction, but I still have some suggestions. Working directly, learning, and also starting to teach and supervise others, I feel like the geometry can get out of control for anything but a rectangular block building.
This is specifically related to my experience with the NREL OpenStudio project (not the legacy tool) and integrating it into my workflow with E+.
Here are some items on my list, all are related to Robustness of geometry creation;
1. Precision. I constantly see 15 decimal points in my surfaces. Femtometers. This is the size of a PROTON!!! BuildingSurface:Detailed, ! -10.893252914887839, ! 3.5671903621940375, !
4.6999999999999993, ! In computers 4.6999999999999993 meters is not 4.7 meters, and might be causing problems with surface matching etc, and other strange bugs. Also file size, speed, and parsing issues. Each number is one byte of data, so say: 10 zones, 6 surfs per zone, 4 vertices per surface, 3 coordinates, 15 redundant characters per coordinate =~ 10 kB for a simple box building with no windows.
Maybe the problem is that Google Sketchup has no inherent "grid", only a precision setting. So I typically draw surfaces that are exact in width and height, but their absolute position in space might be offset by 0.000001.
2. Pre-flight Desktop publishing has the notion of checking everything is ok before rendering or printing. I think we can learn from this and have a real-time check of the geometry as we draw it. The problem is that I can draw a surface which will cause errors (let's say a 5 edged window), and then I won't see it until I run the model, maybe a week later, and have to spend 5 minutes searching the model for FenestrationSurfaceDetailed Whatever.
3. Bloat I was disappointed to see a new file format (.OSM) with the OpenStudio project. We already have tens of extensions for E+, now we have another. A lot of the OS: objects seem redundant to IDF. Draw a single zone building in OpenStudio and save it. 200 kB and 6000 lines of text! I would prefer a bare-bones template which can be used to check the basic geometry before we move to applying loads and constructions (pre-flight). Maybe this is just because I'm on the outside and don't see the master plan behind the program and where the formats and interfaces are going.
(Aside: And I was surprised to see that the syntax is unchanged. What about XML as a new native format for E+? I personally parse everything to XML and then operate on the model for bulk actions and parametrization. I think OpenStudio does the same internally?? Or is it SQL? XML is a natural evolution for the IDF quasi-CSV syntax; each object in a tag, each attribute as a child, with extensions for units, the ! comments, XSLT transform, but I think the dev team is aware of this and moving towards something similar...?)
4. Transparency I haven't delved into the source code for OpenStudio, but it would be nice get some more feedback from the underlying engine. Is the code using a logging module? I only have Python experience, my world changed once I started to use it's native logging module. If there is, it would be nice to have a console window open in an advanced user mode or at least a text file dump with lots of feedback - where is the execution now? Which Module? How many surfaces did it find? What are they called? What are we doing with them? What errors and online fixes are made? This would help users provide feedback in the current beta phase, help to self-correct and understand, and help future developers.
So in closing, I would wish for a return to basics before adding all sorts of new features like radiance coupling, dakota interface, system outlining, online database, etc. For now I would prefer a much more boring Openstudio that does even complex geometry quickly and cleanly, and then my next wishlist will be for all the cool stuff.
All that aside, I'm grateful to all the devs who have put in countless hours of work envisioning and implementing a revolutionary modeling tool free of charge for the world, keep up the good work!
Excuse cross posting, and have a great holiday,
Marcus -- Marcus Jones, M.Sc., LEED®AP BD+C Freelance energy consultant Vienna, Austria