Using ModelChain with Plane of Array (POA) as weather input

[srlightfoote]

I really love the concept of the ModelChain in pvlib. However, I would like to be able to use the ModelChain to model DC and AC output of a given system (more than one module and inverter) using Plane of Array irradiance as the weather input, rather than inputting the GHI, DNI and DHI components (which I don't have measurements of) and then specifying a transposition model as part of the ModelChain. Could this functionality of being able to specify:
mc=pvlib.modelchain.ModelChain(transposition_model='None')

and then inputing poa_global data as an input to weather data frame in mc.run_model?

[cwhanse]

I agree, this enhancement would be valuable. There isn't an elegant way to supply poa_global in place of GHI, etc., in the ModelChain methods. #478 wrestled with this issue.

A question for @srlightfoote : in your use case, does poa_global already account for either spectral content or reflection loss? I can foresee use cases where poa_global is sourced from different measurement devices (reference cell, photodiode, pyranometer) where the adjustments to poa_global from spectrum and reflections may already be accounted for in the measurement.

[srlightfoote]

Not sure I’m qualified to answer the question other than to say that the use case would be for a Pyranometer (secondary standard or other) at a typical operational solar plant installed at the POA of the modules, either at a fixed tilt, or mounted on a tracker array.

[cwhanse]

OK, if it's a pyranometer then we should anticipate the POA irradiance is broadband without either spectral adjustment or reflection losses. I just wanted to confirm this use case is of interest before we consider the ModelChain design changes.

[mikofski]

I believe that using poa as input is the goal of the gti dirint changes in #400 and #396

[wholmgren]

@mikofski They are certainly related ideas, but I wrote #400 because it was useful for some parameter fitting algorithms, not because I wanted to integrate the output with ModelChain. I don't expect to explicitly support the combination in pvlib.

[cwhanse]

@mikofski I don't think that starting with POA, translating to GHI, then transposing back to POA to provide input to a power simulation is wise. I doubt that the POA-GHI-POA circle closes to the same values.

I think that we can enhance the prepare_inputs convenience function to accept poa as a column of input data. While we're at it, we could also allow prepare_inputs to accept 2 of GHI, DHI, or DNI, and calculate the missing component by closure.

[srlightfoote]

@cwhanse I agree wholeheartedly with your assessment that an expansion of the prepare_inputs function is probably a good way to go and also that we probably don't want to include additional uncertainties / biases in doing the roundabout POA --> GHI --> POA method. If we have POA, we should use it. That said, wouldn't there be a conflict with the defaults of the ModelChain creation function which by default applies a transposition algorithm? If the disabling of a transposition algorithm isn't done until the run_model function is executed this could be an unexpected result for the user. Obviously the user could modify the ModelChain transposition algorithm choice to None or False when calling it in the first place, but that isn't currently the default. Ideally, the weather data would be an input to Model Chain itself whereby the code logic used to define the transposition method would default to 'None' or False if a poa_global column of data was included. Perhaps the simplest update, other than just allowing the ability to input poa_global into weather and disabling the transposition algorithm step in run_model would be to have the transposition algorithm be overwritten to "None" or "False" upon execution of "run_model" if poa_global is detected in the weather data and a simple warning is printed to the command line indicating that this was done. I suppose run_model could also just error as well if poa_global is detected along with a defined transposition algorithm.

Thanks all for your interest in this update. Let me know if I can be of further help. I'm afraid my python skills are probably insufficient at this point to contribute to the package, but hopefully in the future I'll be able to lend a hand.

[mikofski]

@cwhanse, @wholmgren, @srlightfoote, I'm sorry, I was confused, you are correct, POA if measured and matching spectral and IAM of panels, then should be used directly.

I was thinking about shading, then you might need the components individually for shade and unshaded areas, but correct also that roundabout process will introduce uncertainties.

Although, if POA measurements are not matched spectrally or have different IAM, then I don't see what other choice you would have than go the roundabout way, right?

[wholmgren]

I'm not too excited about making ModelChain.prepare_inputs do more than it already does. Maybe it would be ok if some of the existing functionality is refactored into other methods. Perhaps we should think about a new method such as run_model_from_poa. Maybe also rename the existing run_model to something like run_model_from_weather (not sure about this name, but hopefully it gets the idea across).

If we did both of the above, the transposition argument could be used to map the generic name run_model to the relevant specific method. Other options (as discussed in #478) could come into play in that mapping as well. I'm not sure if that's a good idea, just brainstorming.

While we're at it, we could also allow prepare_inputs to accept 2 of GHI, DHI, or DNI, and calculate the missing component by closure.

In #239 we decided to make a new method, ModelChain.complete_irradiance, and expected the user to call this method first if necessary. I still think this is a good design choice. Also relevant to my point of view here is that I think that we should remove the "use clear sky by default" behavior of run_model/prepare_inputs.

[kevinsa5]

@cwhanse As far as use-cases go, it would be handy to be able to specify either pyranometer or reference cell as the sensor type when supplying measured POA data (SAM has this toggle). Though if the scope is limited to only allowing one of them, I would agree that assuming pyranometer is preferable.

Additionally, for what it's worth about POA-GHI-POA: SAM will decompose measured POA into constituent direct/diffuse components for shading calculation purposes, and in my experience the recombined POA is pretty close to the original (within a W/m2 or two). But I have no hard data to show for this.

[markcampanelli]

Sorry, I did not see this until just now.

Is there any way that we can abstract these three lines in ModelChain.run_model:

self.aoi_model()
self.spectral_model()
self.effective_irradiance_model()

into a single self.compute_irradiance() method that complements the single temperature method self.compute_temperature()? The interface for this method is "simply" to compute whatever irradiance input is needed to the DC model whose parameters are in the PVSystem member and whose implementation is in ModelChain.dc_model. (Also, this self.compute_irradiance()'s output may need to inform the subsequent self.compute_temperature() call.) Implementing self.compute_irradiance() generally for existing and future/custom dc_models is where the (potentially disruptive) refactor presumably occurs.

@srlightfoote PVfit can use measurements of an IEC 61853-1 calibrated reference PV device (say, a matched reference module at the same orientation as the array) and directly produce an "effective irradiance ratio" F := Isc/Isc0 and a cell temperature, T, which is then passed to a single-diode performance model that is parameterized directly in terms of F (as opposed to G with various corrections). I can even envision a F-measurement scheme that computes F using a module's T-dependent irradiance-mode spectral response, a conventional module temperature model, and some sort of global tilted spectrometer. Thus, in #478, I was trying to accommodate these possibilities, while "falling back" to a variant of the SAPM to compute F and T from "conventional" MET-station-based weather data when a reference PV device is not available.

[cwhanse]

@markcampanelli are you suggesting to replace the three separate calculations with a single call to a new method? What would the new method do that the current methods don't?