For the last eight to ten months I’ve been thinking about and working on tools to help improve my energy modelling workflows. In the process I’ve analyzed my current tools and found them to be lacking in certain areas. I’ve also not been able to find any other tools that really meet my expectations. Throughout this process I’ve identified some key characteristics and concepts that I value in energy modelling tools and will describe them here in a “Manifesto for Good Energy Modelling Tools”.
Before going further I should clarify what I mean by “tools”. I mean the software and processes used to create and modify the input files for existing energy simulation engines, as well as the tools used to analyze and process the resulting outputs. There are various simulation engines out there with their own pros and cons, but the engines themselves are a different discussion. In no particular order, the “precepts” for my “Manifesto” are:
Open Source and Cross Platform
I believe good tools will be open source to allow the community to embrace and extend them without needing to rely on a third party. The user should also be free to choose his or her operating system and still have good tools available. These two items encourage a community to develop around the development and growth of the tools, not just their use.
If you’re trying to “build a platform”, you’re doing it wrong!
The underlying input file for the modelling tool of choice is the platform. These files are often plain text and at least somewhat human-readable. If you’re adding a layer on top of this, then the layer should be as thin as possible. “Heavy” interfaces to underlying input formats tend to be complex abstraction layers and I personally find that they get in the way. The primary goal should be to make interacting with the input file easier, not necessarily “extending” format. When a file format is “enhanced” it usually ends up meaning a new file format which is not in and of itself compatible with the target simulation engine. The outputs of good tools should be the native file formats supported as inputs for the engine. This doesn’t mean that an intermediary file format is out of the question, but it should be avoided unless there is significant advantage. Even then, the format should remain human readable and plain text. An example of this is eQuest‘s pd2 files and inp files. The DOE2 file format was “extended” by implementing separate eQuest-specfic features in a separate file, but both files remain plain text. Another way to put this is that a “light weight” tool will provide as clear and direct a path as possible between the inputs to the tool and the resulting changes to the underlying, native input file.
No Black Boxes
This goes partly along with the “light platform” idea in that when you find yourself creating “heavy” abstraction layers, you also end up with black boxes. Engineers hate black boxes. We want to know the inputs, outputs and what happens inside the box. Energy modelling tools can be incredibly complex, so the more known about how a tool process the inputs its given, the better the user will understand the outputs. It is these outputs that will be used by the simulation engine itself, so this allows users to feel comfortable with the tools and make more informed choices about which tools to use and when.
Automatic Compatibility With Underlying Engines
This is a tricky one and can’t always be achieved, but the goal should be to build the tools (input editing tools especially) in such a way that they are compatible with any version of the underlying engine that a user has installed. If you find yourself saying “that feature is not yet supported by the editor” then you have created a “heavy” abstraction layer—this is bad. An example of how this could work is the EnergyPlus input file format (IDF). All information necessary to create an editor is contained in the input data dictionary (IDD) that comes with the engine itself. An editor that reads and processes this file and acts only as allowed by the IDD file will be compatible with any version of EnergyPlus. This can make extending the format more difficult, but the IDF format is quite flexible.
Bottom Up, Not Top Down
The goal of any tools should start with the end-user and their specific pain-points. If your users have to think hard about how they could incorporate your tool into their workflow, then you’ve created a “solution in search of a problem”. The tool should address specific pain points in the user’s worflow, making it extremely obvious how they would use it. It’s ok to create innovative features that a user “didn’t even know they needed”, but this is difficult and should only come out of a deep understanding of the workflow. This type of understanding will typically come only from having significant, first-hand experience with the old tools first.
Clarity and Information
A good tool will be clear and provide all the information necessary to judge appropriate use of the tool. This covers everything from high quality help files to interfaces that provide clear guidance on what a feature actually does. This point is similar to “no black boxes” and applies particularly to output processing tools. If a tool provides a summary of “peaks” for example, it should be clear somewhere what exactly that means—what is included, when are the peaks recorded, etc.
To sum it all up, a good energy modelling tool should be:
- Open source and cross platform,
- As lightweight as possible,
- Free from black boxes,
- Automatically compatible with other engine versions,
- Built to solve specific pain points, and
- Have clear interface and documentation