pvlib v0.9 release planning

[cwhanse]

We've got a lot of new capability pending, and should move to formalize a release. @wholmgren @mikofski @kevinsa5 @wfvining I am willing to manage v0.9 release. Here's the checklists. Please indicate what is needed to close a PR, or if you are willing to close any of the identified issues, or recommend deferring.

PRs to merge or defer:

• Fix to WVM methodology to track changes in MATLAB version. #1213 merged
• Add Array.get_cell_temperature, PVSystem.get_cell_temperature #1211
• Deprecate/raise error for PVSystem "pass-through" properties #1196
• Update irradiance.aoi to use more reliable formula #1191
• ENH: infinite sheds #717 @mikofski I'm guessing the infinite sheds PR will be deferred?

Issues to close or defer:

• change eta_m to module_efficiency #1188 will close with Rename eta_m and eta_m_ref to module_efficiency #1218
• irradiance.aoi can return NaN when module orientation is perfectly aligned with solar position #1185
• ModelChain.pvwatts_losses creates self.losses instead of ModelChainResult.losses #1184 PR mc.losses to mc.results.losses #1231
• It should be impossible to instantiate a PVSystem with no Arrays #1148 PR Raise ValueError if PVSystem constructed with 0 Arrays #1224
• Improve documentation of ModelChainResult class #1126 PR Docstring for ModelChainResult #1233
• Remove shadowed/unused kwargs from PVSystem methods #1118 PR removed kwargs in calcparams_desoto, calcparams_cec, and sapm #1222
• Update modelchain.rst #1115 PR Revise modelchain.rst for multiple arrays, results attribute #1223
• Remove default air temperature and wind speed from ModelChain.run_model etc. #1113
• make Array play nicely with fixed tilt systems and trackers #1109
• Applied PVsyst-type losses in ModelChain #1069
• move pvsystem.retrieve_sam to iotools #964 suggest deferring
• Inconsistent parameter name in fit_sdm_cec_sam()? #958 suggest deferring
• irradiance.detect_clearsky: possibly redundant input 'times' #954 deferred
• Improve docstring or behavior for irradiance.get_total_irradiance and irradiance.get_sky_diffuse #949 PR Better handling of missing inputs in get_total_irradiance, get_sky_diffuse #1225
• Consistent names for reference kwargs #825 recommend deferring
• Add a public constants module and include scipy as base requirement for pvlib #483 recommend deferring
• Breaking out parts of pvsystem.py? #436 maybe this can be closed, we've accomplished a substantial part of the scope
• ENH: allow user to specify the scaling of singlediode ivcurve-pnts or a specify an array, series, or sequence #418 recommend deferring
• define/improve documentation structure #329 perennial can to be kicked down the development road

[wholmgren]

I'd say #1176 is the key remaining PR, which depends on several of the other PRs. @kanderso-nrel is behind most of those and appeared to be slowed down because he didn't get timely feedback from the rest of us (sorry Kevin!). I'm fine deferring anything that's not related to the object layer refactor.

[kandersolar]

I'd say #1176 is the key remaining PR, which depends on several of the other PRs. @kanderso-nrel is behind most of those and appeared to be slowed down because he didn't get timely feedback from the rest of us (sorry Kevin!). I'm fine deferring anything that's not related to the object layer refactor.

Slowed down by my having to prioritize non-pvlib work lately as well. #1211 is waiting for me to pick it up again, but #1196 is ready for others to take a closer look. I need to remind myself of the details but I think #1176 will be close to ready once the other two are merged, that is unless I continue expanding its scope...

Other than that trio, I think I'd like to see modelchain.rst use ModelChain.results so that it doesn't encourage users to use deprecated functionality (see the current "latest" build log, ctfl-f "Use ModelChain.results"). This is one of the bullet points in #1115.

[wfvining]

#1118 Should be taken care of to remove technical debt now that the Array class has been merged. I recall this being a bit more complex than it seemed, just because of the mocks in the tests.

#1148 Should be easy to address, and along with #1184 and @kanderso-nrel's PRs I think it ties up most of the loose ends with the multi-array PVSystem and new ModelChainResults. I'll see if I can find some time for these.

Other than that trio, I think I'd like to see modelchain.rst use ModelChain.results so that it doesn't encourage users to use deprecated functionality (see the current "latest" build log, ctfl-f "Use ModelChain.results").

I agree, but I think #1115 might be a pretty big lift.

[mikofski]

Agreed on deferring infinite sheds, I think the PR is very close, just needs some examples for the gallery, but it may take a long time to review.

[wholmgren]

It would make some sense to address #1113 and #894 together. I don't know if we can achieve community consensus on that before 0.9.

[cwhanse]

It would make some sense to address #1113 and #894 together. I don't know if we can achieve community consensus on that before 0.9.

