Within the cost of energy module, costs are calculated for the project as a whole and then allocated to each turbine so that each turbine has its own cost of energy.
Turbine-specific costs are input as part of each turbine type, as can be seen in Figure 161 below.
All the costs that scale directly with the number of turbines should be included here. In the list of periodic costs below, new costs can be added or deleted using the "+" and "-" buttons. The detail of the periodic costs are covered in Costs in Turbine Types.
Users set up costs for the collector system and access roads in the Cost of Energy settings.
In the Roads tab of the cost of energy settings, the meanings of the input fields are as follows:
•Enable Access Roads - this option should be on for onshore sites and off for offshore sites where access roads are not required.
•Cost per Kilometer of Using Existing Road* - in the case that a LineLayer has been assigned the meaning "Roads" but is not to be interpreted quantitatively then this is the upgrade cost (if any) of using that road layer to access the site;
•Base Cost per Kilometer of Road - this is the cost of laying new road from scratch;
•Policy when access roads using extant roads
oNo crossing costs - this assumes that the already existing roads contain bridges which are suitable for turbine trucks
oHierarchy derived costs - this allows the user to choose which crossing costs should be applied and which ones should not. Layers which are found by the access road layer before the extant road layer cause crossing costs. Layers which are below the extant road layer in the hierarchy do not cause crossing costs.
oAll crossing costs - this assumes that any existing bridges will need upgrading or replacing.
•Maximum Incline for Any Type of Road - this is the maximum incline allowed for new or upgraded roads (even if there is no upgrade cost);
•Additional Cost per Kilometer of Road Through Steep Terrain - this is a penalty applied to roads below the maximum steepness but perhaps above the turbine manufacturer's recommended limit - this cost should be significant at least during the optimisation process;
•Steep Terrain to be Classed as Having an Incline of At Least - this is the preferred gradient limit and is generally the limit recommended in the turbine specification;
•Minimum Turning Radius in Meters - this can be found in the manufacturer's technical documentation for the turbine;
•Cost of Crossing a Water Course* - in the case that a LineLayer has been assigned the meaning "Water Courses" but is not to be interpreted quantitatively then this is the cost of crossing each line in that LineLayer;
•Cost of Taking Down and Rebuilding a Crane* - similar to above but represents crane take downs. This layer is likely digitised in based on the judgement of the user.
•Cost of Crossing a Fence Line* - similar to water courses but for fence lines.
•Cost of Crossing a Railroad* - similar to water courses but for rail roads.
•Cost of Crossing a Public Road* - similar to water courses but for public roads that cannot be used by the road layout and entail a cost to cross.
•Cost of Crossing a Pipeline* - similar to water courses but for oil or gas pipelines.
•Cost per Kilometre of Crossing Wetland* - similar to water courses but uses wetland polygons.
•Acceptable Terrain Gradient - is the maximum crosswise gradient after cutting and filling;
•Width of Road [m] - is the width of the access road and is used to calculate the amount of cut-and-fill;
•Cost of Earth Moving (per cubic meter) - is used to calculate the total cost of the cut-and-fill.
•Save As XML – saves all the optimiser for cost of energy (OCOE) settings as XML.
•Load XML – loads in different OCOE settings from an XML file. This functionality is intended to facilitate the maintenance and use of different sets of OCOE settings to be used as templates for working on different kinds of project or in different parts of the world.
Both the cost of using existing road and the cost of stream crossing can be overridden by quantitatively interpreting the database fields of LineLayers interpreted as "Roads" and "Water Courses". In this way, the optimisation can incorporate costings based on data from a detailed survey of the site area.
In the Collectors tab of the cost of energy settings, the meanings of the input fields are as follows:
•Auto-place substations using clustering (single substation at average turbine location) - use this option for early stage projects in which you have an idea of where to interconnect and you do not yet know the position of the substations. A single substation will be placed, as in previous versions, at the average turbine location. For more than one substation, K-means clustering is used to place substations at the cluster centers. It is still up to the user to determine how many substations are appropriate.
•Use fixed grid connections and substations - use this option if you know where you want to place both your grid connection and your substation or if you want to use more than one substation.
•Optimise substation locations – this functionality is still subject to change but appears to be working reasonably well and the limited number of case that have been tested including 2 substation problems. We welcome feedback on this. It works best when the substation layer has a limited buildable area.
•High voltage from substation costs - these are only applicable when choosing the root node as the grid connection. The voltage and resistance are used in the electrical losses model.
•Cable Types - here is where you specify the full range of cable types to be available to the collector system optimiser
oName - simply a text field used to refer to the cable type
oCapacity - this field determines how many turbines can be connected upstream of this cable. The capacity of any cable type is site-specific as it depends upon the soil moisture content. The cable type with the maximum capacity also determines the maximum circuit capacity
oCost per meter - this cost should include not only the cost of the cable but the cost of installation including forest clearing or trenching if the cable is buried
oResistance in Ohms/km - this property is used in the electrical losses model.
•Cost of Crossing a Water Course* - in the case that a LineLayer has been assigned the meaning "Water Courses" but is not to be interpreted quantitatively then this is the cost of crossing each line in that LineLayer.
•Cost of Taking Down and Rebuilding a Crane* - similar to above but represents crane take downs. This layer is likely digitised in based on the judgement of the user.
•Cost of Crossing a Fence Line* - similar to water courses but for fence lines.
•Cost of Crossing a Railroad* - similar to water courses but for rail roads.
•Cost of Crossing a Public Road* - similar to water courses but for public roads that cannot be used by the road layout and entail a cost to cross.
•Cost of Crossing a Pipeline* - similar to water courses but for oil or gas pipelines.
•Cost per Kilometre of Crossing Wetland* - similar to water courses but uses wetland polygons.
•Cost multiplier for using existing (seeded) collector system - this option can be used to shape the collector system solution. However, it is a rarely used option.
•No branching - with this option checked, each turbine can be connected to a maximum of two other turbines. This option tends to be used offshore and is particularly appropriate for floating turbines.
•Use Sharma for substation to turbine routing - this is an alternative to the Esau-Williams CMST algorithm which is less optimal but tends to cause far less cable-crossing and is therefore more suitable for offshore applications.
•Discount solutions which require cable crossing - still a work in progress but this tries to ignore trade-offs which cause a cable crossing and so is again aimed at offshore applications only.
•Cost of equipment to connect a circuit inside the substation - this can include the cost of switch gear, circuit protection or any other fixed costs which are added when you add another circuit. We term all of this together to be a “feeder bay”. This cost encourages the collector system optimiser to fill circuits.
•Cost saving of running cable along new roads - in this way it is possible to encourage the collector system to run alongside the roads. When burying the collector system underground, there can be a significant cost saving to trench the cable at the same time is building the road. The collector system routing will still only use roads where it makes economic sense but the larger the cost saving specified here, the more likely the cables will run along the roads.
•Cost saving of running cable along existing roads - there may be little or no cost saving when running along existing roads.
•Specify how the collector system solution is derived - initiates the following dialogue:
The collector system optimiser uses a variety of well-known path-finding and network optimisation algorithms in order to achieve the goal of a near-optimal collector system design. Several of these rely on gridding the search space. The search time for the path finding components tends to scale with the inverse square (or worse) of the grid resolution. For this reason it is a good idea to keep the grid resolution as coarse as possible whilst still being able to represent realistic solutions. When creating validity constraints for the collector system, it is a good idea to make corridors be at least twice as wide throughout as the resolution of the grid.
Generally, the nearest ten turbines will be adequate to identify a turbine to which the turbine in question should be connected to form a circuit to minimise construction cost. However, there are times when this will not be enough, and the number should be increased. Increasing the number also increases the processing time, however.
The optimiser requires that Site Layers are either optimised on the basis of their cost of energy, therefore requiring both a Site Roads and Site Cables layer, or that the Site Layer is not included in the optimisation at all. It is not possible to mix optimiser modes so that some sites are optimised on the basis of energy whilst others are optimised on the basis of cost. All enabled SiteLayers are still included in the energy capture and wake calculation. The effect of not including a site in the optimiser for cost of energy is to effectively fix the location of that site's turbines for the duration of the optimisation.
Validity
It is possible to constrain the Site Roads and Site Cables layers using child Layer Validity logic in a similar fashion to Site Layers, etc. In this way, access roads and collector system can be restricted to existing easements and signed land.
Cost Multipliers
In addition to being able to set the upgrade cost of the roads, setting a polygon or raster layer to act as a cost multiplier layer can be used to discourage the access roads and collector system from using certain areas. Examples of the use of cost multiplier polygons might be to represent boggy, rugged, or forested areas. A geotechnical survey could provide the basis for a cost multiplier raster.
Notes on optimisation with respect to cost rather than energy:
•It is important to set the correct minimum turbine spacing to avoid layouts which would result in unacceptable fatigue loading as the OCOE will tend to bunch turbines closer together to reduce cabling and road costs. In general, the purpose of minimum turbine separation distances is to protect turbines from excessive fatigue caused by wake-induced turbulence. When using the optimiser for cost of energy it is particularly important to protect turbines in this way as the algorithm is attempting to minimise BOP costs.
•The OCOE is more prone than standard energy optimisation to the problem of local minima. These are solutions which are attractive compared to other, similar layouts, but not compared to some very different layouts, which the software never finds. This problem can occur because groups of turbines share the costs of the roads and cabling connecting them. Removing a single turbine from a group often causes an increase in the cost of energy for that group; furthermore, placing a single turbine in an area devoid of turbines creates a high cost of energy for that turbine. As a result, there is a significant barrier inhibiting the software from migrating a group of turbines from one area into other, potentially more attractive area. To work around this problem, it is recommended that the user run several optimisations from different random or user-input starting placements in order to attempt to find the global minimum, or true minimum cost-of-energy layout. Another suggestion is to start the OCOE with the turbines in the windiest locations (see optimiser settings). Note that some form of biologically inspired algorithms (e.g. particle swarm, genetic etc.) could very likely solve the local-minimum problem, but they would cause the optimisation process to take a prohibitive amount of time on a single node. We are currently collaborating with NREL as well as several large developers to apply cloud computing to the problem.
•It should be noted that the OCOE module can be used to estimate the cost of energy of an existing layout but simply ticking the Enable Cost of Energy checkbox in the operations menu and then hitting Calculate Cost of Energy, also in the operations menu. In this case the user needs to take responsibility for making sure that it is possible for the road and collector system optimisers to reach all turbines.
•Please make sure that the buildable area of the turbines is a subset of the buildable area of the roads and cables. In particular, the maximum steepness for turbine placement (as limited by a slope raster) should be significantly less than the maximum steepness of the roads.
•Please make sure the buildable area of the substations (when using substation optimisation) is a subset of the collector system buildable area.
