Update of the centralised optimisation algorithm #3260
Conversation
Introduction of all relevant classes and the functions necessary to build the domain (the domain summarises the boundary conditions for the optimisation of the energy system in the respective scenario's zone)
This commit introduces a new data base of energy carriers. It is a bit simpler than the 'feedstock'-database used by the old optimisation algorithm. Energy potentials are also linked to these energy carriers in this commit.
The schemas now contain then new 'ENERGY_CARRIERS' database.
Fixing a few typos in the database and adding it to the reference-case to fix workflows.
This portion of the script creates new networks based on the connected buildings given by the 'individual' and calculates their operating conditions (this is largely based on the existing network scripts)
|
@shanshanhsieh , @lguilhermers whenever you find the time to review yesterday's commit ('introducing networks') could you check if the following code lines make sense to you? These parts were all taken from the old thermal networks script. line 124 line 189 line 470 line 475-477 |
cea/technologies/constants.py
Outdated
| @@ -79,3 +79,8 @@ | |||
|
|
|||
| #natural gas conncetion | |||
| GAS_CONNECTION_COST = 15.5 / 1000 # CHF / W, from Energie360 15.5 CHF / kW | |||
|
|
|||
| # Thermal Network | |||
| TYPE_MAT_DEFAULT = 'T1' | |||
There was a problem hiding this comment.
Unclear to me what this variable means, is it material type? Perhaps add a comment to make more clear. Pipe diameter is self explanatory, but I would add the units is being considered, just for documentations
There was a problem hiding this comment.
Yes. this is meant to declare the type of pipes (material and construction) that is used for the network. This is based on the existing thermal network code. I added a comment in the constants-file.
However, I just realised, that the pipe type is currently a bit meaningless. The only method this could play into is the calc_linear_thermal_loss_coefficient-function from simplified_thermal_network.py, but the function assumes a constant construction (steel pipe + calcium silicate insulation). So, there is currently no database in CEA specifying the properties of these types, but that could be added in the future.
There was a problem hiding this comment.
Got it! Could it be relevant for the LCA parts, perhaps?
| index_closest_mean_temp = (thermal_energy_carriers['mean_qual'] - temperature).abs().nsmallest(n=1).index[0] | ||
| energy_carrier_code = thermal_energy_carriers['code'].iloc[index_closest_mean_temp] | ||
| else: | ||
| energy_carrier_code = "T???" |
There was a problem hiding this comment.
Yes, that is a placeholder for now. I'm currently linking that up. Should be part of the next bigger commit at the end of this week.
|
In ENERGY_CARRIERS.xlsx, does it make sense to dfine a default for all thermal and radiation costs and ghg to 0.0? Or you expect to find some values for it? (In the case of leaving it blank bringing errors later on) |
both FT_TO_M seem reduntant to me, as it is a constant factor. |
This seems to me a safety factor, as you pointed. I think it should be declared before and individually, for clarity. Not sure how it would scale, but my guess is that it is for each substation. |
I agree, even the comment says it is to account for return, which is calculated right before, so it seems logical to change that as well. |
I think if the cells of a .csv-file are empty, they get read as 0.0 by default. But I'll check that either today or tomorrow. |
Small changes following the review of @lguilhermers .
Introduced two new classes describing energy carriers and energy flows. The latter is essentially a time series of quantities of a given energy carrier being transferred from a category of supply system components to another.
These changes introduce a new tab to the 'Optimization'-section of the front-end. Databases and the example reference case are also updated to match the new selection of components that can be installed in the supply system.
component choices were corrected and 'OrderedMultiChoiceParameter' was made a child of 'MultiChoiceParameter' instead of 'ChoiceParameter'
These changes build a district energy system for a given domain, including networks and supply system demands. The complete supply systems structure with its components and their corresponding capacities and operational modes are not yet implemented, however.
Added component model complexity parameter to the dashboard. In a first phase only 'constant' will work. This assumes a constant efficiency rating for all components.
Updated energy carrier and conversion (new) databases. This is linked to the introduction of the new component class and the new constant efficiency models for each of the supply system components.
Some of the config-inputs being called from different scripts caused the script to not be launched in the front end. This fix introduces the relevant parameters to the optimization-script's dashboard page to fix this.
Change folder structure for more clarity
Removing potentials from the expected input-files, to avoid inconsistent errors when only some potentials are considered in the optimization.
Implimented a first version of a tracker for the optimisation that is activated by setting debug=true
GHG emissions are no longer reduced if a supply system exports energy.
expand schemas to include files created by the optimization tracker
A bug was introduced into the thermal networks script when it was copied into the optimization script. This fix reverts this bug.
Previously to this fix, the mutation and recombination of capacity indicator vectors could effectively lead to a understocked supply systems (i.e. supply systems that could not meet the necessary demand, and would simply neglect part of the demand). This fix makes sure the supply system always offers the necessary capacity and meets demand.
Before this fix, passive components did not get properly activated when building the 'SupplySystemStructure'-object and therefore let to errors raising a mismatch between energy carriers of demand and what the installed components can supply.
This change finally allows for multiprocessing to work on the new optimization branch.
|
Would you be able to give the multiprocessing a go on Mac. If that works and you can't see any other immediate issues, I think we can merge. I'm sure, as people use it, more errors/unexpected behaviors will become apparent, but I think it would be easier to handle fixes to those through normal issues from here on out. |
lowered minimum capacity of some components, to allow for an adequate supply system component to be installed in small stand-alone buildings.
|
Hi @MatNif |
Prior to this fix, the pareto-optimal supply systems layouts of the different thermal networks were not combined properly, leading to skewed results and inconsistent improvements in the overall pareto-front. This fix rectifies that error.
This fix takes into account that supply systems might not have a component in each of the supply system categories and adapts the criteria for building the capacity indicator vectors accordingly.
If multiprocessing was set to false and 'generate-detailed-outputs' to true, the code would run into an error because the 'tracker' object was not initialized. This fixes that error.
|
@MatNif |
The tracker is generated only in debug mode (config.general.debug = true) and not when 'detailed outputs' are generated. This change corrects yesterday's fix accordingly.
|
@MatNif should the "new" database files replace the old ones? |
|
Hi @reyery, |
** this is ongoing work, the PR is launched to make the review easier, I will update this message when the branch is ready for a final review before the merge **
The new optimisation problem this update is based on is described in issue #3254.
The code structure is described in the class diagram here, which will be updated regularly to reflect the latest changes of the code.