Veda2.0 Released!


Emissions not being produced
#1
I'm trying to include brine released from desalination processes.

The simple approach I'm taking is by utilizing the ~PRCCOMEMI table similar to air emissions from power plants that utilize fossil fuels. I have calculated a factor which once multiplied by the amount of distilled water produced will give the brine amount.

The issue I am facing is that nothing is entering into the brine commodity that I have defined and therefore there are no brine results.

Note that the difference in calculations attempt between air emissions and this sea emission is that the air emissions have fuels as input to the plants while the sea emission is calculated based on the plant output which is the distilled water. And that the amount of distilled water is calculated based on CEH and CHPR.


Any tips are highly appreciated.

Thanks
Reply
#2
I don't know why your specification does not work, but Amit has said earlier on this Forum: "I strongly discourage the use of tables COMAGG, COMEMI and PRCCOMEMI. These were introduced in VEDA to make life simpler when working with MARKAL."  So, is there a reason why have you chosen to use  PRCCOMEMI with TIMES?

You can use FLO_EMIS to define emission factors on any process flows. You can do that in TFM_INS, TFM_DINS and FI_T tables. Just define the source commodity in Other_indexes.  Example:


I guess PRCCOMEMI is actually translated to FLO_EMIS, but to see why it does not work in your case would require more information.
Reply
#3
thanks Antti Smile
Reply
#4
(04-02-2020, 04:52 PM)Antti-L Wrote: I don't know why your specification does not work, but Amit has said earlier on this Forum: "I strongly discourage the use of tables COMAGG, COMEMI and PRCCOMEMI. These were introduced in VEDA to make life simpler when working with MARKAL."  So, is there a reason why have you chosen to use  PRCCOMEMI with TIMES?

You can use FLO_EMIS to define emission factors on any process flows. You can do that in TFM_INS, TFM_DINS and FI_T tables. Just define the source commodity in Other_indexes.  Example:


I guess PRCCOMEMI is actually translated to FLO_EMIS, but to see why it does not work in your case would require more information.

This works. Thank you very much for your help and prompt response Smile
Reply
#5
Dear Amit and Antti,

I would like to get your help with the issue related to assigning emissions to commodities/processes in TIMES (Flo_Emis attribute).

My issue in short: I would like the model to assign a CO2 emissions factor to each unit of electricity used by electricity consuming heat generation technologies, such as electric boilers and heat pumps, which are all named starting with "EH" (as is indicated in the TFM_INS table in Pic1). 
The attached Pic1 shows my version of the TFM_INS table inspired by the example from Antti above.

On the Pic2, you can see the TFM_INS table being translated into the Veda format. Pic3 shows that the IMPCO2 commodity is recognized as being one of the output commodities from one of the relevant processes (a heat pump).

However, when it comes to the modeling results I do not see any IMPCO2 commodity reported by the model even though the processes that use ELCELC for heat generation do generate heat and should be having associated CO2 emissions (see Pic 4).

could you please help me understand what I am doing wrong.
Thanks you,
Dmytro


Attached Files Thumbnail(s)
               
Reply
#6
Hmm...  I am not able to see what might be wrong, but you are not displaying all the details.  For example, the emissions are defined only for the GOT region, but you are not showing the region index in the results table. Is GOT the only region in the model?

Could you perhaps post the *.DD file for the scenario Subannual_El_Emfa where you define the parameters, and the listing file (*.LST) if possible (zipped), to see if they reveal anything suspicious?
Reply
#7
(09-11-2023, 09:00 PM)Antti-L Wrote: Hmm...  I am not able to see what might be wrong, but you are not displaying all the details.  For example, the emissions are defined only for the GOT region, but you are not showing the region index in the results table. Is GOT the only region in the model?

Could you perhaps post the *.DD file for the scenario Subannual_El_Emfa where you define the parameters, and the listing file if possible (zipped), to see if they reveal anything suspicious?

Dear Antti,

thank you so much for the quick reply.

The answer is yes, there is only one region in the model. 
And yes, I could certainly share the files you indicated with you.

However, after receiving your answer I did manage to find the mistake myself. It turns out that I was trying to make changes to the Scenario file with the emissions factors all day (without success) without including that file to the list of files of the Scenario Group I am running.  Confused 
Now I add the file to the list and everything works as it should - emissions are calculated for every unit of electricity consumed.

Sometimes it help to simply relax, I guess...

Anyhow, thanks again for getting back to me and, by this, for provoking my thought process.

Best regards,
Dmytro
Reply
#8
Thanks.  Yes, I have done that mistake myself, and that was one reason to ask for the DD file (which would not exist if not included).  Shy
Reply
#9
Dear Antti,

I am sorry, but I need to disturb you again. Hope you do not mind and can help me  Angel

The thing is that I continue struggling with adding CO2 emissions factors related to electricity generation/consumption in a proper way to my model. After I had added the SubAnnual file with the CO2 emissions factors to the model (with your help) I started to see CO2 emissions calculated per electricity consumed and generated. This is great! 
But now I noticed that the calculated values of emissions are not correct. To be more precise, they are correct for some processes and incorrect for others.

