Revision control for text-based modeling programs

asked 2014-09-05 07:01:03 -0600

Julien Marrec

29716 ●94 ●76 http://www.effibem.com/

updated 2015-11-09 14:06:48 -0600

__AmirRoth__

4436 ●5 ●17 http://bleedinggreenna...

When you're using EnergyPlus or eQuest for example, your input file is a simple text file. During the course of a project, you'll often end up modifying your input file over and over again, as part of an iterative process, be it to debug, calibrate or improve accuracy.

Before long, if you haven't been really careful about backing up and naming files and keeping a list of the changes you've made in another file, you'll be crawling under a sea of poorly named files, unable to know what changes you've made between this and that files.

This is no different than writing computer code, and the programmers have tools to deal with version control / revision control / source control. I could quote Apache Subversion (SVN) and Git for example.

According to wikipedia, Revision control, also known as version control and source control is the management of changes to documents, computer programs, large web sites, and other collections of information. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged.

It's a very handy thing: you'll get a complete track record or what you made (you can comment on what the change is too on some tools), rollback capacities, compare capabitilities, you can fork (for an ECM for example), etc.

Have people being using Revision control with success? What tools have you been using? (eg: Git/Github, TortoiseSVN, etc) How did you set them up to suit your modeling workflow?

edit retag flag offensive close merge delete

Comments

Hi all,

Are the options above still the go-to solution for version control in Energy modelling? I'm looking to implement it in our workflows and it's helpful to know what people are using in our industry nowadays.

In any case, thanks for sharing with so much detail.

Rafael

rafael.alonso ( 2021-12-18 14:20:55 -0600 )edit

Hi Rafael, I would be curious to hear what your solution/best practice is. For my personal playground with really small examples Github is a nice place, but in the office environment Google Drive and Dropbox are being used, and it's hard to introduce yet another service. So instead of proper version control, endless streams of randomly named files occupy the folders, many of them are being generated by LBT/Pollination or DesignBuilder... It's a mess.

furtonb ( 2022-09-18 08:05:05 -0600 )edit

I would recommend Sourcetree and BitBucket (either run it on your own local server or use their cloud version). You can still have files synced with Google Drive and Dropbox if you want, but being able to have one version of the file names and then being able to see the commit tree visually along with the commit messages is really helpful. It's worth taking the time to learn it and train your co-workers.

anchapin ( 2022-09-21 11:55:49 -0600 )edit

add a comment

4 Answers

Sort by » oldest newest most voted

answered 2014-09-05 10:14:50 -0600

Neal Kruis

4735 ●10 ●17 http://bigladdersoftware.com/

At Big Ladder we train energy modelers to use version control for their models. This is important for keeping a history of changes, but it also makes collaborating on a model much simpler than the old "original file name + my initials + date" approach to sharing files.

We have hosted SVN repositories for several modeling firms, and, if they are working on windows, we will set them up with TortoiseSVN as one of the more intuitive graphical interfaces for version control.

We also use SVN in-house to keep templates for the different components of the building input file that we re-use often. Each template is then referenced by a master file for a specific building model. This workflow has really streamlined the whole modeling process for us.

That said, there is definitely a learning curve for version control. I suggest easing into it with a very basic system (like Dropbox, which will keep a history of changes) and then progressing to SVN which enables more collaboration as projects become more complex and require closer tracking of changes and have multiple contributors.

If you still feel like you need more capability for forking and merging, you can look into Git, but I feel it would be a bit overkill for an energy model. One thing in Git's favor is that there are several good sites that offer free hosting (though I'm sure you can find some decent SVN hosting sites as well):

BitBucket for private repositories
GitHub for public repositories

edit flag offensive delete link

Comments

Thanks or the answer. I actually use Git myself, first with Github for Windows, and I found the process fairly easy. I've tried both TortoiseSVN and Github in the past when building websites, but I can't 100% remember why I decided to stick with git, I think it was for the hosting. I recently decided to try out Bitbucket by Atlassian, and realized they have a pretty good client too, SourceTree, so I've decided to try it out as well. I'll likely update when I get a clearer idea. And I want to push my colleagues to use it too for collaboration...

Julien Marrec ( 2014-09-06 12:11:57 -0600 )edit

I've been using SourceTree as a git client for months now, with Bitbucket repositories for collaboration with my team (QA/QC works for example) and it's going great! There is a bit of a learning curve - for the first user at least. But by giving a short (15-30min) demonstration to my colleagues they were able to use it right away and rarely ran into problems afterwards. GitHub for Windows is surely simpler but SourceTree has more features and a really nice graphic interface, especially for advanced use such as branching and merging.

Julien Marrec ( 2015-01-08 05:02:37 -0600 )edit

Also, Bitbucket has a built-in wiki and simple issue tracking system: a plus for collaboration. (The issue tracking system isn't as good as the paid JIRA, but it does the job nicely for QA/QC)

Julien Marrec ( 2015-01-08 05:05:24 -0600 )edit

add a comment

answered 2014-11-11 10:54:39 -0600

mtiller
61 ●1 ●2

If this is a topic you are interested in, you might want to read this blog post I wrote called What Engineers Need to Know About Version Control.

Version control is an excellent example of something that engineers really should be intimately familiar with. The usual reaction is "Oh, I don't need that" or "That's too complicated". But in reality, all engineers do ad hoc version control and it is just as complicated and far less useful. At least, those are my opinions.

edit flag offensive delete link

add a comment

answered 2014-11-12 03:06:52 -0600

rubenbaetens
61 ●1 ●1

Version control is a must-have when it comes down to code- or model- development, or the writing of large documents. Within the framework of e.g. IEA EBC Annex 60 we use both GitHub (for all public code) and BitBucket (for all private work) for all code development, while i personally always use GitHub, even for my private repositories.

The main point for using a git version control system is of course: collaboration, and it's (my opinion that) only by using it in collaboration with others in code development, that you're able to steadily tackle the learning curve of git. If you only use it for yourself and on your own code, you'll once discover and use the tip of the iceberg of what version control can offer you.

edit flag offensive delete link

add a comment

answered 2015-07-14 20:27:02 -0600

DavidReddy

481 ●1 ●6 http://www.OBrien360.com/

We've used revision control (TortoiseSVN) in our work flow, versioning energy model files and supporting documents for projects, for almost 3 years now, and can't even remember how we got by without it. It is very useful for tracking history, collaborating, and reducing the amount of information we need to backup. On more than one occasion, I have made some change to the model that causes a fatal error that cannot be debugged easily with logging. Diffing versions of the file is one more way to help debug the problem.

Our repositories are stored in local folders that are sync'd with the cloud and then across all our computers. We currently use Egnyte, but have also used DropBox; both have worked fine. There is a bit of lag time between commits/syncing between users on different computers, but nothing that has slowed us down.

Most of our experience is in the context of versioning eQUEST files, and the following are the files we archive in each revision: *.inp *.pd2 (though only for the initial wizard model. Once in detailed mode, we often skip versioning this) *.prd *.Parms.csv (This is once we get int

We try to commit any supplemental files (xlsx, etc) that help document the model along with the model commit. Also, we have found it valuable to tag the trunk when delivering a set of results or final report to the client.