I’ve been spending a significant amount of time studying my energy modelling workflow lately. I’ve also spent a significant amount of time programming, so it’s occurred to me that I should take a look at applying programming tools & techniques to energy modelling.
I have been doing a trial run of using a version control tool called Mercurial, which is commonly used in computer programming to record and give you access to previous versions of your code. This is an over-simplified description, but the idea is that you can freely experiment with your code (or other text-based file like an energy model) without fear of “messing something up”, because you’ve been saving versions along the way and can easily jump back (or forward again) to any version in the tool’s “repository”. This is far more advanced than simply saving a copy, however, it saves only the differences between versions making it very space efficient. It’s also searchable so you can search all previous versions of all model files for arbitrary keywords!
Every time you “commit” a version using the tool it’s saved for good in the repository and you also write a short log message which serves as a reminder of what changes were made. There are also features available like tagging a version with a keyword such as “Report Version” for the version of the file used to generate a report sent to a client. This way, you can continue working and yet be able to jump back to the specific version used for that report at any time.
Another great feature that’s used all the time in the programming world is branching. This allows you to “branch” off from any version of your model, make changes, then “merge” the changes back at a later date. This can be useful for very specific features you want to implement and keep track of separately.
So far I’ve been finding it integrates well with my modelling workflow, although it is not for novice users! It helps to have a background in programming, but is not necessary. The tools available to manage version control repositories tend to be very complex, like the one that is distributed with the Windows version of Mercurial, TortoiseHg. There are, however, simpler tools, which I have been trying as well such as EasyMercurial. EasyMercurial is much more user-friendly and still maintains most of the features and flexibility of Mercurial. There are, of course, other version control systems, the most popular being Git. I personally find Mercurial to be more intuitive, but this will be subjective.
There is a concept in programming known as self-documenting code. Wikipedia describes it best:
In computer programming, self-documenting (or self-describing) is a common descriptor for source code and user interfaces that follow certain loosely defined conventions for naming and structure. These conventions are intended to enable developers, users, and maintainers of a system to use it effectively without requiring previous knowledge of its specification, design, or behavior.
Applied to energy modelling, a “self-documenting energy model” would be one in which there is good use of comments, descriptive system names, zone-naming conventions, intuitive system and component names, etc. Altogether, this leads to a model that is easy to understand by others who may need to use your model later, and also by yourself when returning to a project after some time away from it. The key idea is that any value that “looks odd” or “needs to be that way for a reason” or is in any way out of the ordinary should be documented somewhere! Keep in mind that the definition of “ordinary” is relative.
There will be varying ways to implement these concepts in different energy modelling tools, however most of them offer ways to use comments and custom naming of objects, which are the primary features needed.
The Zen of Python
The Zen of Python is a document created early in the history of the Python programming language (which I am working in primarily these days). It includes a set of precepts that are intended to make your python code better. They might not all apply to energy modelling, but a few do and I wanted to include at least a few of them here:
- Explicit is better than implicit. If you have a choice between saying or doing something directly or indirectly, choose directly! If you know you need a value to be a certain way then set it explicitly in your modelling software instead of relying on defaults or the unknown level of expertise of future modellers.
- Readability counts. If your notes, comments or model is confusing and difficult to read it will be difficult to understand and use.
- In the face of ambiguity, refuse the temptation to guess. This one definitely applies! There will always be some way to make some kind of engineering judgment call, not just a guess. Ask around, do more research, call the contractor/client, etc.
So as you can see there is a significant amount of cross-over between handling specially-formatted text-based input files for simulation engines and specially-formatted text-based input files for compilers. I’m sure there are other tools and techniques that I will run across as I continue to study my workflow. I’ll do my best to post them here!