search

cpmodel / FTT_StandAlone

Future Technology Transformation models
GNU General Public License v3.0
10 stars 1 forks source link

Generic sales and corrections to FTT-P #135

Open Femkemilene opened 4 months ago

Femkemilene commented 4 months ago

Implementing the new MEWI calculations for FTT:P now as well. I've tested that it produces reasonable values for FTT:P. Not tested if it stays the same for FTT:Tr yet.

cormacmlynch commented 4 months ago

Quite a bit of difference between transport TEWI. Generally only a couple of percent difference but in some years this goes over 10%. Power also different MEWI.

Femkemilene commented 4 months ago

What technologies are different for MEWI? The previous version didn't have the new depreciation calculations yet, so for technologies that don't grow at times, a difference is expected.

ldxib2 commented 4 months ago

Most of them are different in value but with similar dynamics. Solar is particularly different though with MEWI rising until 2030 then plateauing in the SA but continuing to rise in Fortran. Slow steady rise in offshore in both but different values, onshore has a sudden drop off in both but a bit later in Fortan

Femkemilene commented 4 months ago

We're still in the mids of aligning SA and FORTRAN, so MEWI plateauing is a reflection of MEWG plateauing, so I'm not too surprised here.

I will get back to TEWI. I've tweaked the code slightly (like a >=, rather than a >), and changing the condition to check "quarterly" additions/removals, rather than yearly. The latter may have changed things. Will have another look later this week.

Femke

From: Ian Burton @.> Sent: 14 May 2024 12:35 To: cpmodel/FTT_StandAlone @.> Cc: Nijsse, Femke @.>; Author @.> Subject: Re: [cpmodel/FTT_StandAlone] Implement new MEWI calculation (PR #135)

CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.

Most of them are different in value but with similar dynamics. Solar is particularly different though with MEWI rising until 2030 then plateauing in the SA but continuing to rise in Fortran. Slow steady rise in offshore in both but different values, onshore has a sudden drop off in both but a bit later in Fortan

— Reply to this email directly, view it on GitHubhttps://github.com/cpmodel/FTT_StandAlone/pull/135#issuecomment-2109973765, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHDIIYZ5J2VAJ4CIDGWVCTZCHZG7AVCNFSM6AAAAABHT7JQMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBZHE3TGNZWGU. You are receiving this because you authored the thread.Message ID: @.***>

rhayward1 commented 4 months ago

It doesn't seem like the MEWI calculation matches the calculation in the FTT Iter R&D.

MEWI was changed to explicitly calculate the proportion of end-of-life replacements depending on whether the change in shares of a technology was positive or negative.

The shares equation is already replacing a subset of breakdowns with new technologies, so MEWI is overestimated in previous model versions.

Happy to discuss this. The FTT Iter implementation can be seen in the latest version of industrial heat.

Femkemilene commented 3 months ago

I'm surprised you say the new Iter R&D hasn't been implemented in this branch. There are now three conditions for investment, different for a growth, moderate decline, and decline larger than eol replacement. Is that different in IH?

That said, I do suspect the code is wrong. It does not seem to be dt-invariant.. (this branch isn't for sure, and I think my implementation is the culprit).

rhayward1 commented 3 months ago

E.o.l. Replacements were based on whether shares in each time step were positive or negative in the Fortran version, but from what I can see investment in this version isn’t in the time loop.

If you take a look at the latest version of industrial heat, you can see a calculation of same-technology e.o.l. replacements based on the shares. It’s quite detailed so if you want to have a quick call about it let me know. I think it was left in the Fortran version and is time-step invariant, and should be more accurate.

Femkemilene commented 3 months ago

After digging down on the time step issue, it seems to stem from a different part of the code (something to do with curtailment, a bit of a mystery).

About the new sales / investment calculation, it's still in the time loop, but now calls this new sales function. I believe the logic is the same as in FTT:heat.

rhayward1 commented 3 months ago

I'm so sorry Femke, this was my mistake. I think the branch hadn't updated for me and was showing an old version of the model, or maybe I was looking in the wrong branch! It all looks fine from what I can see, great that it is a separate function.

I can spend a bit of time here or there if it helps with Ian's project so let me know if there's anything I can do to aid with alignment.

Femkemilene commented 3 months ago

Do you happen to have a list of changes implemented as part of the Iter R&D? It would be good to know if I've got all of them implemented now.

rhayward1 commented 3 months ago

I do not but I did make notes while I worked at CE, they should have a list of what was implemented. @pv-camecon do you still have this?

Femkemilene commented 3 months ago

I'm falling more and more behind on getting the cascading tipping point work done, and I'm stuck. I find the new ITER Fortran code very difficult to work with; it's very "WET" code. I wonder if it would be good to review the changes as is, and for others to continue finding bugs in the code base. There is still a 44% deviation in wind generation and a 14% deviation in total 2050 solar generation. @pv-camecon and @ldxib2, let me know what you think.

ldxib2 commented 3 months ago

Happy to try and work with code as is and make bug fixes as we go. Will hopefully pick up a few more during QA

pv-camecon commented 3 months ago

I'm falling more and more behind on getting the cascading tipping point work done, and I'm stuck. I find the new ITER Fortran code very difficult to work with; it's very "WET" code. I wonder if it would be good to review the changes as is, and for others to continue finding bugs in the code base. There is still a 44% deviation in wind generation and a 14% deviation in total 2050 solar generation. @pv-camecon and @ldxib2, let me know what you think.

I've been reviewing PR #113 and #135. It's becoming more evident that we've now got a fundamental divergence in the FORTRAN and Python models.

pv-camecon commented 3 months ago

To add, there is a decision to be made:

  1. If we want to maintain intercomparitability between the models, then we will need to mimic everything. So, in this case it means we would need to read in the expected electricity demand and calculate the market share dynamics, followed by feeding in the actual electricity demand for the accounting.
  2. We change the way we QA things and allow for divergence. This means we need to unify functionality (needs to happen regardless) and need to develop unit testing for both models.

Option 1 quickly becomes messy as is evident from our current experiences. Option 2 seems more reasonable, depending on well defined unit testing, which is more difficult to do in FORTRAN. Effectively, we need to check that the unit tests remain the same across models.

rhayward1 commented 3 months ago

Making the FORTRAN code "drier" would be great, and I think it's been on the todo list for a long time. However, the fundamental difference in how demand is treated will absolutely be the largest driver of divergence between the two versions, as Pim says.

One test could be to extract the demand from the first iteration in FORTRAN and see if the same market shares are then found in python, although there are probably other complications present.

Femkemilene commented 3 months ago

Done that, and there are still discrepancies. I thought I had the historical period perfectly aligned, but there seem to be some small differences there, which @ldxib2 may want to resolve (these are easier to resolve than those in the simulation period). In particular, MEWW in FORTRAN is starting counting a year earlier.

For the new demand, would it make sense to do the entire calculation with the new demand estimation and then only rescale MEWG and MEWK to true MEWD at the end of the year?

The way I see the "function" of the two models. The Python model is more suitable for developing new elements and to do uncertainty estimation, whereas the FORTRAN version works for economic estimations. If we want to use both model versions in a single paper / single project, they do need to align.

Femkemilene commented 2 months ago

I noticed I hadn't removed the temporary exogenous METC. This means the models diverge more again (20M GWh of solar vs 39M GWh). There are two options:

Of course, it would be fantastic if we can find another couple of bugs and get the models closer again. I won't have time for this till around October, meaning my preference is for the first option.