Veda2.0 Released!


UC_CO2 Trading
#16
But I already gave you a working example, didn't I?

An emissions trading system only sets a cap (bound) on the total amount of emissions that can be emitted by the installations covered by the system.  That cap corresponds to the total amount of allowances, whether they are auctioned off or allocated for free, and the allowances can subsequently be traded.

In your case, I have understood that your model does not include the whole ETS system, but only a single participating country exposed to exogenous prices of emission allowances, and therefore I suggested to use an exogenous trade process (or two processes) for the allowance trading. In such a case one cannot really put a cap on the total amount of allowances in the whole system, but one might still want to put a cap on the total amount of free allowances allocated to the country modeled, in order to have the costs and revenues from the allowance trade correctly reflected. And that is what my example did.

However, you say that "its not good approach for us to summing all ETS quotas."  Therefore, it seems that you are probably trying to model something different than a "cap and trade" system. But I don't quite know what your system looks like, because so far you have not disclosed the design for your ETS system. Maybe you could present the mathematical formulation of your system, so that I would be able to understand how it actually works?
Reply
#17
> Is there any  "enhanced" documentations about User Constraints ?

Yes, the documentation, Part II, describes the User Constraints facility in detail. See Chapter 6.4 User Constraints (pages 272–325). I believe VEDA supports all the features described, except that for timeslice-dynamic constraints one needs to use UC_ATTR(tslvl) instead of UC_TSL.
Reply
#18
(24-05-2021, 10:04 PM)Antti-L Wrote: But I already gave you a working example, didn't I?

An emissions trading system only sets a cap (bound) on the total amount of emissions that can be emitted by the installations covered by the system.  That cap corresponds to the total amount of allowances, whether they are auctioned off or allocated for free, and the allowances can subsequently be traded.

In your case, I have understood that your model does not include the whole ETS system, but only a single participating country exposed to exogenous prices of emission allowances, and therefore I suggested to use an exogenous trade process (or two processes) for the allowance trading. In such a case one cannot really put a cap on the total amount of allowances in the whole system, but one might still want to put a cap on the total amount of free allowances allocated to the country modeled, in order to have the costs and revenues from the allowance trade correctly reflected. And that is what my example did.

However, you say that "its not good approach for us to summing all ETS quotas."  Therefore, it seems that you are probably trying to model something different than a "cap and trade" system. But I don't quite know what your system looks like, because so far you have not disclosed the design for your ETS system. Maybe you could present the mathematical formulation of your system, so that I would be able to understand how it actually works?

Hi Antti in a nutshell, i would like to apply your approach for all (ENV) CO2_* Commodity, SEPARATELY. I have no intent to make a CAP for total amount of free allowances for now. Every facility is unique and belongs to different "CRF" in our reporting obligations. Soo i need to create UC tables base on your example for almost 110, CO2_* "ETS" commodities separately . 
Is it possible ?
Reply
#19
Of course it is possible, I already gave you an example, which you could follow. But to repeat what I said, I don't understand why you would need to handle the emission trade of almost 110 CO2_* "ETS" commodities separately.  If you allow trade in all those emissions, you only need a cap on the total for modeling the impact of the free quotas.

Wouldn't it be a bad modeling approach to model the trade in the 110  CO2_* "ETS" commodities separately, if you can have the same model results by using a single cap?  Can you not explain formally (mathematically) why it would be useful to do it as you suggest?  If you cannot explain it, I don't think it would be good practice...
Reply
#20
(31-05-2021, 03:31 PM)Antti-L Wrote: Of course it is possible, I already gave you an example, which you could follow. But to repeat what I said, I don't understand why you would need to handle the emission trade of almost 110 CO2_* "ETS" commodities separately.  If you allow trade in all those emissions, you only need a cap on the total for modeling the impact of the free quotas.

Wouldn't it be a bad modeling approach to model the trade in the 110  CO2_* "ETS" commodities separately, if you can have the same model results by using a single cap?  Can you not explain formally (mathematically) why it would be useful to do it as you suggest?  If you cannot explain it, I don't think it would be good practice...

