Sam 1064 correct monthly curtailment

[brtietz]

Fixes NREL/SAM#1064

Recalculates monthly energy in cmod grid & moves annual outputs to the attic to avoid confusion

Generic system with a constant generation profile makes a good test. A grid connection limit of 1 kW should result in monthly energy equal to the number of hours in each month. Sample file with that configuration:
monthly_values_interconnection_limits.zip

[sjanzou]

The changes look fine and thanks for putting annualoutput in the attic...

However, the geothermal test is failing since the compute module has a monthly output and the grid monthly energy seems to be overwriting with length 12 instead of 12*25 = 300 months in the analysis period.

Please check the test and update, thanks!

[brtietz]

@sjanzou, @mjprilliman, and @cpaulgilman This strikes me as an odd convention from cmod_geothermal. In particular:

1. It's the only compute module where monthly_energy isn't length 12
2. It's using an array where other technologies would use a matrix and the year-month structure

My inclination is to revise cmod_geothermal such that monthly_energy follows the convention of other compute modules (length 12, year 1 only) and then implement a new variable that displays the lifetime data without curtailment to preserve the current output.

Does this break anything that you're aware of downstream? If not, what are your preferences between maintaining the current array structure versus shifting to a matrix with the year-month structure? Given answers to those I can propose some variable names.

[mjprilliman]

@sjanzou, @mjprilliman, and @cpaulgilman This strikes me as an odd convention from cmod_geothermal. In particular:

1. It's the only compute module where monthly_energy isn't length 12
2. It's using an array where other technologies would use a matrix and the year-month structure

My inclination is to revise cmod_geothermal such that monthly_energy follows the convention of other compute modules (length 12, year 1 only) and then implement a new variable that displays the lifetime data without curtailment to preserve the current output.

Does this break anything that you're aware of downstream? If not, what are your preferences between maintaining the current array structure versus shifting to a matrix with the year-month structure? Given answers to those I can propose some variable names.

I'm not opposed to changing the variable name. I'll have to check the downstream changes but I don't anticipate it being too much difficulty. Monthly energy output is an important metric for geothermal (more so than hourly typically) so I'm hesitant to put it into a matrix structure. I think a newly named array variable would be the best path forward.

[brtietz]

Thanks! A few name options:

• monthly_energy_lifetime
• monthly_energy_gross
• monthly_energy_pre_curtailment

Preferences?

[cpaulgilman]

Thanks! A few name options:

* monthly_energy_lifetime

* monthly_energy_gross

* monthly_energy_pre_curtailment

Preferences?

I think monthly_energy_lifetime is the least mysterious.

[cpaulgilman]

Looks good. Tested in SAM with Generic / Single Owner and Geothermal / Single Owner, and reviewed monthly energy variable names in LK script.

[sjanzou]

Thanks for updating the tests! Changes look good!