Add BESS dispatch options and export

[lixiangk1]

Please check if the PR fulfills these requirements

• CHANGELOG.md is updated
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• Any new Django model inputs have also been added to job/test/posts/all_inputs_test.json

What kind of change does this PR introduce?

(Bug fix, feature, docs update, ...)

What is the current behavior?

(You can also link to an open issue here)

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change?

(What changes might users need to make in their application due to this PR?)

Other information:

Things to test here / in REopt.jl:

• Net metering
• Net billing
• Net metering and net billing combined
• Multiple/probabilistic outage inputs with and without min_resil_timesteps
• Scenarios that we think could return feasible on first run and infeasible on last (after MPC)
• Test what happens with multiple PVs and add a warning or error message

[adfarth]

Generally curious if running hourly is in line with available versions of this capability in BESS dispatch software, or if less frequent should be considered too?

[Bill-Becker]

@lixiangk1 @adfarth the new feature branch PR process is to merge directly into master instead of develop (I updated this PR to do that). We're going to make the develop branch obsolete/irrelevant, as it kind of has been for a while now other than adding a step/branch for feature branches to converge into. We can now deploy feature branches to the staging server with snapshots of the production database merged into that to test database compatibility, in parallel to testing new features. This should enable rigorous testing on the feature branch until it's ready for production (master).

Relevant PRs with a description of deploy updates:

• Move to GitHub Actions for deployments; other deployment updates/cleanup #714
• PostgreSQL v18 updates; Database restores #720

I will work on updating our Wiki/README/etc documentation with this new process.

[Bill-Becker]

Looks great! I like the separate files for MPC and pre-sizing if sizes are not input.

[Copilot]

Pull request overview

Copilot reviewed 20 out of 21 changed files in this pull request and generated no new comments.

Suppressed comments (8)

CHANGELOG.md:37

• This changelog entry has a typo (“udpates”) and “timeseries” should be “time series” for readability/consistency.

## fixed-soc
### Minor udpates
#### Added
- Add **ElectricStorage** inputs field **fixed_soc_series_fraction** and  **fixed_soc_series_fraction_tolerance** to allow users to fix the SOC timeseries within a chosen absolute tolerance

julia_src/http.jl:1

• The first line contains a UTF-8 BOM/zero-width character before using, which can cause hard-to-diagnose parsing or linting issues in Julia tooling. Remove the hidden character so the file starts with plain ASCII.

using HTTP, JSON, JuMP

reoptjl/validators.py:370

• Use is None / getattr for None checks instead of __getattribute__(...) == None to avoid non-idiomatic comparisons and ensure consistent behavior (this file already uses is None elsewhere).

            if self.models["ElectricStorage"].__getattribute__("soc_min_fraction") == None:
                if self.models["ElectricStorage"].dispatch_strategy=="backup":
                    self.models["ElectricStorage"].soc_min_fraction = 0.8
                else:
                    self.models["ElectricStorage"].soc_min_fraction = 0.2

reoptjl/validators.py:379

• fixed_soc_series_fraction is treated as “provided” only when len(...) > 1, which skips validation for a single-value array (and will also error if the attribute is ever None). If any non-empty series is provided, it should be cleaned/validated.

            if len(self.models["ElectricStorage"].__getattribute__("fixed_soc_series_fraction")) > 1:
                self.clean_time_series("ElectricStorage", "fixed_soc_series_fraction")

reoptjl/models.py:3782

• The fixed_soc_series_fraction help text is missing a space due to adjacent string concatenation (renders as “values providedhere ...”).

        help_text=("If provided, SOC (as fraction of total energy capacity) will not be optimized and will instead be fixed to the values provided"
                   "here +- the absolute fixed_soc_series_fraction_tolerance. Must be an array of values 0-1 with length equal to 8760*time_steps_per_hour.")

CHANGELOG.md:32

• This changelog entry has typos (“udpates”) and references an input field name (dispatch_options) that doesn’t exist in the codebase (the model/input uses dispatch_strategy).

This issue also appears on line 34 of the same file.

## heuristic-dispatch-option
### Minor udpates
#### Added
- Add **ElectricStorage** inputs field **dispatch_options** with heuristic options

reoptjl/custom_table_config.py:810

• This BAU lookup key (outputs.ElectricStorage.storage_to_grid_series_kw_bau) doesn’t exist anywhere else in the repo, so this will always fall back to the default value (0) and can be misleading in the comparison table. If BAU export isn’t supported for storage yet, prefer an explicit blank BAU value.

        "bau_value"     : lambda df: safe_get(df, "outputs.ElectricStorage.storage_to_grid_series_kw_bau"),

reoptjl/test/test_job_endpoint.py:138

• Most of the assertions/execution that would validate successful MPC/heuristic dispatch behavior are commented out, so this test currently only checks the off-grid error case. That leaves the new dispatch path largely untested.

        # resp = self.api_client.post('/v3/job/', format='json', data=post)
        # self.assertHttpCreated(resp)
        # r = json.loads(resp.content)
        # run_uuid = r.get('run_uuid')

[lixiangk1]

Generally curious if running hourly is in line with available versions of this capability in BESS dispatch software, or if less frequent should be considered too?

This seems to be common as far as I can tell, and what SAM does for BTM dispatch. Once we start considering techs like hydrogen and using longer horizons to incentivize LDES to dispatch, then might be helpful to start testing different horizons and update frequencies to see how they impact dispatch/costs/solve time.