Hard-coded solar inputs

[paulf81]

Hi @misi9170 , @brookeslawski and @genevievestarke , question for you, in the function _setup_model_parameters in solar_pysam_pvwatts.py, some values are set by the h_dict (passed though from input yaml) while some are hard coded:

https://github.com/NREL/hercules/blob/0fbd6567fc4802cc1c9f7335543f9a43d64d67d0/hercules/plant_components/solar_pysam_pvwatts.py#L32

        sys_design = {
            "ModelParams": {
                "SystemDesign": {
                    "array_type": 3.0,  # single axis backtracking
                    "azimuth": 180.0,
                    "dc_ac_ratio": h_dict[self.component_name]["target_dc_ac_ratio"],
                    "gcr": 0.29999999999999999,
                    "inv_eff": 96,
                    "losses": 14.075660688264469,
                    "module_type": 2.0,
                    "system_capacity": h_dict[self.component_name]["target_system_capacity"],
                    "tilt": 0.0,
                },
            },
            "Other": {
                "lat": h_dict[self.component_name]["lat"],
                "lon": h_dict[self.component_name]["lon"],
                "elev": h_dict[self.component_name]["elev"],
            },
        }

I don't want to crowd the input file with options that rarely change, but some of these seem they might better be set by the input file. Do you have a preference on which ones should be set by the input file and which are fine to stay hard-coded?

[misi9170]

Another option is to have these as defaults, and the user may specify them on the input file---that way the input file doesn't get crowded unless users really want to change things.

[paulf81]

That makes sense to me, I have a few quick thoughts:

1. Some things probably, even if annoying shouldn't have defaults. It took me a little while to work out why solar was never reaching it's capacity (these efficiency losses). I probably won't be the last person to miss this

2. GCR I think for example could remain hard-coded, I don't think it impacts Hercules at all for now

3. There's also a question of where the defaults are implemented. Their isn't infrastructure yet in the reader so would probably happen at the component level, does that work for you?

Starting a quick list:

Must specify:

• Capacity
• lot, lon, elev
• effiency terms

Has defaults

• array_type
• azimuth
• dc_ac_ratio
• module_type

Rest are hard coded

[misi9170]

Yeah I think defaults can live at the component level. For things like this that are stored in dictionaries, there's a convenient way of combining defaults with user-provided values that I've used a bit in the past:

default_values = {"a": 1, "b": 2, "d": 4} # Lives in the component code
user_provided_values = {"a": 0, "c": 3} # Read in from the input file, for example
values = {**default_values, **user_provided_values} # Order matters: defaults have to go first
print(values)

This produces:

{"a": 0, "b": 2, "d": 4, "c": 3}

i.e. the defaults with "a" overwritten and "c" added.

[brookeslawski]

This plan looks good to me. If we want to use Misha's method for setting defaults, the the default losses should be 14%.

Also following up on my conversation with Paul. There are two inputs that reduce the solar power generated compared to the input system size (e.g. cause <100 MW generated power from a a 100 MW PV plant): inverter efficiency (inv_eff) and losses. Right now, we output the system power generated (which I believe is the same as the AC inverter output power) by selecting the output variable system_model.Outputs.gen. Another option could be to also output the DC inverter input power dc, which is the power generated by the PV modules before it reaches the inverter so this power is not affected by inv_eff, thus eliminating any losses. Under maximum POA irradiance, the dc variable would output 100 MW for a 100 MW system.

Variable list found here: https://nrel-pysam.readthedocs.io/en/main/modules/Pvwattsv8.html

[brookeslawski]

I reviewed the docs about solar in the v2 branch and made some small changes based on what we discussed today. I added a bit more explanation to the inv_eff and losses parameters and removed "These parameters allow you to configure the efficiency characteristics of your solar system while maintaining the dc_ac_ratio at 1.0." This sentence seemed to be using the dc_ac_ratio as the inv_eff when it's a separate parameter that governs the design of the system. For example, a dc_ac_ratio of 1.2 means the DC capacity of the system is 20% larger than the AC inverter capacity. Documenting it here in case my interpretation is off and you want to keep it in there.

[paulf81]

ok I think the latest versions includes these recommendations now, thanks @brookeslawski !