Optconfig #37
Optconfig #37
Conversation
| @@ -37,13 +37,43 @@ struct OptVariable{T,N,Ax,L<:NTuple{N,Dict}} <: AbstractArray{T,N} | |||
| type::String | |||
| end | |||
|
|
|||
| """ | |||
| OptConfig{tech::Dict{String,Bool} | |||
| model::Dict{String,Bool} | |||
There was a problem hiding this comment.
The docs does not seem to be the same as the code here
| limit_emission=get_limit_dir(limit_emission) | ||
| #Setup the config file based on the data input and | ||
| config=set_config_cep(opt_data; descriptor=descriptor, limit_emission=limit_emission, lost_load_cost=lost_load_cost, lost_emission_cost=lost_emission_cost, infrastructure=infrastructure, demand=demand, non_dispatchable_generation=non_dispatchable_generation, dispatchable_generation=dispatchable_generation, storage=storage, conversion=conversion, seasonalstorage=seasonalstorage, transmission=transmission, scale=scale, print_flag=print_flag, optimizer_config=optimizer_config, round_sigdigits=round_sigdigits, region=opt_data.region, time_series=Dict{String,Any}("years" => ts_data.years, "K" => ts_data.K, "T"=> ts_data.T, "config" => time_series_config, "weights"=>ts_data.weights, "delta_t"=>ts_data.delta_t)) | ||
| kwargs...) |
There was a problem hiding this comment.
I see why you are replacing the explicit keyword arguments by kwargs. However, I am not sure if that enhances usability, I think it may do the opposite. As a user, I like to look at the one function I am exposed to (run_opt), and check out the arguments that I can give it. If the most important arguments are within a kwargs, then the functionality is hidden and it makes it more complicated to figure out what the different options are that I can use.
Adding to the documentation of the OptConfig struct that the input arguments in run_opt have to be modified any time that OptConfig is modified may be better. [In general, that is the reason why I am not 100% convinced if an OptConfig struct makes the code better. It adds complexity in terms of in how many places the definition of the config shows up.]
There was a problem hiding this comment.
Those are good arguments.
There was a problem hiding this comment.
The main idea of introducing OptConfig is the separation of:
- Selecting the settings for the optimization
- Running the optimization
I intended to keep therun_optwith all keywords-function alive, but move to first setting up the settings and running the optimization later (as shown in the example).
| - `descriptor`: String with the name of this paricular model like "kmeans-10-co2-500" | ||
| - `print_flag`: Bool to decide if a summary of the Optimization result should be printed. | ||
| - `optimizer_config`: Each Symbol and the corresponding value in the Dictionary is passed on to the `with_optimizer` function in addition to the `optimizer`. For Gurobi an example Dictionary could look like `Dict{Symbol,Any}(:Method => 2, :OutputFlag => 0, :Threads => 2)` more information can be found in the optimizer specific documentation. | ||
| - `round_sigdigits`: Can be used to round the values of the result to a certain number of `sigdigits`. |
There was a problem hiding this comment.
Some of the inputs are missing in the list here (e.g. time_series)
src/utils/datastructs.jl
Outdated
| print_flag::Bool=true, | ||
| optimizer_config::Dict{Symbol,Any}=Dict{Symbol,Any}(), | ||
| round_sigdigits::Int=9, | ||
| time_series::Dict{String,Any}=Dict{String,Any}()) |
There was a problem hiding this comment.
what's the difference between time_series and ts_data?
There was a problem hiding this comment.
This basically only contains some general information about the time_series data - not ClustData
|
Furthermore, checks are failing. |
…he optimization (run_opt)
config::Dict{String,Any}replaced byconfig::OptConfig1e6to 700