Electrolyser Modelling
#16
(06-05-2019, 07:51 PM)Antti-L Wrote: Yes, if NCAP_OLIFE = 10, the lifetime of a plant is 10 years if it runs at 100% load all the time. If it runs at 50% load all the time, the lifetime would be 20 years (NCAP_TLIFE permitting it), and so on.  NCAP_TLIFE should thus be set sufficiently long.

As described in the documentation, NCAP_OLIFE requires that early retirements are enabled and the process is vintaged. In my example early retirements are activated by setting a dummy interpolation option RCAP_BND('0','N')=0.  When the capacity is retired, no fixed or variable O&M costs will occur any longer.


Thank you very much for the clarification. This is very useful when for example modelling batteries, fuel cells and electrolysis.

Pernille
Reply
#17
(06-05-2019, 07:51 PM)Antti-L Wrote: Yes, if NCAP_OLIFE = 10, the lifetime of a plant is 10 years if it runs at 100% load all the time. If it runs at 50% load all the time, the lifetime would be 20 years (NCAP_TLIFE permitting it), and so on.  NCAP_TLIFE should thus be set sufficiently long.

As described in the documentation, NCAP_OLIFE requires that early retirements are enabled and the process is vintaged. In my example early retirements are activated by setting a dummy interpolation option RCAP_BND('0','N')=0.  When the capacity is retired, no fixed or variable O&M costs will occur any longer.


I believe the dummy interpolation option is not an option in Answer-TIMES, true?

For Answer, will early retirements, enabling NCAP_OLIFE, be activated by PRC_RCAP(r, p)=1, and $SET RETIRE 'LP'? Or is there a better way of doing this? 

Pernille
Reply
#18
Ah, yes, using RCAP_BND for activating early retirements works only under VEDA-FE.

If using ANSWER-TIMES, you need to use the switch $SET RETIRE 'LP' and PRC_RCAP(r, p)=1, as you noted.
Reply
#19
(08-05-2019, 02:31 PM)Antti-L Wrote: Ah, yes, using RCAP_BND for activating early retirements works only under VEDA-FE.

If using ANSWER-TIMES, you need to use the switch $SET RETIRE 'LP' and PRC_RCAP(r, p)=1, as you noted.


Thank you very much for the fast reply and support.
Reply
#20
(03-05-2019, 03:55 PM)Antti-L Wrote: The online capacities are not reported, because they are not generally of much interest, and it is not a physical quantity, but just the amount of capacity having that operational status, in each timeslice.

If you find the GDX file, you can calculate the online capacity in each timeslice ts by subtracting VAR_UPS(r,v,t,p,s,'N') from the total capacity, for all s above or equal to ts. VAR_UPS(r,v,t,p,s,'N') thus gives the offline capacity in each timeslice.

Anyway, I just tested your example model with the following small modification. I introduced COM_FR for the demand:

Code:
PARAMETER COM_FR /
REG1.2005.DEMCAR.WD 0.36
REG1.2005.DEMCAR.WN 0.14
REG1.2005.DEMCAR.SD 0.36
REG1.2005.DEMCAR.SN 0.14
/;

As expected, now the TESTELSR process had partial load efficiency losses of 32% in the night timeslices, which now had a lower load level, in accordance with the load profile I defined.  So, it worked exactly as expected.

Please also read the documentation if you have not yet read it: TIMES_Dispatching_Documentation.pdf


Hello Antti. Now I can see there is drop in efficiency for my electrolyser and I hope it's working fine. However, since I am not able to read the GDX file, I can't see the online capacity to verify the values. When I open the GDX file in notepad, it is not a readable script. Do you know why it is so? Is it a VEDA problem? Should I ask in the VEDA forum.
Reply
#21
I doubt that there is anything for you to see. As I have told you, the online capacity is exactly the total capacity (150 in your case), if you don't allow any start-ups / shut downs. Isn't that how you wanted to model the process in the first place? So there should be nothing to verify for you: the online capacity is forced to be the full total capacity throughout the year, when not allowing start-ups / shut downs.

The GDX files are produced by GAMS. There is a GDX viewer in your GAMS installation, which you can use for viewing GDX files and exporting data from them, if you ever happen to need to do that. If you have any problems with GDX files, you can ask for GAMS support in the GAMS Forum. But as I have told you, the online capacities cannot be found in the GDX files either, only the offline capacities, by timeslice.

However, it should be clear that you cannot find the offline capacities in the GDX file if you disable the start-ups / shut downs, because then you have explicitly disabled the capacities from going off-line. Therefore, I am afraid there is probably nothing for you to see or verify.
Reply
#22
(09-05-2019, 03:19 AM)Antti-L Wrote: I doubt that there is anything for you to see. As I have told you, the online capacity is exactly the total capacity (150 in your case), if you don't allow any start-ups / shut downs. Isn't that how you wanted to model the process in the first place? So there should be nothing to verify for you: the online capacity is forced to be the full total capacity throughout the year, when not allowing start-ups / shut downs.

