Some suggestions for model refinement

[nhlong2701]

Hi @philouhawi,

Yuchi shared with me the repo. First of all, congrats on the work!

I have compiled below a list of enhancements, which can help model better the true cost of LCOX:

• The wind and solar patterns are slightly over-simplified by using same daily pattern for the whole year. You may want to switch to using hourly pattern instead. You can download this information from renewable.ninjas for wind and pvgis (https://re.jrc.ec.europa.eu/pvg_tools/en/#api_5.2) for solar (From my experience, pvgis provide more close-to-reality irradiation for solar).
• Is there a reason why you use overwrite=True in every .add operation? I would suggest removing them.
• You assumed the lifetime of WTON to be 20 years, which is even lower than solar PV. In my opinion, the technical lifetime of wind turbine should be at least equal to solar PV of 25 or even higher. In other modelling studies, we used 30 years for wind turbine lifetime.
• The fix cost is calculated as % of investment (not annualised capex). Therefore, FOM/100 * annualized_capex should be corrected to FOM/100 *Capex.
• Is there a reason why you use e_cyclic=False for your store component? I would suggest having all stores to be cyclic to avoid dumping energy.
• If I remember correctly, the Haber-Bosch process takes nitrogen and hydrogen as input to produce Amonia. In that case, the Haber-Bosch link you created should have Hydrogen as bus0 (for input) and Ammonia as bus1 (output) and Electricity as bus2 with negative efficiency (side input). Please refer to this small example how we model Direct air capture in our model, which consists of multiple input-single output set up (https://sefep.sharepoint.com/:u:/s/IEDM-06_Modelling/EYrvvzf0TABFps72TPejcogBkuFBYRaCCK7Eb6txuCWOGw?e=ZKGCLV). If you look at the current diagram, it looks like your Haber-Bosch link is taking in electricity to produce hydrogen and ammonia at the same time.

[RichChang963]

Hi @philouhawi ,

Thanks Long for the comments and time for review it! I have some extra comments based on Long's points, and I can explain you further about the implementation.

1. In terms of the overwrite=True, I guess that you added because you edited the networks on the notebooks directly, so in this way you can avoid reloading the network from the beginnning again. Yet once all the adjustment of network elements is done (or if you work on .py file directly), then we can remove this attribute.
2. In the Haber-Bosch component, I saw that you made efficiency2 negatvie if your script already, so only the sequence of the buses needs to be adjusted as Long's comment. The input of efficiency also needs to be adjusted since now the bus0 will be H2 and bus1 will be ammonia/methanol (I provide an example as follows), and / electricity_input_hb in capital_cost and marginal_cost can be removed due to the same bus reason.

    efficiency1=(1/ hydrogen_input),
    efficiency2=-(1 / electricity_input_hb),
    capital_cost=(annualized_capex + FOM/100 * CAPEX),
    marginal_cost=VOM,

3. Regarding the CAPEX of H2 storage (in this case it will be aboveground compression tank if I understood correctly), the CAPEX in the ntoebook is the 59,700 USD/MWh (=59.7*1000) while CAPEX from boa is 59.07 but unit in USD/kW_h2 (At the moment I am checking this with H2 team). I crossed check with the Excel sheet input, and you noted a value of 550USD/kgH2), which will be around 16,500 USD/MWh (=550/33.33/1000 assuming 1 kgH2 = 33.33 kWh ). I think taht 16,500 USD/MWh is more reasonable as per the analysis chart we had from Hydrogen storage cost range in EU H2 map. This chart is based on the data collection and is independent from the opt modelling outputs.
4. Regarding the electrolyzers, in EU H2 map, even though the life time is 20 years, we added a stack replacement cost of every 10 years (cost_assumption). This cost also will be annualized before adding into the components. In case you are interested in including this, we can further implement it.
5. Is there a reason for having a battery with energy-to-power ratio at 2hrs? Since the HB process also consumes quite some amount of electricity, I think that the battery can help reduce the curtailment. In this way, the size of battery will affect the results as I imagine.
6. I saw that the interest rate is around 5%. Just want to double check since 5% is a bit low as compared to our assumptions in EU H2 production cost map, where 5% falls in the average in central Europe countries. You can refer to the last chart of this story. This chart is based on the data collection and is independent from the opt modelling outputs.

Thanks and look forward for the further discussion!

Best,
Yu-Chi

[RichChang963]

by the way, I tried to have a run with Gurobi solver after covering a bit of the aboved major adjustments, and it takes around 20-30sec to calculate. Hence, I feel that it will take very long time to calculate with cbc solver. But we can discuss about this point further and also I can help on executing the output based on the updated assumptions.

[philouhawi]

Dear Long, dear Yu-Chi,

thank you so much for all the feedback which I find very useful. I am in the midst of going through the code and correcting what you suggest, and will get back to you once done.

[philouhawi]

Regarding your comments and questions, @nhlong2701:

1. I am using yearly load profile (01-01-2019-01-01-2020) derived from renewables.ninja, but maybe the code is incorrect? Thank you for pointing to pv.gis – I will check and see how they differ from the renewables.ninja data (I adjusted the tilt according to the global solar atlas suggestions for each location).
2. Yes, I am using the overwrite to be able to change the code without having to include a remove loop somewhere. I can definitely take this out, once the whole code is correct. My coding is still prone to many mistakes, so playing with the remove. command started to annoy me.
3. With regards to the lifetime of wind, you are fully correct that usually it is higher. I am using this value as it comes from those found by my colleague Wei in assumptions for China. I briefly double-checked, and it is indeed commonly reported as 20 years.
4. I have changed the FOM code to CAPEX, instead of annualized_capex, thank you for pointing this out!
5. I put e_cyclic=False because in my initial code it created a loop where the storage already held some methanol or ammonia in it at t=0, which I didn't want. but maybe if I put e_initial=0, then this loop is interrupted? I will have a look and see. Maybe you could tell me if this loop is an issue? On a second thought, I would assume that if this system runs for 20 years, obviously there will be a seasonal loop with storage levels on 31/12/2019 to be available on 01/01/2020.
6. This is really valuable, as I was most unsure on the link components! At this moment, nitrogen (and CO2 for methanol) are included in the VOM, as I wasn't sure how to do this otherwise. As I don't have access to the SEFEP, would it be possible to send this document to my email please? With regards to the directional flows, I have changed the buses and the code for the efficiency values accordingly, thanks so much, also to @RichChang963!

To now come to your comments, Yu-Chi,

1. Correct, I am using overwrite for the reason you mentioned. So far I have only worked in ipynb files, but will look up how I can work in .py directly.
2. I have integrated this together with the issues that Long has raised! Thanks for telling me about the precise implications for the efficiency conversions.
3. I was trying for a while to find the conversion from the USD/kW_h2 value to USD/kWh value for storage, thank you!! I didn't trust the 550kg/H2 number before, I will use 20000/MWh now as a value as it is the average of the range from your table.
4. Yes I would like to include the stack replacement assumption. Could you perhaps share the code with me, please?
5. Maybe I don't understand the energy-to-power ratio correctly; my intention was to use a 2h battery storage i.e. (50MW / 100MWh) to precisely decrease the curtailment rate (if cost effective). This 2h battery storage is somewhat the common battery for utility scale projects in China. Is there a better way to do it?
6. I am also not quite sure right now where we took this value from, but I believe it comes from a PtXboa sheet that had an overview of various WACCs of the countries included? I will search for it now, and get back to you.

[nhlong2701]

Regarding your comments and questions, @nhlong2701:

1. I am using yearly load profile (01-01-2019-01-01-2020) derived from renewables.ninja, but maybe the code is incorrect? Thank you for pointing to pv.gis – I will check and see how they differ from the renewables.ninja data (I adjusted the tilt according to the global solar atlas suggestions for each location).
2. Yes, I am using the overwrite to be able to change the code without having to include a remove loop somewhere. I can definitely take this out, once the whole code is correct. My coding is still prone to many mistakes, so playing with the remove. command started to annoy me.
3. With regards to the lifetime of wind, you are fully correct that usually it is higher. I am using this value as it comes from those found by my colleague Wei in assumptions for China. I briefly double-checked, and it is indeed commonly reported as 20 years.
4. I have changed the FOM code to CAPEX, instead of annualized_capex, thank you for pointing this out!
5. I put e_cyclic=False because in my initial code it created a loop where the storage already held some methanol or ammonia in it at t=0, which I didn't want. but maybe if I put e_initial=0, then this loop is interrupted? I will have a look and see. Maybe you could tell me if this loop is an issue? On a second thought, I would assume that if this system runs for 20 years, obviously there will be a seasonal loop with storage levels on 31/12/2019 to be available on 01/01/2020.
6. This is really valuable, as I was most unsure on the link components! At this moment, nitrogen (and CO2 for methanol) are included in the VOM, as I wasn't sure how to do this otherwise. As I don't have access to the SEFEP, would it be possible to send this document to my email please? With regards to the directional flows, I have changed the buses and the code for the efficiency values accordingly, thanks so much, also to @RichChang963!

To now come to your comments, Yu-Chi,

1. Correct, I am using overwrite for the reason you mentioned. So far I have only worked in ipynb files, but will look up how I can work in .py directly.
2. I have integrated this together with the issues that Long has raised! Thanks for telling me about the precise implications for the efficiency conversions.
3. I was trying for a while to find the conversion from the USD/kW_h2 value to USD/kWh value for storage, thank you!! I didn't trust the 550kg/H2 number before, I will use 20000/MWh now as a value as it is the average of the range from your table.
4. Yes I would like to include the stack replacement assumption. Could you perhaps share the code with me, please?
5. Maybe I don't understand the energy-to-power ratio correctly; my intention was to use a 2h battery storage i.e. (50MW / 100MWh) to precisely decrease the curtailment rate (if cost effective). This 2h battery storage is somewhat the common battery for utility scale projects in China. Is there a better way to do it?
6. I am also not quite sure right now where we took this value from, but I believe it comes from a PtXboa sheet that had an overview of various WACCs of the countries included? I will search for it now, and get back to you.

Hi Philips,

Thanks for your quick reply.

1. I was confused by the comment saying it is daily pattern. It's good now that you're using hourly pattern for the whole year.
2. PyPSA optimisation is greenfield so If you put e_initial=0, the previous filling is not considered. If you're running multiple year loop (assuming myopic approach), you have to export the last state of charge from previous solved network and add that as "e_initial" into the store of new brownfield network. But that's quite complicated. It would suggest sticking to cyclic storage for your exercise.
3. I will send the example to your email.

[RichChang963]

To now come to your comments, Yu-Chi,

1. Correct, I am using overwrite for the reason you mentioned. So far I have only worked in ipynb files, but will look up how I can work in .py directly.
2. I have integrated this together with the issues that Long has raised! Thanks for telling me about the precise implications for the efficiency conversions.
3. I was trying for a while to find the conversion from the USD/kW_h2 value to USD/kWh value for storage, thank you!! I didn't trust the 550kg/H2 number before, I will use 20000/MWh now as a value as it is the average of the range from your table.
4. Yes I would like to include the stack replacement assumption. Could you perhaps share the code with me, please?
5. Maybe I don't understand the energy-to-power ratio correctly; my intention was to use a 2h battery storage i.e. (50MW / 100MWh) to precisely decrease the curtailment rate (if cost effective). This 2h battery storage is somewhat the common battery for utility scale projects in China. Is there a better way to do it?
6. I am also not quite sure right now where we took this value from, but I believe it comes from a PtXboa sheet that had an overview of various WACCs of the countries included? I will search for it now, and get back to you.

Hi Philip,

Thanks for the update!
3. Sure I think that 20,000 USD/MWh is also within the range (but you can cross-check with H2 team again just to ensure). Usually we use 1 kgH2 = 33.33 kWh with the case of LHV, and 1 kgH2 = 39.39 kWh for HHV for the conversion. In EU H2 map, LHV is the only source that we consider.
4. Sure I can discuss with you about the details later in the call. But as a nutshell, similar to the normal CAPEX, you will need the annualised stack replacement CAPEX (e.g. 31% of original electrolyzer's CAPEX with replacement of 10 years (life time) according to the cost_assumption), and add it into the capital_cost attribute.
5. I think that if 2hr battery is the common size for projects in China, then it's good to keep it. Since the system solely depends on the RES generation (off-grid), it might happen the situation similar to dunkelflaute in Germany. In this case, the storage can help balance the demand and reduce the curtailment, yet might increase the cost due to the installment and operation of the battery.
6. I just got information from H2 team and 5% is the value as in Ptxboa. So I agree with you that we can keep it.

[philouhawi]

Hi Yu-Chi,

thank you for double checking with H2 team and for the further feedback, and yes lets talk about the stack replacement later if that's ok.

For the Haber Bosch plant, I have encountered an issue when switching bus0 and bus2, and when changing the efficiency values. The LCOA jumps from about 560 to about 3300. Do you have an idea what the issue could be? I noticed that the capacity of every component increases drastically, except for the ammonia flow link. After the changes to the efficiencies, the haber_bosch capacity and the hydrogen flow capacity are the same. I feel like the amount of electricity needed to produce one unit of ammonia has significantly increased.

Best,
Philip

[philouhawi]

I have now shared the results to this cloud: https://cloud.sefep.eu/s/rmX6sXGcJMW2BfK/download

The sheet JiLi_BC_GW from the xlsx (new data) and the the Kopie.xlsx (old data) has the output

[RichChang963]

Hi Philip,

Sorry it's my mistake, the negative sign is in the flow level, but the input output still follows the sequence of the buses. So it should be like:

 efficiency1=(1/ hydrogen_input),  # NH3/H2
 efficiency2=-(electricity_input_hb), # Electricity/NH3

[RichChang963]

hi @philouhawi ,

Well as I discussed with Long, there's one more adjustment that needs to be corrected in the efficiency2. The -(electricity_input_hb), # Electricity/NH3 actually does not conside the H2 consumption. Hence, we actually just need to consider input (H2) and output (NH3, Electricity) regardless of the flows. The update will be like:

 efficiency1=(1/ hydrogen_input),  # NH3/H2
 efficiency2=-(electricity_input_hb/hydrogen_input), # Electricity/H2

Same applies for Methanol process. It's a minor changes on the efficiency which will reduce the electricity consumption in the process.

[philouhawi]

Dear both,

I see! Ok I have made these changes as well now, thank you!

Also just FYI, I managed to switch it to VS Code so I'm coding there now (without overwrite, path, etc). Thank you for the hint.

[nhlong2701]

@philouhawi just to clarify, pypsa link by default only haas single input (from bus0) and single output (to bus1). Any additional buses (bus2+) are considered additional outputs with relation to the first output. By putting negative efficiency2, we are using a trick to model negative output (input) from electricity bus. However, the efficiency2 should still consider how much hydrogen is consumed. Therefore, the following unit should be applied for efficiency2:

-1 (output to input) * NH3/H2 (main conversion efficiency) * Electricity/NH3 (electricity consumed during the conversion)

This logic is applied in general wherever we model multiple input-ouput in PyPSA with Links.

[philouhawi]

Thanks for the further explanation! It's good to know that, Darlene also told me to do this before she went on holiday, but I couldn't explain myself where it came from.

Have a nice weekend!

[philouhawi]

Hey all,

I just tried to include a carbon management system, and realised that we have a data constraint here that makes the use of a DAC a bit difficult.

We are assuming that the carbon is captured from an emitter (i.e. the gas plant, but external to the system). The only data that we have is: 1t of this carbon source costs RMB 250 / tCO2

If we now assume a DAC system, the electricity of it would be another cost component that I would assume is already included in the price of RMB 250 / tCO2.

Because of this I am wondering the following:
would it make sense to include a "CO2-generator" that has the marginal cost of RMB 250 / tCO2 and otherwise no system cost? This CO2 generator we then link to a "co2 stored" bus, to which we attach a "co2 store" with e_nom_max=np.inf as well as the "methanol_synthesis" link?

I have included this in the code now, could you perhaps have a look if this makes sense, please?

Best,
Philip

[RichChang963]

Hi @philouhawi ,

Thanks for the implementation and I had a look after our short chat, and I have some comments here:

1. Since the CO2 is fed into methanol synthesis, you can just keep the CO2 generator in the bus (similar to the wind/solar structure) and remove store and atmosphere bus as shown in red-highlighted sections below. The fewer the components are presented in the network (no matter it's used or not), the shorter the calculation time and space it will take. At the moment as I ran one location, it will take over 1mins with Gurobi license.

Another way to implement it, if you want to make it a bit simplified, you can add it into the marginal cost of the methanol link. It's actually the same part that you commented out in the screenshot below.

2. A short questionon the blue-highlighted section in the first picture in point 1. Do you have a constraint in you project on the total CO2 emissions?

3. I tried to run the model with InMo_CF and turbine with GW without CO2 emission constraint, and here's output for your reference:

• LCOM: 657 USD/t
• LCOA: 581 USD/t

We can talk about the implementation tomorrow, and I can help run the model with Gurobi license if you need supports on it. Also we can try to implement some frequent used scripts into functions so that you can use for loop to run the whole locations at once.