Slight typo

[kjsauer]

temperature.py

PVWatts defauls is 9.144 [m]

defauls -> default

[kandersolar]

Thanks @kjsauer! Want to submit a PR to correct it?

[kjsauer]

I looked at the PVWatts reference doc. I don't see anything relating to 9.144 m (i.e., 30 feet). (It's in the Fuentes paper, though - I assume such 9.144 m wind speed height data was used in Fuentes's PV thermal model development, e.g., coefficient fitting.) In terms of PV thermal model application, the referenced PVWatts manual says TMY wind speed is at 10 m (Section 4). I'm not sure if PVWatts is translating wind speed data from a height of 10 m corresponding to the TMY wind speed data or from a height of 9.144 m corresponding to Fuentes's wind speed data used for model fitting (and how to figure out that answer, e.g., a PVWatts source code file, which I don't have handy at the moment, or personal conversation with someone who has knowledge of/access to the PVWatts source code). So, simple spelling error aside, the more important (related) and complex issue is that I'm not sure which of the following is the more appropriate guidance:

A.) Fuentes default is 9.144 [m] -> Existing reference doc [1]
B.) PVWatts default is 10 [m] -> Existing reference doc [2]
C.) PVWatts default is 9.144 [m] -> Some new TBD reference doc
D.) Something else altogether

Please advise.