Here are details about the model:
- The model focuses on the heating sector -> I want to include CO2 emissions factors for electricity consumed by electric boilers and heat pumps and CO2 emissions factors for electricity generated by CHP plants.
- The model is run up until 2050 and the tables below (with input data and results) are also for 2050
- The model has only one region
- I have chosen a few timeslices (which represent a few hours during a winter day) to present my case.


Problem description:
The pictures 1 and 2 show the TFM_INS tables I made for emission factors to be applied to the consumed and generated electricity, respectively.

The picture 3 shows the results table. This table shows 4 process: two CHP plants with names starting with EC*, and an electric boiler and a heat pumps (names start with EH). We can see all the input and output flows in each timeslice.

Here is what troubles me!
The process ECWCHRDHE (second one) has CO2 emissions calculated properly. The amount of generated electricity multiplied with the emissions factors from the input tables result in correct total emissions numbers. 
BUT, the other CHP plant and the electricity consuming technologies do not have their emissions properly calculated.
If we check the highlighted cells for the 1st CHP plant, we can see that the amount of generated heat is identical in each timeslice. The emissions factors in these timeslices are also almost the same (see input file). BUT, the total amount of generated emissions changes between the timeslices and none of the calculated emissions numbers is correct. 
Same situation is with the electric boiler and the heat pump.


There is more to this. Sad
I have tried another model run with a CO2 emissions cap (picture 4).
With this extra condition, the model gave even more confusing results (picture 5).
With the same negative emissions factors and positive generation of heat and electricity (for CHP plants), the model calculated positive values for the total amount of emitted CO2.  Huh

I have been puzzled about this for a day now and still could not figure out the reason for these results.
Especially confusing that the numbers are correct for one of the CHP plants (also correct in the second scenario).

I would really appreciated your help with this, Antti.
Hope to hear back from you.
Sincerely,
Dmytro


Attached Files Thumbnail(s)
                   
Reply
#10
I am sorry for your trouble with the emissions.

But looking at your pictures, it is not so easy for me either to see what is going on. However, it would be quite easy, if I had a reproducible case.

If you would like me to look at it in detail, could you therefore provide me the full set of model input files (I mean the *.DD and *.RUN files), plus the listing file (*.LST), for example for the first case (without a CO2 cap)?  If you can pack these files into a ZIP file, you could then send me the ZIP via e.g. DropBox, Google Drive or equivalent (you could give the download link in a private Forum message if the data are confidential).
Reply
#11
Dear Antti,

thank you for the prompt response (as usual)!

I will gladly follow your advise and share with you the created zip file via a private Forum message.

Thank you,
Dmytro
Reply
#12
Ok, I was able to reproduce and see what was going on.

In addition to the emission factors you showed for 2050, you had quite different emission factors defined for 2030. Morevover, the processes where you saw those unexpected emissions were vintaged, which means that the emission factors are also vintage-dependent. Taking these factors into account, I was able to calculate and confirm with Excel that the emissions reported were indeed all correct.

I am not sure what is actually causing you the issue here.  Is it that you forgot that you had those very different emission factors for 2030, or is it that you assumed that the emission factors would/should not be vintage-dependent?
Reply
#13
Dear Antti,

thanks again for the quick reply.

You are absolutely right, the emission factors for the year 2030 are significantly different from the factors assumed for 2050. This is because I use electricity price profiles and corresponding electricity-related emissions factors obtained from another model (Balmorel model over the electricity system of Europe). Since the composition of the electricity system changes quite a lot in that model between the years, the emissions factors used in my model as inputs do change noticeably together with the electricity prices profiles assumed for 2030 and 2050.

You are also right that the processes with unexpected emissions are all the NEW processes (invested by the model). And they are marked as vintage-dependent (to have improved efficiencies closer to 2050).

So with this said, what would be your advise Antti?
Since I do have electricity prices and emission factors as inputs from other modelling and want to see their impact on the model outcomes, I am leaning towards the solution of having processes in the SubRES files not vintage-dependent. Would this be a solution? Or maybe some other solution exists?

Appreciate your opinion.
Sincerely,
Dmytro
Reply
#14
Well, assuming that all the ELCELC consumed have equal (positive) IMPCO2 emission factors, and all the ELCEXP produced have equal (negative) EXPCO2 emission factors, my suggestion would be to model those IMPCO2 / EXPCO2 emissions upstream / downstream of those vintaged processes, by using non-vintaged processes there.  So, can you not model those IMPCO2 at the FT-ELCIMP process, and the EXPCO2 at the EXPELCEXP process, which are non-vintaged? Or is there some reason why that solution would not work for you?

Of course, by removing the vintaged characterization from those processes would also work for the emissions, but e.g. the efficiency improvements would then be applied to all vintages (so, for example, the capacity installed in 2030 would also get the efficiency improvements defined for subsequent vintages, e.g. in 2040 and 2050, if the capacity is still available). Therefore, I would recommend the solution I mentioned above instead, whenever it is appropriate for your modeling.
Reply
#15
This is a great suggestion, Antti. Thank you!

I will try to implement this and see how the model reacts.

Really hope everything will work properly this time and I will not bother you with this again Smile

Thank you!
Sincerely,
Dmytro
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)