The ACES model is the first open-source energy system model created for Atlantic Canada. With an open-source energy system model, policymakers, industry and NGO representatives, regulators and researchers in our region can contribute to possible next steps on the path to net-zero GHG emissions for Atlantic Canada. Multiple interested parties using the same model can also create significant value through discussions around energy system planning informed by a standardized set of calculations and assumptions.

Users of the open-source Atlantic Canada Energy System model will be able to define model inputs and run a variety of scenarios to test which assumptions create feasible model solutions that can inform long-term energy system planning

Yes we can. Please contact us to inquire about consulting services.

The desktop model provides a "look under the hood" for users. While the Python language may take some getting used to, it is important to note that the desktop version of the model does not require Python experience. For users who are interested in running the model in this format, we provide learning tools on our website, training sessions, and technical support. Please note that the full Atlantic Canada 6-sector database requires 20GB of RAM to solve, so you will need access to a computer with sufficient RAM.

This model is independent from other existing models used by government or utilities. However, linking models could generate valuable insights. With an open-source energy system model, policymakers, industry and NGO representatives, regulators and researchers will be able contribute to possible next steps on the path to net-zero GHG emissions for Atlantic Canada.

Setting up ACES on your device requires a command line interface (your terminal or Ubuntu distribution), a Python distribution (Anaconda), an SQLite database editor (DB Browser), and the ACES model files. These components work together to read the model code, run commands, and produce model results based on the files and databases in the ACES folder. You can watch a video on how to download the model on the Run the Model page.

If you are using a Windows device, we recommend that you install Windows Subsystem for Linux (WSL) as a compatibility layer for running Linux operating system on your computer. Running the model directly on Windows without Linux is possible, but some faster solvers are not available on Windows, resulting in a much slower run-time of the model. Using WSL will allow you to run the model in a fraction of the time.

Even though using WSL has many benefits for Windows users, it is possible to run the model using only your current Windows set-up. Please contact our support team at ACESModel@netzeroatlantic.ca for instructions on doing so.

The Ubuntu terminal on WSL asks for you to set a username and password. It may appear that when you are trying to set your password that nothing is showing up, and what you are typing is not being accepted in the terminal. However, the system is processing the keys you are typing, though the line appears blank for privacy reasons. Make sure you type in the exact password you want and re-enter it when asked to do so.

The ACES model as well as Temoa, the modelling platform on which ACES is based, use Python language and require the use of a Python distribution to run. Anaconda is a computer program that acts as a distribution of Python programming language, simplifying packages and the installation process, making high-level computer programming more user-friendly.

When you download the ACES model folder, you first want to make sure that you unpack the zip file. Once you have extracted the ACES model folder in the zip file, it is best to put it somewhere that is easy to navigate – we recommend placing the folder in your C-drive (Windows) or Documents (MacOS). Modelling training sessions refer to the folder as being placed in your C-drive, so placing it in this location – even temporarily – may make it easier to follow along during training.

An environment in Anaconda is created to separate your Python workspaces from one another. The ACES model environment contains all the specific packages that you will need and have installed to run ACES and navigating to that environment by using the command “conda activate ACES” will allow you to use the collection of packages you need and to work within that environment without affecting any other python environments you may have.

Regardless of the operating system you are using (WSL, MacOS, Windows), you should be able to activate the environment at any time once you have created it. By invoking the command “conda activate ACES”, the command prompt should then begin with (ACES) rather than (base), signifying that the model environment has been activated successfully.

After navigating to your ACES folder and activating the environment, you can run a test to ensure that the environment is working by invoking the following command (as one line): python data_processing/MakeGraphviz.py -i ./data_files/ACES-Testing.sqlite

A network diagram of the ACES-Testing database should appear under a new ACES-Testing_input_graphviz folder in your ACES folder.

ACES is a capacity expansion model that minimizes the total discounted system cost, subject to user-defined constraints.

The configuration file (known as config_sample in the temoa_model folder) allows users to specify model options, including setting up an input database to run in the model, setting up an output database to store results, naming the scenario, and specifying the solver. Invoking the command to the run the configuration file communicates these decisions to the model.

The tables contain all user-definable data inputs of the model and will store its eventual results. Tables that start with a capital letter (eg. CostInvest, EmissionLimit) contain information on parameters which can be edited to update scenario assumptions (e.g., increasing the investment cost of a certain technology). Tables that start with a lower-case letter represent the aspects, or "sets", across which the parameters are indexed (e.g., technologies, regions, years). Finally, tables that start with "Output_" (e.g., Output_Costs) will contain the model outputs. It is important to note that model users do not complete the output tables; once the model solves, these tables are automatically updated.