I agree. Both will need a deprecation period. Would that make sense to run from v0.9.1 to v0.10, or would it be preferred to being with v0.9?

[wholmgren]

Perhaps preferable to start the deprecation in v0.9. But starting the deprecation in v0.9.1 would be ok and consistent with the way we've done deprecations in the past. Or we can go straight to v0.10 if we want to make that change on a bigger release (perhaps postponing a few other deprecations to v0.11).

[mikofski]

It would make some sense to address #1113 and #894 together. I don't know if we can achieve community consensus on that before 0.9.

It makes sense to me to address them together, but I wonder if it will be possible. I didn't get a clear sense from #894 that there was a consensus. Has it been discussed in the google group? On the other hand, #1113 seems more pressing. The existing behavior is a problem which should be addressed, possibly before we can reach a consensus on temperature.

I'm also fine with starting the deprecation cycle in 0.9.1 and ending it with 0.10.

[wholmgren]

Have we agreed to defer all remaining issues listed above? I can take another look at #1254. Is #1258 ready too? From a quick look at new issues I think the only one I'd consider adding is #1221.

[cwhanse]

#1258 slipped off my list, we should review and merge. My apologies to @jranalli

#1221 should be included in v0.9.

I don't have time to work on #1113 and related, so I vote deferring.

[kandersolar]

I have a few gallery examples drafted for Array & Mount, and a small set of edits to the .rst pages about Mount stuff, it's not much but maybe better than nothing for now. Worth opening PRs for those now, or wait for 0.9.1?

[wholmgren]

@kanderso-nrel worth opening now

[wholmgren]

I relabeled issues/PRs with new milestones. I believe the 0.9.0 milestone tracker is now accurate.

[cwhanse]

Looks like #1273 is the last open item before v0.9.

[kandersolar]

Oh, can we add #1268 to the list? I think that one makes sense for v0.9.0 too.

[cwhanse]

I'm OK with adding #1268 since I believe we decided to implement these changes without deprecation. Better to rip the bandaid right off than continue to think about it.

[AdamRJensen]

#1268 also includes changes to the unreleased get_bsrn and get_cams functions that would become breaking changes if not implemented now, so it certainly makes sense to include!

[wholmgren]

When cleaning up the whats new for the release we might want to add a note about github discussions. And maybe in the release announcement. Depends on how aggressive you all want to be in pushing discussions. I am neutral and will leave it to others to experiment.

[wholmgren]

Another 0.9 status check:

• We need a decision on the kwarg in Change local_path to save_path in get_bsrn #1282. Change the name or delete it?
• Defer make tables a required dependency #1286 until it's less of a hassle?
• Include Add retrieval function for ERA5 reanalysis data #1264 and Add retrieval function for NASA MERRA2 reanalysis data #1274? I'm -1. I think we need to take some time to think through how we want to use xarray and dask.
• Finalize whats new

I suppose one could argue that given all of the new iotools functions, we should hold up 0.9 if there's a non-negligible chance we'll reorganize them in the short term. Sigh. Or maybe drop warnings into those modules that the API is likely to change without deprecation.

[cwhanse]

I haven't kept up with the iotools PRs and discussion so have no opinion about #1264 and #1275.

Related to #1282, I favor @mikofski's approach of adding a download function, and keep the save_path kwarg in the get function. I think this is useful functionality for the module.

I can reluctantly agree to deferring #1286.

[kandersolar]

#1286 might have a solution, see #1287 (comment). Ok with me to defer #1264 and especially #1274.

[wholmgren]

Related to #1282, I favor @mikofski's approach of adding a download function, and keep the save_path kwarg in the get function. I think this is useful functionality for the module.

@cwhanse are you suggesting that you're ok with either approach or that you want both approaches implemented?

The main problem is a lack of consensus on how to support the download function. It might take careful thought and larger refactorings to do so consistently across iotools. So do we forge ahead with an API that risks immediate deprecation or do we remove the unreleased feature from 0.9?

That and finalizing what's new are the only issues remaining for 0.9.

[cwhanse]

I'm in agreement (generally) with the quartet of functions described here.

I'm OK if the save_path capability is the exception rather than the rule for iotools functions, provided where downloads are non-trivial as @mikofski and @AdamRJensen describe here and here.

[mikofski]

Hi All, where are we on v0.9.0? Are we waiting for #1264, #1274, and #1295?

[cwhanse]

We have 2 votes to defer #1264 and #1274, and I've abstained since I haven't kept up with these PRs.

I think #1295 should be deferred.

As far as I can see, looking over this conversation, all other PRs and issues for v0.9 have been merged or deferred.

[wholmgren]

I think we only need to finalize the whats new (date, double check no sphinx build errors for linked objects).