Trying to fix global natural gas consumption - not working

Nbiswas2 commented 3 months ago

I am trying to fix global primary natural gas consumption based on a forecast. I am NOT interested in the distribution to the end-use commodities or the sub-technologies. Just the overall natural gas consumption for primary energy. The 1.5 deg C reference case output vs targeted natural gas consumption are provided below:

| 1990 | 2005 | 2010 | 2015 | 2020 | 2025 | 2030 | 2035 | 2040 | 2045 | 2050 | 2055 | 2060 | 2065 | 2070 | 2075 | 2080 | 2085 | 2090 | 2095 | 2100 -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- desired NG consumption (EJ) | 57.94005 | 74.99215 | 88.71963 | 91.5236 | 95.6181 | 82.77207 | 87.10042 | 89.39205 | 91.73987 | 94.33283 | 96.63343 | 99.0768 | 100.7232 | 101.6182 | 95.00337 | 91.39136 | 87.10674 | 84.2463 | 81.36769 | 78.30786 | 74.31207 Model Reference case (EJ) | 57.94005 | 74.99215 | 88.71963 | 91.5236 | 95.6181 | 74.5926 | 78.49323 | 80.55841 | 82.67421 | 85.01094 | 87.0842 | 89.28612 | 90.76984 | 91.57638 | 85.61522 | 82.36014 | 78.49892 | 75.92115 | 73.327 | 70.56955 | 66.96861

I tried to use the following method to feed in the desired natural gas primary energy consumptions:

'

subsidy Global

-1000

95.61809641

-1000

82.77206506

-1000

87.10041888

-1000

89.39205342

But this has been giving an error - "ERROR:No Discrete Choice function set in Global, gas processing" (attached main log) . I have also attached the files for configuration and the subsidy structure file

NG_feasiblerange.txt

configuration_NG_1P5C_constrainedNG.txt

main_log.txt

I have no clue how to move ahead.

pkyle commented 3 months ago

