Nerd alert! Do the automation

This week has been a fun one. I have been tinkering with using Excel VBA to communicate with the TAS modelling software for a while, but this week we really got stuck in to automation.

What we wanted to do was be able to run a model of a home through CIBSE TM59 for 4 orientations and 12 weather files to explore AD-O compliance for a major house builder. As anyone who has run this many iterations for TM59 models will tell you, this can be time consuming as each iteration has to be set up manually, simulated and the results processed. What’s more, we want to be able to do this for lots of house types, and for several cases on each one.

Many modellers have been automating dynamic simulation tools (TAS, IES, Energy+ etc) for some time using Grasshopper or java+ or C# etc, often to facilitate parametric studies. I am better versed in coding with Excel, so that was my preferred option. EDSL TAS (I am a TAS user) offers access to loads of functionality through automation interfaces (API) that can be accessed via multiple coding platforms.

I was able to write code that picks up one model, and creates separate model files for each orientation (N, S, E and W) in each of 12 DSY1 weather files. I then batch simulate the 48 models created to generate a year of results for each. The final stage is to run each result file through the TM59 calculator to generate compliance results, and export them to Excel. This last bit only became possible this week thanks to the lovely Andrew at EDSL compiling a dll for me to try out. He promises this will be included in future updates of TAS for everyone to use.

Automating the software in this way is admittedly fiddly, but also, so much fun and deeply satisfying when you get it to work! We are now able to produce 48 results sets for one home in about half an hour; a process that would have taken around 2 days without this facility.

Previously we have had to rely on taking worst case orientations through all the weather files, but that is still time consuming and doesn’t give the full picture. We can now give more definite advice on where a unit can be built in any orientation without additional mitigations, where some orientations will comply with AD-O but others will need mitigations, and which site locations will need much more consideration. NB sites that exceed the AD-O noise criteria will need another layer of analysis.

If you are a TAS user and would like to try this but are new to writing macros in Excel there are some really helpful blogs on the EDSL website that take you through some basics (3 lessons) starting here: https://www.edsl.net/programming-take-your-tas-modelling-to-the-next-level/ – I hope they will write more of these posts as they are really helpful.

I’ve previously written macros for a number of repetitive tasks, including:

Importing a list of zone names from Excel – typing in the names for zones within large models can be very repetitive, but it’s important to keep a clear naming convention, so I found it much easier to create the master list in Excel and then run code to import the list to TAS. I still have to manually apply them within the model

Update ventilation rates to all zones – ventilation is set for each internal condition in TAS and sometimes a separate condition is needed for every single zone. When global changes need to made to all these internal condition profiles it can take ages and there is risk of missing one by mistake, so I write a macro that would do this for me.

I am assured that it’s possible to automate almost all functions of the software, which opens up huge potential to make the software work harder so that I can focus my attention on the tasks that need a human brain – getting the initial model creation right, and interpreting the results.