Closed grantbuster closed 2 years ago
Merging #361 (5bfcdad) into main (5bfcdad) will not change coverage. The diff coverage is
n/a
.:exclamation: Current head 5bfcdad differs from pull request most recent head fa9d7ba. Consider uploading reports for the commit fa9d7ba to get more accurate results
@@ Coverage Diff @@
## main #361 +/- ##
=======================================
Coverage 79.05% 79.05%
=======================================
Files 135 135
Lines 18256 18256
=======================================
Hits 14432 14432
Misses 3824 3824
Flag | Coverage Δ | |
---|---|---|
unittests | 79.05% <0.00%> (ø) |
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 5bfcdad...fa9d7ba. Read the comment docs.
Full scale test failed... I think the bespoke meta is missing the sc_(row,col)_ind
columns: https://github.com/NREL/reV/blob/a947b6ba8677224a939a1b2ac9b97d91525f06b2/reV/bespoke/bespoke.py#L355
Eagle test run directory: /shared-projects/rev/projects/weto/fy22/bespoke/rev/test_runs_conus_sc
Will add a review after patch
There's actually kind of a big issue that we need to make sure we're calculating LCOE(FCR) for the timeseries SAM simulation based on inputs from the optimized plant layout... Need to figure out with PJ how to link up the cost parameters...
Yea, Owen, Travis, and I actually already talked about that. I was going to patch it in with a more general reV maintenance patch sometime this week. AFAIK, it should be straightforward by setting the OPEX and CAPEX correctly in the SAM config after the plant optimization
Yeah here's what I'm thinking: FCR and VOP would be taken from the input config and would be fixed, cap cost and fixed op cost would be based on the optimized plant. I'll just add optional inputs (required if lcoe_fcr
is requested) to the sam_sys_inputs
that would be capital_cost_per_mw
and fixed_operating_cost_per_mw
and then have the user input those.
Couldn't you just compute capital_cost_per_mw
and fixed_operating_cost_per_mw
from the input config (before running the optimization)? capital_cost
, fixed_operating_cost
, and system_capacity
are already required parameters, so the relationships capital_cost_per_mw = capital_cost / (system_capacity / 1000)
and fixed_operating_cost_per_mw = fixed_operating_cost / (system_capacity / 1000)
should hold prior to optimization
Yep we could do that too! I'm not sure if system_capacity is really required for bespoke but I agree that makes more sense than new keys
Ah fair. We have been throwing it in anyways, probably because old habits die hard XD
Good idea though, i'll go ahead and implement that
This needs to be tested full scale but it won't break anything so opening a PR now