In DB Browser, you can see all the tables in the database. In these tables you will be able to see what the abbreviations mean to understand the nomenclature, such as in the “technologies” and “commodities” tables. Generally, the nomenclature is formulated as sector_technology/commodity (i.e. E_WIND-OFF = electricity, wind, offshore). A full table of these terms can also be found in the model user guide.

When you use a model database, it is useful to create 2 new copies: one as an “original” file, and the other as a designated output file. Keeping a copy of the original database allows users to refer back to the original data inputs at a later stage. Having separate input and output files is not absolutely necessary, but is a cautious way to separate large databases with a lot of data. You can rename these new copies by adding “-Original” and “-Out” at the end of the file name, to designate them as their associated files (e.g., ACES-Testing-Out). Maintaining consistency with file naming is a good way to avoid mistakes. It is also important to note that file name should not have spaces (e.g., ACES-Testing Out) as this will create an error in the command line interface.

The command line is a text interface that allows you to interact with the operating system in text form. Your terminal or Ubuntu have command prompts that provide a line for you to type your command, where it is processed in the program. The commands used in ACES are important for directing your system to perform the necessary steps to run the model.

The results for each model scenario are stored in the output file you set in the configuration file. You can see that the tables in the output SQLite database that begin with “Output_” have been filled in once the results are produced. Excel spreadsheets of the results are also created and stored in the data_files folder.

You can run the command to bring up the dashboard visualization of the results (found in your user guide), which will produce an http code that can be copied and pasted into your browser. This dashboard will contain interactive plots of the results showing either the capacity, emissions, or flow figures based on the command you run, where you can explore the results for the different regions and commodities. This functionality is best suited for the electricity, transportation, and buildings sectors.

The temporal representation of the model is based around representative days. Representative days are selected with an optimization approach based in literature (Poncelet et al., 2017). Any given year can be effectively represented by a subset of its days that are weighted in terms of their relative frequency. To determine which days are selected and their respective weights, the following approach is taken.

First, a metric for the ‘representativeness’ of a set of days is defined. The most common approach found in literature is to use the comparison between the annual duration curves of a set of loads and/or technologies with those of the weighted representative days. In the Atlantic Canada Energy System Model the following curves serve as the metric: normalized load duration curve, normalized existing wind production duration curve, and the normalized new wind availability (i.e., capacity factor).

Second, the hourly load, existing wind production and new wind availability of each day of a year is encoded into a vector with length 3x24=72.

Third, the problem of selecting the optimal set of representative days with their respective weights is encoded into a combinatorial optimization problem. The target is to select K days (where K is a user input) with corresponding weights such that (1) the weights sum to 365 and (2) the root-mean-square error between the approximated duration curves and the annual duration curves is minimized.

This approach also enables the user to select a set of days that are forced to be included. For instance, the model user may wish to force the representative day selection algorithm to select the day with the peak annual load as one representative day. Alternatively, the user may wish to select three consecutive days with relatively high loads and low wind resource availability.

To create a scenario, open the database you want to work with in DB Browser. You can modify existing values or create a new entry by adding a new record to the table. You can watch a video on how to create scenarios on the Run the Model page.

When you change the parameter(s), set the scenario name in the configuration file to “test” or something that describes the scenario with no spaces (e.g., “WindEfficiency”). If you are running multiple scenarios with the same database, make sure you give each scenario a different name so the results do not override the previous ones. You can compare the scenario results by analyzing differences between the model-produced Excel spreadsheets, as well as using the drop-down menu to view different scenarios in the dashboard visualization. Note: you can also save the dashboard visualizations as image files.

Each time you run a new database, it is important to create a copy of the file and save it as the “original”. Leaving this file untouched will mean that you will always have the default values available. If you run a scenario and want to go back to your original values, you can either open the original file and copy and paste the values you want back into the input database or create a new input file by copying the original database file and renaming it. Remember that maintaining consistency in file names is a helpful way to avoid mistakes and confusion.

If you want to save the results from multiple scenarios, it is useful to create a folder to store results files. You can move excel files, dashboard images, and SQLite files into a folder and rename them all files to easily find them later. Remember that an output file is always needed in the data_files folder, so if you move it into a different folder to save results, you will need to create a new output file in data_files for the next model run.