Add detailed PV model (pvsamv1)

[Matthew-Boyd]

• Improve value assignment in power_source
• Add detailed PV model (pvsamv1)
• Add custom PV model capability

[Matthew-Boyd]

@dguittet

• For parameter coherence, should nstrings be aligned to system_capacity or the other way around? See line 56 in detailed_pv_plant.py
• Should detailed_pv_plant.py be named detailed_pv_source.py to relate better to pv_source.py?
• Next steps:
  • generalize grid financial model (so a custom financial model doesn't need all the singleowner parameters)
  • add detailed PV layout capability
  • add custom financial model capability

[dguittet]

@Matthew-Boyd I think the workflow goes: target design capacity and ratios -> figure out the nstrings, nmodules etc which are integer and so might not result in exactly the desired target design capacity and ratios -> then set the system_capacity, which is really more like a reporting step since in Pvsamv1, the system_capacity is a calculated variable. Did I understand the question correctly?

[Matthew-Boyd]

@Matthew-Boyd I think the workflow goes: target design capacity and ratios -> figure out the nstrings, nmodules etc which are integer and so might not result in exactly the desired target design capacity and ratios -> then set the system_capacity, which is really more like a reporting step since in Pvsamv1, the system_capacity is a calculated variable. Did I understand the question correctly?

@dguittet Thanks, and yes, you understood correctly. I wasn't sure if this would apply to plant initialization, but I guess so. I've made the change.

[dguittet]

How I've tried to handle this issue of interdependent variables is shown in the wind source. For instance, in the __init__, the turbine rating is assigned from the config, and the rating then changes the system capacity:

HOPP/hybrid/wind_source.py

Line 71 in c4e2a55

self.turb_rating = farm_config['turbine_rating_kw']

The turb_rating is actually a Python class property with custom-defined getters and setters, as you can see here:

HOPP/hybrid/wind_source.py

Line 130 in c4e2a55

def turb_rating(self, rating_kw):

Whenever the setter self.turb_rating = x is called, we end up going to that custom function. That custom function's job is to make everything in PySAM consistent to the best of its ability.

When you have these new Pvsamv1 variables that users are supposed to use, you will need to add these class properties to control how they are accessed and modified. We want to enable the ability for the user to do:

pvplant.n_strings = 11
pvplant.module_power = 240
pvplant.subarray1_modules_per_string = 10
...

and have the end resulting Pvsamv1 model consistent.

[Matthew-Boyd]

I've been running into trouble with the way some properties are set up in HOPP, where you get caught in loops, and that's why I'm setting these directly. In this case, the actual system_capacity has been calculated (without designing a new layout) and should be set in the pysam model as-is, where the property is set up to assume it's been given the target system_capacity and it then calculates a new layout and sets a different system_capacity.

[dguittet]

I wonder if there's a more explicit way to let users choose between creating a DetailedPVPlant vs a PVPlant?

[Matthew-Boyd]

I was wondering this too... let's discuss.

[Matthew-Boyd]

@dguittet This covers everything we discussed last week. There's one test failing in one build, for what looks to be an nsrdb download issue.

[dguittet]

Should this be subarray2-4?

[Matthew-Boyd]

Agh, darn it! Thanks for the catch!

[dguittet]

I think this is good to merge after that minor subarray2-4 change!