In many aspects, a building energy model is similar to software: they are systems consist of many many sub-systems, each system has their data categories, levels of details and it interacts with the other systems. Moreover, depending on the size of the system, the workload, and the number of stakeholders can be scaled up significantly. Lastly, both of them need to go through a rigorous testing process to optimize their performance.
With all these complexities, model version control has played a significant role in the process of creating an energy model. Imagine how painfully it could be if you lost track of your hours of work after accidental data deleting or crash/error from EnergyPlus. Fortunately, most of the energy modelers are using some version control technique now. The most common one is the file naming.
The naming technique has a personal style. I remember when I just started doing modeling, I named each version of the model as V1, V2, V3, or added some level structure, like v1.1, v2.1... This worked fine for homework. However, this style was not very informative. So when it came to a real project, I had to reinvent my naming style. "project_v1_envelope_r15.idf", "project_v1_envelope_r20.idf"... Adding a highlighted change to the name was pretty effective at the beginning of my project. But, very quickly, I realized that there could be too many changes in one version for a file name...so in the end, I created a text file to keep track of everything. In the text file I mapped the file name to the highlighted systems:
"v1: envelope - r15, light-9.6, EPD-10.2, occupants-5, HVAC-PTAC....".
I called it the mapping technique. It works pretty well for most of my projects until we started calibration work.
The difference between a calibration work and design parametric is that you are playing with parameters rather than systems. Because you can't swap the HVAC system to make the model outputs matching the measured data, and you can't change the lighting products because the lighting system performance should be derived from measured data. Instead, you can only play with the performance curves, coefficients and schedule values, etc. And this causes a big problem for the mapping technique. I was spending too much time on version control than my actual modeling. Changing one parameter in EnergyPlus is just one second, but write it down on the "map" file could take more than 10 seconds!
It later got even worse when I started working with my colleague on the same model. Many data overwritten, constantly data lost and repetitive work have greatly reduce both of our productivities.
Interestingly, software industry used to suffer this issue as well. This inefficiency largely contributes to the development of code version control and code management techniques. Nowadays, you can see products that promote these techniques are used by every software development team. Some of them might sounds familiar to you, such as the GitHub and Atlassian SourceTree. In this blog, I would like to introduce the foundation technique of these two products, GIT and what we can leverage its power in our daily energy modeling tasks.
Next time we will learn more about GIT.