Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • R remind
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 19
    • Issues 19
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Jerome Hilaire
  • remind
  • Issues
  • #286

Closed
Open
Created Dec 02, 2020 by Michaja Pehl@pehlContributor

geohdr infeasibilities

tl;dr: EDGE-Transport needs to stop messing with the past like a naughty time traveller. ;)

I'm pretty confident I found the origin of the infeasibilities having to do with geohdr capacity in the first free time step.

Ultimately, it is caused by EDGE_transport.R modifying the values of p35_fe2es https://github.com/remindmodel/remind/blob/547ba8f7be1bfc8adbd9cf1c39438089e9c0b174/modules/35_transport/edge_esm/presolve.gms#L13-L19 These end up in the fulldata.gdx, which becomes the input_ref.gdx for the next run, where they are loaded, overwriting the data from ./modules/35_transport/edge_esm/input/fe2es.cs4r. https://github.com/remindmodel/remind/blob/547ba8f7be1bfc8adbd9cf1c39438089e9c0b174/modules/35_transport/edge_esm/datainput.gms#L50-L54

Then, different pm_fe2es values change the result of initialcap2, specifically v05_INIcap0/pm_cap0, which trickles down to change the vintage capital structure of geohdr through pm_cap0 → s05_aux_tot_prod → s05_aux_prod_remaining → p05_aux_prod_thisgrade → p05_aux_cap_distr → p05_aux_cap → sm_tmp → vm_capDistr.fx: https://github.com/remindmodel/remind/blob/547ba8f7be1bfc8adbd9cf1c39438089e9c0b174/modules/05_initialCap/on/preloop.gms#L145-L182

Then, depending on region and scenario settings, it is possible that (a) CONOPT is in a weird spot it can't find out of (my Npi run) or (b) the modified vintage capacity is so high that capacity × capacity factor exceeds pm_dataren(regi,"maxprod",rlf,te) (FelixNSW run) – which isn't a problem for the fixed time-steps, asq_limitProd` is defined only over the free ones.

@LaviniaBaumstark @dklein-pik @giannou (In lieu of a RSE github team): I think it's problematic that a run, that is supposed to be fixed on a different run up to some point, has a different vintage structure. I was always puzzled by the fact that initialcap2 is run for every run. This seems not only to be the case for geohdr, but other technologies too. Small thing that doesn't show up in the results (vm_cap is still the same), but this bug wouldn't happened without initialcap2 running again, although its results should be the same in any case.

In any case, preserving the 2005 values of pm_fe2es at the ./modules/35_transport/edge_esm/input/fe2es.cs4r levels should fix this.


Evidence/notes using the failed DeepEl3 Npi run as an example: /p/tmp/pehl/Remind_DeepEl/output/TraInd-Npi_2020-11-27_16.06.51

$ gdxdiff input_ref.gdx non_optimal.gdx id=pm_cap0,pm_EN_demand_from_initialcap2,pm_cesdata,pm_shFeCes,pm_fe2es,pm_cf,pm_data,pm_prodCouple,p35_fe2es,EDGE_scenario
GDXDIFF          31.1.1 r4b06116 Released May 16, 2020 LEG x86 64bit/Linux    
File1 : input_ref.gdx
File2 : non_optimal.gdx
Id    : pm_cap0 pm_EN_demand_from_initialcap2 pm_cesdata pm_shFeCes pm_fe2es pm_cf pm_data pm_prodCouple p35_fe2es EDGE_scenario
Summary of differences:
                      pm_cap0   Data are different
                        pm_cf   Data are different
                      pm_data   Data are different
pm_EN_demand_from_initialcap2   Data are different
                     pm_fe2es   Data are different
                   pm_shFeCes   Data are different
Output: diffile.gdx
GDXDiff finished
$ dumpgdx diffile.gdx vm_deltaCap "CHA.*geohdr.*L\>" | head
1995  CHA  geohdr  1  dif1  L  8.2494690248504E-8
1995  CHA  geohdr  1  dif2  L  8.24965476551363E-8
2000  CHA  geohdr  1  dif1  L  1.42715686791135E-6
2000  CHA  geohdr  1  dif2  L  1.42718900101742E-6
2015  CHA  geohdr  1  dif1  L  0.000906719440325381
2015  CHA  geohdr  1  dif2  L  0.000906719440325381
2020  CHA  geohdr  1  dif1  L  3.4181901481737E-5
2020  CHA  geohdr  1  dif2  L  3.4181901481737E-5
2030  CHA  geohdr  1  dif1  L  0.000100553100549173
2030  CHA  geohdr  1  dif2  L  0.000100553067898506
$ dumpgdx diffile.gdx pm_cap0 "CHA.*geohdr"
CHA  geohdr  dif1  1.49901612654113E-5
CHA  geohdr  dif2  1.4990498775921E-5
$ dumpgdx diffile.gdx pm_fe2es "2005.*CHA"
2005  CHA  te_espet_pass_sm  dif1  32.7810653744073
2005  CHA  te_espet_pass_sm  dif2  32.7803397536317
2005  CHA  te_esdie_pass_sm  dif1  72.8208842393301
2005  CHA  te_esdie_pass_sm  dif2  72.6703864713621
2005  CHA  te_eselt_pass_sm  dif1  274.077206442013
2005  CHA  te_eselt_pass_sm  dif2  276.29708722215
2005  CHA  te_esh2t_pass_sm  dif1  64.7583317381968
2005  CHA  te_esh2t_pass_sm  dif2  64.742052256529
2005  CHA  te_esgat_pass_sm  dif1  66.8262951982073
2005  CHA  te_esgat_pass_sm  dif2  67.1300018776568
2005  CHA  te_esdie_frgt_sm  dif1  35.041588297353
2005  CHA  te_esdie_frgt_sm  dif2  34.9779610388119
2005  CHA  te_eselt_frgt_sm  dif1  226.082090011469
2005  CHA  te_eselt_frgt_sm  dif2  226.082090011469
2005  CHA  te_esh2t_frgt_sm  dif1  33.3906087857954
2005  CHA  te_esh2t_frgt_sm  dif2  33.391690768669
2005  CHA  te_esgat_frgt_sm  dif1  13.2919587450842
2005  CHA  te_esgat_frgt_sm  dif2  13.3447480682688
Assignee
Assign to
Time tracking