The GDX files are produced by GAMS. There is a GDX viewer in your GAMS installation, which you can use for viewing GDX files and exporting data from them, if you ever happen to need to do that. If you have any problems with GDX files, you can ask for GAMS support in the GAMS Forum. But as I have told you, the online capacities cannot be found in the GDX files either, only the offline capacities, by timeslice.

However, it should be clear that you cannot find the offline capacities in the GDX file if you disable the start-ups / shut downs, because then you have explicitly disabled the capacities from going off-line. Therefore, I am afraid there is probably nothing for you to see or verify.

I have modelled by the first way you suggested, since it makes more sense not to use the whole capacity throughout the year. Thank you very much on GDX.
Reply
#23
I have been developing a small hydrogen technology model. The process follows the pathway: input electricity, electrolyser, electrolyser stack (because of different life time), compressor, hydrogen storage (just an intermediate stop, not modelled as a storage process) and finally the hydrogen cars. This way, the model was working at least meeting the demand and all technologies were working. Then I included a dummy electricity demand process (residential electricity demand). After this, the electricity is only produced to meet the residential electricity demand. However, the hydrogen car demand is also met by the hydrogen from the hydrogen storage. But there is no flow in to the hydrogen storage and other technologies like electrolyser, compressor are also not working. Surprisingly, there is also no dummy import process happening. I don't know from where model is taking hydrogen to meet the demand. I doubt the error has something to do with commodity group. There was a warning message after the run which says about the process hydrogen storage process.
" RPC in TOP not found in any ACTFLO/FLO_SHAR/FLO_FUNC/FLO_SUM
*01 WARNING - R=REG1 P=HYGNSTG C=HYGN IO=OUT
*01 WARNING - R=REG1 P=HYGNSTG C=HYGNfc IO=IN

Any idea why this is happening?
Reply
#24
A bit hard to say without seeing the model, but something is obviously wrong at least with that HYGNSTG process characterization. But it would be easy to say if you can show the model (*.DD, *.RUN).
Reply
#25
(09-05-2019, 08:16 PM)Antti-L Wrote: A bit hard to say without seeing the model, but something is obviously wrong at least with that HYGNSTG process characterization. But it would be easy to say if you can show the model (*.DD, *.RUN).


Thanks for the reply. I have attached the .dd and .run files. Could you please have a look?


Attached Files
.zip   ddnrunfiles.zip (Size: 4.79 KB / Downloads: 1)
Reply
#26
Yes, it was easy to see that you have some strange mess up in your model. You are defining the following process type and primary group for HYGNSTG:

Code:
SET PRC_MAP /
REG1.DMD.HYGNSTG
/;

SET PRC_ACTUNT /
REG1.HYGNSTG.DEM.numberofcarkm
/;

Earlier, you defined the process of type PRE and with the primary group HYGN, which were fine. So, why did you change these definitions, for the worse? The process cannot have DEM as the PG, as it has no DEM commodities in the topology. Can you not revert these bad changes in the ~FI_Process table?

I tested with your original definitions, and got no QA_check warnings, and the HYGNSTG process worked ok.
Reply
#27
(10-05-2019, 02:55 AM)Antti-L Wrote: Yes, it was easy to see that you have some strange mess up in your model. You are defining the following process type and primary group for HYGNSTG:

Code:
SET PRC_MAP /
REG1.DMD.HYGNSTG
/;

SET PRC_ACTUNT /
REG1.HYGNSTG.DEM.numberofcarkm
/;

Earlier, you defined the process of type PRE and with the primary group HYGN, which were fine. So, why did you change these definitions, for the worse? The process cannot have DEM as the PG, as it has no DEM commodities in the topology. Can you not revert these bad changes in the ~FI_Process table?

I tested with your original definitions, and got no QA_check warnings, and the HYGNSTG process worked ok.

Thank you Antti. In fact, what happened was that there was no gap between the  ~FI_Process table and ~FI_T table as seen in the snapshot attached. Although the PCG of HYGNSTG was declared as HYGN earlier, the PCG chosen by the code was DEM. Even if you have noticed, the description of the HYGNSTG process was that of the H2TRACAR because of this mess. So there was some error message appearing related to PCG. This made me change the PCG of all the processes into NRG (except demand technologies which I made to DEM) which is one of the default commodity groups mentioned in the TIMES documentation IV. Then, this time the warning message which I shared in the earlier post appeared (message related HYGNSTG). After you pointed out the PCG problem, I found out the excel sheet problem (of having no gap between tables) and ran the model. However, this only avoided the warning in the quality check, but the problem of not picking electrolyser, compressor technologies were still happening. The problem got solved when I changed the PCG of processes into their respective output commodities.

