add capability to job/ app (API v3 using REopt.jl backend) to handle CHP

[hdunham]

Please check if the PR fulfills these requirements

• [x] CHANGELOG.md is updated
• [x] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce?

Add capability to job/ app (API v3 using REopt.jl backend) to handle CHP technology

[Bill-Becker]

@zolanaj When I POST a CHP run with a prime_mover, I'm getting an inputs error that it's expecting a few other inputs which should be assigned based on prime_mover.

"input_errors": {"CHP": {"installed_cost_per_kw": ["This field cannot be blank."], "tech_sizes_for_cost_curve": ["This field cannot be blank."], "unavailability_periods": ["This field cannot be blank."]}

[Bill-Becker]

Looks like it's because those model fields don't have "blank=True" - just want to check if that was intentionally omitted?

Relatedly, if the user does NOT put in prime_mover, or they want use the same installed_cost_per_kw for all sizes, we actually don't require a list for installed_cost_per_kw and tech_sizes_for_cost_curve because there should be an option to just put in a single value (scalar) for installed_cost_per_kw with no associated tech_sizes_for_cost_curve (it then assumes the installed_cost_per_kw is applied to any/all sizes).

[zolanaj]

@zolanaj When I POST a CHP run with a prime_mover, I'm getting an inputs error that it's expecting a few other inputs which should be assigned based on prime_mover.

"input_errors": {"CHP": {"installed_cost_per_kw": ["This field cannot be blank."], "tech_sizes_for_cost_curve": ["This field cannot be blank."], "unavailability_periods": ["This field cannot be blank."]}

Looks like it's because those model fields don't have "blank=True" - just want to check if that was intentionally omitted?

Relatedly, if the user does NOT put in prime_mover, or they want use the same installed_cost_per_kw for all sizes, we actually don't require a list for installed_cost_per_kw and tech_sizes_for_cost_curve because there should be an option to just put in a single value (scalar) for installed_cost_per_kw with no associated tech_sizes_for_cost_curve (it then assumes the installed_cost_per_kw is applied to any/all sizes).

Thanks for catching the cause! The fix that enables blank values for prime_mover notes is in https://github.com/NREL/REopt_API/pull/340/commits/f446966cbf2c456cde5656ffef32ad0a5350ce10 and the allowance for installed_cost_per_kw as a float and tech_sizes_for_cost_curve to be blank is fixed in https://github.com/NREL/REopt_API/pull/340/commits/1035b8a20b2d714c105c322c3001edca57a46fca and tested now in https://github.com/NREL/REopt_API/pull/340/commits/1bb59129795eee5a30a1b2554e730bb25ae57e68. There are a couple additional things I caught in here.

Could you let me know if the post you mentioned above works correctly now, and if not, could you send me your post so that I can ensure the new test covers that contingency?

[Bill-Becker]

@zolanaj I'm now getting an error when validators.py tries to model.save() on line 539. Have you been able to POST a job with CHP?

[Bill-Becker]

@zolanaj I just realized as I was about to add the call to /chp_defaults from validators.py to assign defaults that I need to add the equivalent of the reo.views.simulated_load function to to get the avg_boiler_fuel_load_mmbtu_per_hour input for the chp_defaults endpoint. This is a pretty big effort, so I'll have to find some time over the next week or two to tackle it.

[Bill-Becker]

@zolanaj Still waiting on the results of the test suite, but this should be good to re-review for you - I'll debug any tests that are still failing. I made pretty sweeping changes of your implementation of CHP defaults and validation - sorry about that, I didn't realize the most efficient way forward was to use REopt.jl's REoptInputs.s (Scenario) to assign the defaults back to models.py CHPInputs fields until after I was way into it. I made equivalent tests of the tests that you made for CHP defaults and validation, consistent with the revised processing.

Note, this branch is currently using the simulated-load branch of REopt.jl because it has integrated some of those features. We'll have to merge that stuff into REopt.jl master before merging this.