DOI: 10.5281/zenodo.5774987
title: Pre-built Sector-coupled Euro-Calliope Model

description: <strong>Sector-coupled Euro-Calliope subnational-scale pre-built models</strong> Built using Sector-Coupled Euro-Calliope workflow commit hash: 6fd0bf3dce2a0799ac9821b50e9b1513fa783018 This model is pre-packaged and ready to be loaded into Calliope, based on 2010 - 2018 input data. To run the model you will need to do the following: a. Install a specific conda environment to be working with the correct version of Calliope (<code>conda env create -f requirements.yml</code>) b. Include specific scenarios to pick up the relevant sectors. For the study accompanying this release, The following scenarios were included <code>"industry_fuel_shared,transport,heat,config_overrides,res_2h,gas_storage,link_cap_dynamic,freeze-hydro-capacities,add-biofuel"</code>, where: <code>industry_fuel_shared</code>: Includes all non-electrical industry demands and the necessary technologies to generate those fuels synthetically. This includes e.g. annual methanol requirements for the chemical industry. <code>shared</code> refers to the fact that all regions' annual demand is pooled and can be met across all regions. The other option is to set this to <code>industry_fuel_isolated</code>, where a region must meet its own annual demand by generation of fuel within the region. <code>transport</code>: This ensures ICE and EV light and heavy vehicle technologies and annual demands are in the model. It also includes reference to constraints required to make smart-charging of EVs work (e.g. weekly demand requirements). <code>heat</code>: This ensures that all heat provision technologies and hourly demands are in the model. Carriers added are <code>heat</code> (space heating and hot water) and <code>cooking</code>. Technologies added can be found in <code>heat-techs.yaml</code>. <code>config_overrides</code>: This includes high-level simplifications, such as removal of technologies that are considered redundant (e.g. less interesting combined heat and power technologies). <code>res_2h</code>: Sets the model with a 2h resolution. Can be omitted or can be one of <code>res_2h</code>, <code>res_3h</code>, <code>res_6h</code>, <code>res_12h</code>. The full hourly resolution model takes ~2 days to complete. <code>gas_storage</code>: Includes underground methane storage facilities, based on latest data on a national level. Can be omitted to remove the option of this technology. <code>link_cap_dynamic</code>: Sets a limit on transmission line capacities. The limits are chosen subjectively based on current capacity, such that lines with smaller current capacities can proportionally increase much more (e.g. 100x) than larger lines (e.g. 2x). See <code>national/links.yaml</code> for other override options to apply here. <code>freeze-hydro-capacities</code>: Sets hydro capacities to equal "today's" capacities. This seems more reasonable than setting current capacities as upper limits, as this causes the model to install no hydro. <code>add-biofuel</code>: Enables a biofuel supply stream with a distinct <code>biofuel</code> carrier, with annual limits on biofuel that can be provided (based on JRC residuals). This differs from Euro-Calliope v1.0 which is a black box technology converting biofuel to electricity directly. c. decide on a SPORES run to undertake, e.g. the scenario <code>spores_supply</code> will run SPORES for primary energy supply technologies. SPORES scenarios can be found in the file <code>spores.yaml</code>. d. pick your run year, by pointing to the relevant model config file (e.g. <code>model-2018.yaml</code> for the 2018 weather year). e. run the model via the dedicated scripts found in this directory. These scripts include the addition of custom constraints and have been copied directly from the workflow, where they would normally be initiated as part of the internal process. However, you can load and run them in an interactive session / with your own python script to call them: <code class="language-python">[1] import create_input </code> <code class="language-python">[2] create_input.build_model(path_to_model_yaml, scenarios_string, path_to_netcdf_of_model_inputs) </code> <code class="language-python">[3] import run </code> <code class="language-python">[4] run.run_model(path_to_netcdf_of_model_inputs, path_to_netcdf_of_results)</code> <code class="language-python">Note: The only difference between this version and v0.1 is that spurious hidden files specific to MacOS have been removed from the dataset.</code>