Now my problem is solved. But I am curious to know why those technologies were not being picked when the PCG of all processes except demand technologies (declared PCG as DEM) were declared as NRG. After I changed the PCG of each process into their respective output commodities (eg. HYGN for HYGNSTG), the model is working fine. Could you tell me why this was happening? I have attached the .run and .DD files of that version for your reference. Just now I tested the model without inputting anything in the commodity group. This was also working fine and it gave me the same results as that of the file where I inputted the PCG as their respective output commodities.

One more question. When should we declare the user defined PCG. I read in the documentation that it should be defined when the input commodity and output commodity of a process are different, it should be declared. In one example in the documentation, it was declared only in the ~FI_Process table. However, I have not seen any example in the documentation where user defined PCG was declared in the 'Commodity Group' tab of the SysSettings file. Could you also tell me when should we declare user defined PCG in this tab and how can we declare a user defined PCG in that tab, if say, I have two commodities in my PCG?

I hope what I explained is clear to you. Thanks in advance.


Attached Files
.zip   snapshot of no gap space between the tables.zip (Size: 62.77 KB / Downloads: 3)
.zip   ddnrunfiles1.zip (Size: 4.8 KB / Downloads: 1)
Reply
#28
(09-05-2019, 02:24 AM)MohammedAbiAfthab Wrote:
(03-05-2019, 03:55 PM)Antti-L Wrote: The online capacities are not reported, because they are not generally of much interest, and it is not a physical quantity, but just the amount of capacity having that operational status, in each timeslice.

If you find the GDX file, you can calculate the online capacity in each timeslice ts by subtracting VAR_UPS(r,v,t,p,s,'N') from the total capacity, for all s above or equal to ts. VAR_UPS(r,v,t,p,s,'N') thus gives the offline capacity in each timeslice.

Anyway, I just tested your example model with the following small modification. I introduced COM_FR for the demand:

Code:
PARAMETER COM_FR /
REG1.2005.DEMCAR.WD 0.36
REG1.2005.DEMCAR.WN 0.14
REG1.2005.DEMCAR.SD 0.36
REG1.2005.DEMCAR.SN 0.14
/;

As expected, now the TESTELSR process had partial load efficiency losses of 32% in the night timeslices, which now had a lower load level, in accordance with the load profile I defined.  So, it worked exactly as expected.

Please also read the documentation if you have not yet read it: TIMES_Dispatching_Documentation.pdf


Hello Antti. Now I can see there is drop in efficiency for my electrolyser and I hope it's working fine. However, since I am not able to read the GDX file, I can't see the online capacity to verify the values. When I open the GDX file in notepad, it is not a readable script. Do you know why it is so? Is it a VEDA problem? Should I ask in the VEDA forum.

Reply
#29
(09-05-2019, 02:24 AM)MohammedAbiAfthab Wrote:
(03-05-2019, 03:55 PM)Antti-L Wrote: The online capacities are not reported, because they are not generally of much interest, and it is not a physical quantity, but just the amount of capacity having that operational status, in each timeslice.

If you find the GDX file, you can calculate the online capacity in each timeslice ts by subtracting VAR_UPS(r,v,t,p,s,'N') from the total capacity, for all s above or equal to ts. VAR_UPS(r,v,t,p,s,'N') thus gives the offline capacity in each timeslice.

Anyway, I just tested your example model with the following small modification. I introduced COM_FR for the demand:

Code:
PARAMETER COM_FR /
REG1.2005.DEMCAR.WD 0.36
REG1.2005.DEMCAR.WN 0.14
REG1.2005.DEMCAR.SD 0.36
REG1.2005.DEMCAR.SN 0.14
/;

As expected, now the TESTELSR process had partial load efficiency losses of 32% in the night timeslices, which now had a lower load level, in accordance with the load profile I defined.  So, it worked exactly as expected.

Please also read the documentation if you have not yet read it: TIMES_Dispatching_Documentation.pdf


Hello Antti. Now I can see there is drop in efficiency for my electrolyser and I hope it's working fine. However, since I am not able to read the GDX file, I can't see the online capacity to verify the values. When I open the GDX file in notepad, it is not a readable script. Do you know why it is so? Is it a VEDA problem? Should I ask in the VEDA forum.

Dear Antii

This is Anjana and we met at last ETSAP meeting. Abi Mohammed is working with me and thank you very much for all your kind help regarding partial load modelling. I am also interested at the solution value of VAR_UPS, just for curiosity about its values. Earlier (15 years ago), .lst file used to report all optimal values of all variables from where .vd, .vde etc used to pick up the optimal solution for reporting. So for my curiosity, I checked the variable values at the .lst file, but now .lst file does not report any results on variable value. Perhaps some programming is done at control panel or run file, could you please kindly let me know where I should change so that I could see all variable optimal values including VAR_UPS  at the .lst file.

Thank you in advance for all your time and kind support

Best regards

Anjana
Reply
#30
Anjana Wrote:Perhaps some programming is done at control panel or run file, could you please kindly let me know where I should change so that I could see all variable optimal values including VAR_UPS  at the .lst file.

Yes, at least I have the SOLPRINT option available in the Control Panel, GAMS options.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)