Reference or incorporate PyRTM

[robwandrews]

PyRTM contains functional python wrappers for SMARTS and SBdart, and is capable of modelling spectra in clear-sky and cloudy conditions. This would be a great set of functionality to incorporate into PVLIB. It could be a good project to either integrate the whole code base into the pvlib project (I was involved in the PyRTM project, and I think this would be great). Or, it might we worthwhile to pull in a set of functions to reference it in PVLIB, as PyRTM is already up on pip.

@uniphil any thoughts?

[wholmgren]

Looks interesting. Some thoughts on PyRTM and the broader topic:

I would like to understand some of the pluses and minuses of the many models on https://en.wikipedia.org/wiki/Atmospheric_radiative_transfer_codes for our application. Can anybody point me to some good literature? @Calama-Consulting's referenced paper says that SBDART is simple. @NelisW uses MODTRAN, which does not appear to be open source. RRTMG is now fairly standard in my field, though I don't personally have experience with it. SMARTS seems popular.

On the one hand, we can just wrap a bunch of crap and call it a day. On the other hand, we have an opportunity to help lead the PV community, or at least set some good examples and make some good default choices for people like me that don't already know the literature.

Many of these tools are very general-purposed, and we should keep our focus on the application of these tools to PV. So, I think wrappers are generally the way to go, but I also don't want to introduce dependencies to projects that are no longer maintained. We also need to consider ease of installation. For example, PyRTM itself may be trivial to install, but what about its dependencies? Can we use conda to bundle the whole thing?

Might be wrong about this, but I think that since PyRTM is GNU-licensed you'd have to get permission from all contributors to pull any part of it into pvlib-python.

[robwandrews]

Here is the selection process that we went through, as I remember it. I'll say up front that this wasn't an exhaustive search, but there was some rationale behind it:

• SMARTS widely used in the solar industry, and well validated. Downside is that it does not model clouds
• MODTRAN very heavily validated, but not open source. This is the tool against which all other tools are measured. The libraries that @NelisW uses looks like they do a great job of reading in the outputs of MODTRANS, but it isn't likely to get integrated fully into a workflow
• SBDART this tool has the added advantage of being able to model various forms of clouds, and is validated against MODTRAN http://www.arm.gov/publications/tech_reports/handbooks/rss/publications/ASES2006_Gueymard.pdf
• RRTM we evaluated this, it seemed to be a very versatile model, however it seemed like it might be too skewed towards atmospheric science and so might be a bit bulky/hard to use. That being said, that's not something that a nice clean wrapper can't fix.

The license for SBDART is a bit ambiguous, the code is available at a few locations online, but I'm not sure what the actual license is for the code. The choice of SMARTS and SBDART was made because they seemed to be a good balance between utility, size, accuracy and liscencing.

As for the liscence of PYRTM, the creators are myself and @uniphil, and I believe we would be open to modifying the terms to whatever makes the code most useful.

[NelisW]

I agree with @Calama-Consulting on Modtran. It is somewhat expensive, hard to use, HUGE, and the licence prohibits secondary distribution in any form. My idea would be to do what SMARTS already seems to do: package reference atmospheres (which I could pre-calculate using Modtran). But since SMARTS already do this, there is little point in doing this. It would make much more sense to integrate SBDART, SMARTS or PYRTM with pvlib. At this point I know too little about any of these tools talk any sense (clearly @Calama-Consulting knows a lot more). Give me a while to digest and then I will come back to you.

[wholmgren]

I stumbled across this PyRRTM package but I haven't looked at it closely: https://github.com/tomflannaghan/pyrrtm

[wholmgren]

This Gueymard and Ruiz-Arias article and this Gueymard article might be of interest to people that come across this issue or #101.

[mikofski]

@wholmgren, it's actually this one from Queens-Applied-Sustainability PyRTM and this wiki. Requires Chris Gueyrmard's SMARTS model which is easy to compile. I used gfortran from msys-2 on windows, so I'm sure you can do it in linux or mac as well.

RRTM from Atmospheric & Environmental Research (AER)
Radiative Transfer Working Group is rapid radiative xfer model, but not a spectral model, probably broadband, used in forecasting models? Not sure, shoulkd shoot @tomflannaghan a message.

Watch out lots of irrelevant pyrtms (remember the milk) on the cheeseboard.

[mikofski]

LibRadtran is another RTM that is an all weather (clouds) model. @aoumbe was involved so maybe he can say more about. it.

[mikofski]

Also Gueymard has a new broadband all weather model called REST2.

[mikofski]

As far as references go, Josh Stein PVPMC site at Sandia has a section on irradiance modeling and NREL RREDC has the BIRD clear sky model, SPECTRL2 and the DISC all weather RTM model on which Perez's DIRINT and DIRINDEX models are based.

[tomflannaghan]

RRTM is used widely in forecasting/climate models. It's a correlated-k model (see this paper for example), which is calibrated using a line-by-line model that has been validated with observations. As far as I'm aware it is very accurate. I used the model for some fairly theoretical work with no clouds or aerosols, but the model does support these and is very comprehensive.

The python wrapper I wrote (which is pyrrtm as mentioned above) might be a useful starting point for someone who wanted to call the model from python. However, I did write it with my more theoretical use in mind so doesn't currently support clouds or aerosols. Adding these would probably be quite straightforward.