There is no region called "Global" The policy portfolio standard file should have the extension ".xml" (I assume? Never tried running a txt file before) and should be copied by all 32 regions in similar fashion to most other files in the input/policy directory (see e.g. carbon_tax_10_5.xml. Each region should be assigned the same market which can be called "global" if you want to stick with our naming conventions, though really it could be called anything as long as it's the same market name assigned in each region. The values of the constraint need only be specified in one region (any one will work as all others share the market), and the min-price doesn't need to be copied by each time period since the string fillout="1" will copy it forward. But there's also no harm in copying it a bunch of times.

Nbiswas2 commented 3 months ago

Hi @pkyle Thank you so much for helping out again. I had uploaded txt instead of xml because I wasn't able to upload anything apart from zip, txt, pdf or docx. I will correct my file and try running again. Thank you

Nbiswas2 commented 2 months ago

There is no region called "Global" The policy portfolio standard file should have the extension ".xml" (I assume? Never tried running a txt file before) and should be copied by all 32 regions in similar fashion to most other files in the input/policy directory (see e.g. carbon_tax_10_5.xml. Each region should be assigned the same market which can be called "global" if you want to stick with our naming conventions, though really it could be called anything as long as it's the same market name assigned in each region. The values of the constraint need only be specified in one region (any one will work as all others share the market), and the min-price doesn't need to be copied by each time period since the string fillout="1" will copy it forward. But there's also no harm in copying it a bunch of times.

@pkyle

Thank you for helping with this. However, I had a follow up question please.

Is there any means to shut off 'traded natural gas'.

I haven't been able to achieve the desired results.

The method that I tried is in this txt file (converted from xml) NG_feasiblerange.txt

this is the output that I have received: <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

| 1990 | 2005 | 2010 | 2015 | 2020 | 2025 | 2030 | 2035 | 2040 | 2045 | 2050 | 2055 | 2060 | 2065 | 2070 | 2075 | 2080 | 2085 | 2090 | 2095 | 2100 -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- target total natural gas | 57.9400549 | 74.9921501 | 88.7196319 | 91.52360191 | 95.61809641 | 82.77206506 | 87.10041888 | 89.39205342 | 91.73986936 | 94.33283065 | 96.63342965 | 99.0768031 | 100.7232169 | 101.618198 | 95.0033734 | 91.3913567 | 87.10673544 | 84.24629713 | 81.36768538 | 78.30786403 | 74.31206624 model output: b natural gas | 57.9400549 | 74.9921501 | 88.7196319 | 91.52360191 | 95.61819691 | 74.59257146 | 78.4930835 | 80.5583715 | 82.6741022 | 85.0108824 | 87.0840041 | 89.2860241 | 90.7696405 | 91.5761296 | 85.6150721 | 82.3598947 | 78.49854862 | 75.92076203 | 73.32683808 | 70.56929224 | 66.9684677 model output: traded natural gas | 12.20877588 | 23.70726638 | 26.32258 | 31.8291728 | 37.41871276 | 33.44562853 | 37.42052131 | 42.81020568 | 48.7843507 | 56.2543714 | 63.9488107 | 71.064927 | 77.3882067 | 82.5501484 | 82.1675155 | 83.6989043 | 84.2886671 | 85.4712598 | 85.2353263 | 84.4892534 | 83.6768875

pkyle commented 2 months ago

The NG_feasiblerange.xml file has the incorrect structure in the policy portfolio standard parts. Everything looks good through the min-price line, but then it seems to switch to the structure of a technology, not a policy, and uses fixedOutput, which we wouldn't want here even if we could apply it. The structure should look like this, for a single policy that restricts the consumption of natural gas in 2020, in two regions:

        <region name="USA">
        <policy-portfolio-standard name="Gas-Limit">
            <policyType>subsidy</policyType>
        <market>Global</market>
        <min-price year="2020" fillout="1">-1000</min-price>
                <constraint year="2020">95.61809641</constraint>
        </policy-portfolio-standard>
        <supplysector name="gas processing">
        <subsector name="natural gas">
        <stub-technology name="natural gas">
                   <period year="2020">
                       <input-subsidy name="Gas-Limit"/>
                   </period>
        </stub-technology>                   
            </subsector>
        </supplysector>
    </region>
    <region name="Canada">
        <policy-portfolio-standard name="Gas-Limit">
        <market>Global</market>        
        </policy-portfolio-standard>
        <supplysector name="gas processing">
        <subsector name="natural gas">
        <stub-technology name="natural gas">
                   <period year="2020">
                       <input-subsidy name="Gas-Limit"/>
                   </period>
        </stub-technology>                   
            </subsector>
        </supplysector>

So, the policy portfolio standard is written to each region, with the market-name identified, but the constraints and other attributes only need to be specified in one region (you can do others, but it sets up the possibility of disagreement, involves a bunch of unnecessary copying). Each region has its gas processing/natural gas/natural gas technology assigned an input of the policy. Note that you could also put this as in input to this same technology in the global technology database, and wouldn't have to copy that text by 32 regions. It's the same either way here because the policy is global, applied equally to all regions. This structure of using stub-technologies might be useful if you ever decide you want to exempt certain regions from the constraint, or set up region-specific constraints. As a final note, I usually use input-subsidy when I expect a policy to increase output from a baseline scenario, and input-tax when I expect that the policy will decrease output. Then the prices of the policy are positive. Because you're allowing prices to go negative, this should work, but it might be a bit counter-intuitive in the interpretation, and could make it harder for the model to solve; I don't know. If you just replace the string subsidy with tax throughout the file, that will correctly switch the policyType and the input-* objects throughout the file.

Nbiswas2 commented 2 months ago

The NG_feasiblerange.xml file has the incorrect structure in the policy portfolio standard parts. Everything looks good through the min-price line, but then it seems to switch to the structure of a technology, not a policy, and uses fixedOutput, which we wouldn't want here even if we could apply it. The structure should look like this, for a single policy that restricts the consumption of natural gas in 2020, in two regions:
        <region name="USA">
      <policy-portfolio-standard name="Gas-Limit">
          <policyType>subsidy</policyType>
      <market>Global</market>
      <min-price year="2020" fillout="1">-1000</min-price>
              <constraint year="2020">95.61809641</constraint>
      </policy-portfolio-standard>
      <supplysector name="gas processing">
      <subsector name="natural gas">
      <stub-technology name="natural gas">
                   <period year="2020">
                       <input-subsidy name="Gas-Limit"/>
                   </period>
      </stub-technology>                   
          </subsector>
      </supplysector>
  </region>
  <region name="Canada">
      <policy-portfolio-standard name="Gas-Limit">
      <market>Global</market>        
      </policy-portfolio-standard>
      <supplysector name="gas processing">
      <subsector name="natural gas">
      <stub-technology name="natural gas">
                   <period year="2020">
                       <input-subsidy name="Gas-Limit"/>
                   </period>
      </stub-technology>                   
          </subsector>
      </supplysector>
So, the policy portfolio standard is written to each region, with the market-name identified, but the constraints and other attributes only need to be specified in one region (you can do others, but it sets up the possibility of disagreement, involves a bunch of unnecessary copying). Each region has its gas processing/natural gas/natural gas technology assigned an input of the policy. Note that you could also put this as in input to this same technology in the global technology database, and wouldn't have to copy that text by 32 regions. It's the same either way here because the policy is global, applied equally to all regions. This structure of using stub-technologies might be useful if you ever decide you want to exempt certain regions from the constraint, or set up region-specific constraints. As a final note, I usually use input-subsidy when I expect a policy to increase output from a baseline scenario, and input-tax when I expect that the policy will decrease output. Then the prices of the policy are positive. Because you're allowing prices to go negative, this should work, but it might be a bit counter-intuitive in the interpretation, and could make it harder for the model to solve; I don't know. If you just replace the string subsidy with tax throughout the file, that will correctly switch the policyType and the input-* objects throughout the file.

@pkyle

Thank you for these inputs. I did try to work on this method, from your previous suggestions. This is the format that I had used: NG_feasiblerange (previous version).txt

But in this case also, I wasn't able to tweak the NG consumptions as per target values. :(

pkyle commented 2 months ago

I'm surprised that doesn't crash the model. The supplysector is not embedded within a policy portfolio standard; see the structure of the example I mocked up in the prior message, and compare that with the (previous version) of your policy file. The policy-portfolio-standard tag should be closed before opening up supplysector

Nbiswas2 commented 2 months ago

I'm surprised that doesn't crash the model. The supplysector is not embedded within a policy portfolio standard; see the structure of the example I mocked up in the prior message, and compare that with the (previous version) of your policy file. The policy-portfolio-standard tag should be closed before opening up supplysector

Hi @pkyle

I corrected the xml file as per your suggestion (I hope this is correct) : NG_feasiblerange.txt

However I get the following error:

"SEVERE ERROR:Unrecognized policy type: SEVERE ERROR:Valid policy type strings include: tax, RES, subsidy"

Do you think I should use

subsidy

for each region?

pkyle commented 2 months ago

Oh maybe each region needs to have its policy type specified. Looks like it just wasn't inheriting the value from the global policy. So, in my text block above, I should have had:

<region name="Canada">
        <policy-portfolio-standard name="Gas-Limit">
        <policyType>subsidy</policyType>
        <market>Global</market>        
        </policy-portfolio-standard>

pkyle commented 2 months ago

Just to close out this issue, here's a version of the file that works. One of the issues is that apparently to be binding, global constraints values need to be read to all regions (in contrast to other policies like GHG constraints where just reading it into one region suffices). Adopting the same convention of re-setting the file extension to txt in order to get it to upload NG_feasiblerange.txt

JGCRI / gcam-core

Trying to fix global natural gas consumption - not working #407