Trying to fix global natural gas consumption - not working about gcam-core HOT 9 CLOSED

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.

from gcam-core.

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

from gcam-core.

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:

from gcam-core.

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.

from gcam-core.

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. :(

from gcam-core.

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

from gcam-core.

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?

from gcam-core.

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>

from gcam-core.

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

from gcam-core.