P.S. Incidentally, I don't see it clearly listed in the Fuentes paper what the PV array (aka PV module) height is. However, presumably this is the height at which the Fuentes-derived coefficients apply. Whatever it is, if it doesn't match the PVWatts-reported value of 5 m (~16.4 feet above ground which is quite high off the ground) (Section 9), and if PVWatts is using Fuentes-derived PV thermal model coefficients, then this may raise other issues also (if my understanding is correct) - namely, I presume the Fuentes coefficients apply to whatever "Height of module (m)" was used in the derivation of said coefficients. Like, for the PVsyst thermal model, my assumption has been that if you derive {Uc, Uv} using wind speed data at some height (let's say, 10-m), then those coefficients apply (only) for cases where wind speed data is at that same height (in this example, 10-m).

[kandersolar]

Will take a closer look tomorrow, but the 9.144 number was taken from the SSC PVWatts implementation, which our implementation was meant to mimic. The SSC comments provide some breadcrumbs:

https://github.com/NREL/ssc/blob/c72cfab5c831b131e136cb2fc48bf10c58304031/shared/lib_pvwatts.cpp#L194-L196

[cwhanse]

30ft is the height of the anemometer that was used as the predictor for wind speed at different heights above the ground. See this pub: https://www2.jpl.nasa.gov/adv_tech/photovol/2016CTR/SNL%20-%20Est%20Wind%20Speed%20vs%20Height_1985.pdf

[kjsauer]

My gut feeling is that if PVWatts wants to apply Fuentes-derived PV thermal model coefficients, they need to translate the 10-m TMY wind speed height to the same PV module height assumed by Fuentes in deriving said coefficients.

[cwhanse]

@kjsauer translating wind to module height is being done in the lines of code that @kandersolar linked. Is your question about the pvwatts functions in pvlib, or about PVWatts (the NREL application)?

[kjsauer]

Indeed, it appears PVWatts is translating from a wind speed height of 9.144 m to a PV module height of 5 m in order to then apply Fuentes-derived PV thermal model coefficients (which were derived for/are specific to some specific PV module height, let's call it X meters). I'm thinking the 9.144 m is supposed to be 10 m (the height of the TMY wind speed data used in PVWatts) and the 5 m is supposed to be X m where X is the PV module height used by Fuentes in deriving said PV thermal model coefficients. The question is primarily one for PVWatts, so I just opened a GitHub Issue there. But it then affects the PVLIB function's default values and possibly the referenced docs also.

I suppose the short path forward is to fix the spelling error which prompted this GitHub Issue and then close this issue. Then, once the new GitHub Issue in the other repository "ssc" is resolved, any new guidance which comes out of that can perhaps transfer over into this repo via another (new) GitHub Issue opened in this repo.

I defer to all of you. But I'm not really comfortable fixing a trivial spelling error myself when there may be more fundamental questions which remain open. Once the latter are resolved and the way forward on both the ssc and pvlib-python repos is clear, then sure, I'd be happy to do a PR after that. (In the meantime, please feel free to do a PR without me!)

Edit: In addition to the spelling fix, I think we also need to add a reference to the PVWatts source code that Kevin provided above (or some other reference) as the source of the "PVWatts default is 9.144 [m]" because as far as I can tell this information's not contained in the existing two (2) reference docs. e.g., As such:

PVWatts default is 9.144 [m] [3]

[3] https://github.com/NREL/ssc/blob/c72cfab5c831b131e136cb2fc48bf10c58304031/shared/lib_pvwatts.cpp#L194-L196

[cpaulgilman]

Wind speed data in weather files from the NSRDB is from MERRA2 and is 2-meter data. I haven't found this written in any of the NSRDB documentation, but there is a discussion at about 1:10 in the Q&A segment of this 2022 NREL webinar on the NSRDB: https://www.youtube.com/watch?v=BzNoYACXCOY&t=4220s.

[kjsauer]

That's certainly interesting (and somewhat unexpected and disconcerting if true...). I just want to quickly point out what I already mentioned above, which is that the most up to date PVWatts reference document says the TMY wind speed in use is at a height of 10 m. Depending on what we find out, we may need yet another reference doc...

I guess I should've known all this already, because apparently I asked the question...
https://webcache.googleusercontent.com/search?q=cache:dqpgedl3nbgJ:https://nsrdb.nrel.gov/nsrdb/NSRDB_Webinar_QA_-_Oct_6_2020.pdf
"""
Wasn't the historical wind speed data at 10 m? Can old data be mixed w/ new given the change to 2 m? If we download all the individual years of data, is the wind speed always at 10 m or 2 m or is there some mixture of heights?

As of PSM v3 the windspeed data is at 2m. PSM v2 used MERRA derived windspeed which was computed at 10m. We need feedback from users about whether the 2m or 10m data is more useful for PV and CSP modeling.
"""

[adriesse]

I'm getting 10m wind from ecmwf and still perceive this as a the most common height. Anything lower is a crap shoot because of surface roughness, which PV arrays modify.

[kjsauer]

Ideally, I'd like to tag (via GitHub username at-handle) someone from NSRDB to weigh in on this. However, I don't know the GitHub username of anyone from NSRDB. I've emailed them about it.

[kandersolar]

But I'm not really comfortable fixing a trivial spelling error myself when there may be more fundamental questions which remain open.

I don't see any need to hold off on fixing a spelling error, but of course feel free to submit a PR whenever you like!

I think we also need to add a reference to the PVWatts source code that Kevin provided above (or some other reference) as the source of the "PVWatts default is 9.144 [m]" because as far as I can tell this information's not contained in the existing two (2) reference docs.

Agreed it would be good to list a reference for the 9.144 value. It goes all the way back to the second-ever commit in the SSC repository: https://github.com/NREL/ssc/blob/88207e11ee697210f721bdfaa556888f77c79560/src/lib_pvwatts.cpp#L222-L224

I wonder if it was inherited from PVFORM? Unfortunately I've never been able to locate the source code for PVFORM; if anyone has a copy I'd be interested to learn what it used.

Regarding the NSRDB wind heights and how PVWatts should handle it: it's an interesting discussion, but IMHO better suited to continue discussion in that SSC issue. Regardless of what comes out of that discussion, our goal with pvlib.temperature.fuentes was to replicate the behavior of PVWatts v5/v7, so I think we're going to keep the 9.144 default here.

[kjsauer]

I agree that we can fix that slight typo and then close this GitHub Issue and then continue the discussion in the other, more relevant GitHub repository. I'll add it to my to-do list to make that PR, but I must admit I'm quite busy and don't know when I'll get around to it, so please don't hesitate to do it without me (if so, please just post an update here, and I'll do the same if I get around to it first). Thanks.