Grid2op / chronix2grid

https://chronix2grid.readthedocs.io/en/latest/?
Mozilla Public License 2.0
19 stars 5 forks source link

Chronix2grid constantly fails when asking to generate several scenarios #33

Closed marota closed 2 years ago

marota commented 3 years ago

When you put --n_scenarios>=2, whatever the seed or the starting date, chronix2grid seems to fail. Pypsa OPF cannot be solved probably because of some inconsistent data as input.

--> OPF formulation by => month - Analyzing month # 2 INFO:pypsa.linopf:Prepare linear problem INFO:pypsa.linopf:Total preparation time: 0.91s INFO:pypsa.linopf:Solve linear problem using Cbc solver WARNING:pypsa.linopf:Optimization failed with status warning and termination condition infeasible OPF failed to find an optimal solution Total time 0.04 min OPF Done...... Saving results for the grids with individual generators... applying noise to forecast of 0.01 %

Example command: chronix2grid --mode LRT --output-folder ChroniX2Grid_path/output_data --input-folder ChroniX2Grid_path/getting_started/example/input --ignore-warnings --weeks 1 --case case118_l2rpn_wcci --n_scenarios 3 --nb_core 1 --scenario_name february --start-date 2012-02-01

NMegel commented 3 years ago

I don't have this problem with case case118_l2rpn_neurips_1x. For instance launch: chronix2grid --n_scenarios 2

But I could indeed reproduce the error in OPF with case118_l2rpn_wcci. I tried to launch it with the same seed (1114455947) but in 2 different ways:

It appears that the net load is exactly the same just as expected. But the generators loaded in the pypsa network are not the same. See differences in generators_alone and generators second_scenario in this zip (line 11 for example)

Diff in networks.zip

I noticed it comes from the grid2op environment since its loading in EconomicDispatch.init_dispatcher_from_config

NMegel commented 3 years ago

The problem is that the modifications on Pmax and Ramps applied on hydro and slack generators are propagated to the grid2op environment of the second scenario. So these modifications are applied twice and cause unsolvable OPF It is strange because it is read from disk. We have to figure out why, maybe by performing copies of environments

With this params_opf, all works normally

safe_params_opf.zip

NMegel commented 3 years ago

After discussion, we should not act directly on grid2op envs (because pmax and ramps are static properties) but rather create an intermediate brick that changes pmax and ramps before loading in pypsa

NMegel commented 3 years ago

Done in commit 57c0dc5b37be75cde93b48c80b4574d2758bdd63 Have to check integration tests

NMegel commented 3 years ago

Everything should be OK in commit f588fcbdae027af06815b8f63a7607da16753907 - including tests