Hello Antti, sorry for later answering. I tried to run EU ETS Trading based on your example but it beahe really wierd. My ObjZ is much more higher with applied User constraint where i input free allowances (quotas) higher as emitted in real so ObjZ should be lower because of revenue ? 

  Please could you look at my UC_file (attached) ?
  Thank u.


Attached Files
.xlsx   Scen_CO2_UC_EUETS.xlsx (Size: 42.87 KB / Downloads: 6)
Reply
#21
Sorry, but I am not able to see what is going on in your model, as I cannot see the trade processes, and what else you might have in your model.

But I volunteer to take a look at it, if you can give me this whole test model, to see what is going on in there.
The TIMES input files (all the *.DD and *.RUN from your work folder, zipped) would be sufficient.  You could e.g. send me a Dropbox download link in a private message, but I guess it would be easiest if you could just post those input data files here (zipped).

So, I suspect you have made some mistake(s) related to the trade processes (XIMP-ETS, XEXP-ETS), but because I cannot see your model, it is hard to tell what your mistake is.
Reply
#22
(16-06-2021, 06:53 PM)Antti-L Wrote: Sorry, but I am not able to see what is going on in your model, as I cannot see the trade processes, and what else you might have in your model.

But I volunteer to take a look at it, if you can give me this whole test model, to see what is going on in there.
The TIMES input files (all the *.DD and *.RUN from your work folder, zipped) would be sufficient.  You could e.g. send me a Dropbox download link in a private message, but I guess it would be easiest if you could just post those input data files here (zipped).

So, I suspect you have made some mistake(s) related to the trade processes (XIMP-ETS, XEXP-ETS), but because I cannot see your model, it is hard to tell what your mistake is.

Hi Antti, Here is also "trade" file. And not sure if a wild card * can be used in SubRes file. Maybe this is a problem. I could send u model but need to remove some sensitive names...


Attached Files
.xlsx   SubRES_EU_ETS-Trading.xlsx (Size: 14.5 KB / Downloads: 3)
.xlsx   Scen_CO2_User_Constraint_Allowances.xlsx (Size: 30.67 KB / Downloads: 5)
Reply
#23
Your latest Excel files include a quite different set of CO2_* commodities than what was in your previous scenario file.
That is not very helpful. The idea is that I would like to be able to reproduce the issue you reported earlier, with the earlier (different) EU-ETS model scenario:

> My ObjZ is much more higher with applied User constraint where i input free allowances (quotas) higher as emitted in real so ObjZ should be lower because of revenue ?

I can only reproduce the issue if you provide me with the TIMES input files: the *.DD and *.RUN files from your VEDA work folder, from that very same model run, which produces the issue you reported.  No Excel files are needed at all. Only the *.DD and *.RUN files are required (zipped).
Reply
#24
(17-06-2021, 05:40 PM)Antti-L Wrote: Your latest Excel files include a quite different set of CO2_* commodities than what was in your previous scenario file.
That is not very helpful. The idea is that I would like to be able to reproduce the issue you reported earlier, with the earlier (different) EU-ETS model scenario:

> My ObjZ is much more higher with applied User constraint where i input free allowances (quotas) higher as emitted in real so ObjZ should be lower because of revenue ?

I can only reproduce the issue if you provide me with the TIMES input files: the *.DD and *.RUN files from your VEDA work folder, from that very same model run, which produces the issue you reported.  No Excel files are needed at all. Only the *.DD and *.RUN files are required (zipped).

Hi Antti i managed to fix ObjZ. But why wild card isn´t working in my case ? If you look at the file - User Constraints Allowances, you can notice CO2_HTH*, and that should be CAP of free emissions for CHP and HPL facilities. Can one use  wild card (*) for CO2_HTH11, CO2_HTH48 ...  Attribute- IRE_FLOSUM, Other Indexes- IMP~OUT~CO2_HTH* ? Its not working this way. 

Thnak you.
Reply
#25
I am not a VEDA developer or VEDA expert.

But as far as I know, you are right: You cannot use wildcards in  ~FI_T tables, and I think that you cannot use wildcards in the Other_Indexes column at all (in any table).  In addition, I also believe that you cannot use wildcards or comma-separated lists in ~TFM_DINS or ~TFM_DINS-TS tables.

You could ask the VEDA developers to confirm about the above.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)