Add CSP modelling capabilities. #194
Conversation
Codecov Report
@@ Coverage Diff @@
## master #194 +/- ##
==========================================
- Coverage 73.98% 72.13% -1.85%
==========================================
Files 18 19 +1
Lines 1522 1579 +57
Branches 212 222 +10
==========================================
+ Hits 1126 1139 +13
- Misses 330 374 +44
Partials 66 66
Continue to review full report at Codecov.
|
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
|
@FabianHofmann could you have a look? With a focus on the code. |
There was a problem hiding this comment.
This is really impressive work! The example is excellent and explains well.
Just a few conceptional questions:
- I am wondering why the efficiency map is not defined for a azimuth range from 0 to 360. The ranges 0-70 (roughly) and 270 - 360 are missing. Does that mean a solar position in the north is not covered/supported?
- I am wondering whether the underestimated efficiencies for low solar altitudes play a role. These have a strong relative deviation from the SAM data. For example: For SAM the combination of altitude=8, azimuth=280 leads to en efficiency of ~10%. The same combination on the derived efficiency map gives efficiency ~0%. Do you see any harmful potential there?
- The underestimated efficiencies for low solar altitudes stand in contrast to the overestimated power outputs in winter. In the example the solar altitude during the winter months are between 0 and 20, so exactly the range where the efficiency is underestimated. But still we get a higher power output than the reference model. That seems a bit odd... Any idea?
examples/working-with-csp.ipynb
Outdated
| "The installation details for 'SAM_parabolic_trough' and 'SAM_solar_tower' were retrieved and modelled with NREL's System Advisor Model.\n", | ||
| "For details on the process see [the section below](#extracting-efficiencies-from-sam).\n", | ||
| "\n", | ||
| "The 'lossless_installation' is an universal installation which has be default perfect efficiency and is thus able to convert the direct irradiation of either technology into an heat output.\n", |
There was a problem hiding this comment.
| "The 'lossless_installation' is an universal installation which has be default perfect efficiency and is thus able to convert the direct irradiation of either technology into an heat output.\n", | |
| "The 'lossless_installation' is an universal installation which has per default perfect efficiency and is thus able to convert the direct irradiation of either technology into an heat output.\n", |
|
Code-wise I have nothing to complain about :) Everything is super readable and well-structured |
|
Hi Johannes, amazing contribution! 🥇 A little comment on the notebook: |
|
Thank you both of you for your feedback!
Oops. You're absolutely right. Chile, South Africa, Australia, ... would all have suffered from this mistake. I corrected it now by mirroring the efficiency in the interval [90°,270°] to [90°,-90°=270°] with the mirror plane being 90°. Documentation is also updated. Thanks!
I don't think so, at least not in this example. A low solar altitude also coincides with a low direct solar irradiation. An solar altitude of e.g. 8° rarely happens when there is significant irradiation. Here's two figures showcasing this:
I agree that this is an effect which contributes a little bit. It is also something a user can improve for themselve by using a better efficiency map / CSP installation config as input. Lastly I think it is something that - as long as we are using hourly resolved data sets - we will always struggle with: The comparison of the output of a single plant at high temporal resolution is the edge case to which
I presume this is an issue with the lack of atmospheric attenuation (For now we're using clearsky conditions). This should lead to problems especially during the winter season in Spain. Inspecting the system in SAM yields the following picture for January:
In the top picture you see on the left y-axis in blue the output of the solar field to HTF (heat transfer fluid) in MW_th. In orange on the right the wind speed at that time. High wind speeds and low generation correlate (during daytime). Let's see what Max's expert say about this. :) |
|
Hi Johannes,
Maybe worth adding at the bottom of the script some future work people can catch up on? > For now we're using clearsky conditions. There are ways to correct for the attenuation (based on humidity, altitude, dust). Maybe something for future work? BR, Max
…________________________________
From: euronion ***@***.***>
Sent: 25 November 2021 09:15
To: PyPSA/atlite ***@***.***>
Cc: PARZEN Maximilian ***@***.***>; Mention ***@***.***>
Subject: Re: [PyPSA/atlite] Add CSP modelling capabilities. (PR #194)
This email was sent to you by someone outside the University.
You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
Thank you both of you for your feedback!
@FabianHofmann<https://github.com/FabianHofmann>
1. I am wondering why the efficiency map is not defined for a azimuth range from 0 to 360. The ranges 0-70 (roughly) and 270 - 360 are missing. Does that mean a solar position in the north is not covered/supported?
Oops. You're absolutely right. Chile, South Africa, Australia, ... would all have suffered from this mistake. I corrected it now by mirroring the efficiency in the interval [90°,270°] to [90°,-90°=270°] with the mirror plane being 90°. Documentation is also updated. Thanks!
2. I am wondering whether the underestimated efficiencies for low solar altitudes play a role. These have a strong relative deviation from the SAM data. For example: For SAM the combination of altitude=8, azimuth=280 leads to en efficiency of ~10%. The same combination on the derived efficiency map gives efficiency ~0%. Do you see any harmful potential there?
I don't think so, at least not in this example. A low solar altitude also coincides with a low direct solar irradiation. An solar altitude of e.g. 8° rarely happens when there is significant irradiation. Here's two figures showcasing this:
* In the top picture time vs. efficiency for the PS10 location in Spain during winter solistice. There are 4 points per day with significantly lower efficiency during sun rise and sun set.
* In the lower picture the DHI for the same location and time. Notice that for only 3 of the 4 time points with low efficiency the DHI is != 0. Simulatenously for those 3 points the irradiation is already low and the contribution to the daily output less significant anyway.
[image]<https://user-images.githubusercontent.com/42553970/143406969-6fbc2e1f-6a0c-4517-ae80-43e04d0cc190.png>
I agree that this is an effect which contributes a little bit. It is also something a user can improve for themselve by using a better efficiency map / CSP installation config as input. Lastly I think it is something that - as long as we are using hourly resolved data sets - we will always struggle with: The comparison of the output of a single plant at high temporal resolution is the edge case to which atlite can / should not be applied IMHO.
3. The underestimated efficiencies for low solar altitudes stand in contrast to the overestimated power outputs in winter. In the example the solar altitude during the winter months are between 0 and 20, so exactly the range where the efficiency is underestimated. But still we get a higher power output than the reference model. That seems a bit odd... Any idea?
I presume this is an issue with the lack of atmospheric attenuation (For now we're using clearsky conditions). This should lead to problems especially during the winter season in Spain. Inspecting the system in SAM yields the following picture for January:
[image]<https://user-images.githubusercontent.com/42553970/143412994-92e629bb-8133-4675-9249-7b8483cc7491.png>
In the top picture you see on the left y-axis in blue the output of the solar field to HTF (heat transfer fluid) in MW_th. In orange on the right the wind speed at that time. High wind speeds and low generation correlate (during daytime).
In the bottom picture for the same time range incident DNI (left axis, red) vs. relative humidity (black, right axis) on the solar field. Notice how they also negatively correlate.
Let's see what Max's expert say about this. :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#194 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOYZENPK4VJZKFACE2FPVH3UNX5E7ANCNFSM5IFG4J3Q>.
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
|
|
@pz-max : will do. I'll add a note to the notebook and create+link an issue in the GH repository with "help wanted".
edit: I'm not going to do this as the quality is now significantly better (correct data for SAM used). |
|
I did a quick review on alternative datasets which might yield better results, especially for CSP data which relies on direct irradiation data on the surface, which in turn is influenced by the aerosol and cloud data used in each dataset. NREL's SAM uses the NSRDB which tries to be better in that regard than e.g. SARAH, which only uses a constant annual aerosol specification. But more importantly: With the data for the correct location the deviations are much smaller and IMHO qualitatively totally acceptable, e.g.:
If the checks all pass I'd say we're ready to merge. |
|
Really nice :) |
Closes # (if applicable).
Change proposed in this Pull Request
Description
Motivation and Context
How Has This Been Tested?
Type of change
Checklist
pytestinside the repository and no unexpected problems came up.doc/.environment.yamlfile.doc/release_notes.rst.pre-commit run --allto lint/format/check my contribution