Closed echedey-ls closed 4 months ago
I am a complete non-expert in agriPV, but my initial reaction is that PAR is too narrow a modeling scope to warrant its own pvlib.par
module. I could potentially be convinced that a broader pvlib.agrivoltaics
module is a good idea, but it seems to me that many models relevant to agriPV will fit naturally into existing modules. For example, PAR models could go in pvlib.spectrum
(PAR is basically just spectral mismatch for plants, right?) or pvlib.irradiance
, and several relevant view factor calculations are already available in pvlib.bifacial.utils
.
For example, PAR models could go in
pvlib.spectrum
(PAR is basically just spectral mismatch for plants, right?) orpvlib.irradiance
, and several relevant view factor calculations are already available inpvlib.bifacial.utils
.
I agree that it seems to make sense to put PAR functions in pvlib.spectrum
.
I've kept the documentation API section on agrivoltaics. Should I remove it too?
Just a minor organization idea, the function can be under pvlib.spectrum
namespace but in another file, currently I've put it inside mismatch.py
.
I've kept the documentation API section on agrivoltaics. Should I remove it too?
Hmm I'd lean towards keeping it with it's module.
Just a minor organization idea, the function can be under
pvlib.spectrum
namespace but in another file, currently I've put it insidemismatch.py
.
What would the argument be for thar?
Hmm I'd lean towards keeping it with it's module.
Okay, I don't have a strong opinion on that either.
What would the argument be for thar?
I kinda dislike having too many functions of different topics in the same file. Not a problem to have it there for me; in fact, isolating one function in a file is kinda weird too, so I'm happy with it in mismatch.py
. It is just another idea to take into account in case of a big-reorg.
@echedey-ls @AdamRJensen I commented on echedey's GSoC issue. I think the PAR function should live in pvlib.irradiance
.
Just a minor organization idea, the function can be under pvlib.spectrum namespace but in another file
This is my preference if we anticipate additional spectral models for agrivoltaics. I don't know much about it but anticipate that there may be interest in, say, integration of quantum efficiency curves and that naturally should be near the similar code for traditional PV.
I'm not too enthusiastic about irradiance.py... this function only appears to potentially fit there because that module is already so broad in scope. (Recall previous discussion of breaking it up into transposition.py and other modules)
But the new function in #2048 isn't a spectral model in the scope of pvlib.spectrum
s code module description. It's just translating broadband DHI fraction from diffuse fraction for a restricted range of wavelength. I think it is another version of an irradiance separation model.
We have three comment threads on this naming/organization: here, #2064 and #2048.
Following my GSoC proposal, there are two models I plan to contribute regarding Photosynthetically Active Radiation, PAR. This is of great importance in the design of AgriVoltaic systems, since PAR is one of the metrics used for the simulation of crops productivity.
I pretend this is the first one due to simplicity. The model takes an input of the global irradiance diffuse fraction and the solar elevation, and outputs the fraction of diffuse PAR. See Eq. (1) in [2]. It is a derivation of equations (9) & (10) in [1]. This is known as the Spitters relationship in [2].
10.1016/0168-1923(86)90060-2
.10.1016/j.solener.2022.05.046
.Describe the solution you'd like A function in a new module, presumably
pvlib.par
, that has the functionspitters_relationship
with the described inputs and output.Describe alternatives you've considered Other names for the module
pvlib.agrivoltaic[s]
or trying to fit it into current structure until new things can be included and then arranged in the future. Take into account moving things requires deprecations. Other names for the function, may bepar_diffuse_fraction_from_global
or so. However, I think an author-named model is better in this case. There may be more models about that, like the modified by Gu et al., Eq. (3) in [2].As always, I'm open to other alternatives.
Additional context I will open a PR in short as an initial proposal.
Ask, discuss and suggest freely.