Update TulipaEnergyModel requirement from 0.21.0 to 0.21.0, 0.22 in /test

[dependabot]

Updates the requirements on TulipaEnergyModel to permit the latest version.

Release notes

Sourced from TulipaEnergyModel's releases.

v0.22.0

TulipaEnergyModel v0.22.0

Diff since v0.21.0

Breaking changes

• Reworked model parameters. The ModelParameters Julia struct and EnergyProblem(connection; model_parameters_file=...) path were removed. Model parameters now live in the model_parameters table, with defaults populated during data preparation.

• Renamed/refactored investment method configuration. The old asset.investment_method field was replaced by asset.vintage_method, with current values:

  • aggregated
  • compact_profiles
  • compact_efficiencies

• Changed storage-energy investment configuration. storage_method_energy is now a string option instead of a boolean:

  • none
  • optimize_storage_capacity
  • use_fixed_energy_to_power_ratio

• Changed unit commitment configuration. unit_commitment is now the method selector with values such as none, basic, and 3var; the old separate unit_commitment_method field was removed.

• Reworked investment-group inputs. The old group_asset table and asset.investment_group column were replaced by explicit tables:

  • investment_group_asset
  • investment_group_asset_membership

• Renamed storage “over-clustered year” terminology to “inter-period”. This affects internal/output names such as var_storage_level_inter_period, cons_balance_storage_inter_period, and related dual outputs.

• Assets with min_operating_point > 0 can now receive minimum flow constraints even when unit_commitment = "none". Existing models that relied on min_operating_point being inactive without unit commitment may solve differently.

Added

• Added Conditional Value at Risk support for stochastic optimization, including:

  • model parameters risk_aversion_weight_lambda and risk_aversion_confidence_level_alpha
  • Value at Risk threshold variable mu
  • tail excess slack variable xi
  • scenario tail excess constraints
  • CVaR objective contribution

• Added objective cost breakdown support through obj_breakdown, with documentation for extracting more detailed objective components.

• Added validation for consistency between investable settings and asset_both data.

• Added support for minimum flow limits without requiring full unit commitment.

• Added schema-derived documentation for mandatory input columns.

Changed

• Refactored objective construction into src/objectives/, with one file per objective term.

... (truncated)

Commits

• 132e469 Release 0.22.0
• 1b08bac Update coverage recommendation in docs (#1622)
• 1664649 Rename investment group input tables to explicit investment_* names (#1621)
• 25a0751 Restructure API reference and align docs checks with public API (#1620)
• f0af90c chore: 🤖 pre-commit update (#1616)
• 4f8736c Bump codecov/codecov-action from 6 to 7 (#1617)
• d1baf43 Update OrderedCollections requirement from 1 to 1, 2.0 (#1618)
• a0e5247 Update OrderedCollections requirement from 1 to 1, 2.0 in /docs (#1619)
• 4604cb5 Add min flow limit without unit commitment constraint (#1614)
• 2caf0d4 chore: 🤖 pre-commit update (#1613)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

Downstream Testing Results

The table below helps prevent breakage in downstream packages.
There are four possible results: Pass, Fail, Version Mismatch, and Error.

• Pass: this PR does not break the downstream package.
• Fail: this PR breaks the downstream package.
• Version Mismatch: the version in this PR is not accepted by the compat bounds of the downstream package (in the given version).
• Error: Something else went wrong outside of the tests (possibly workflow related).

If all packages Pass

In this case, it is safe to release a new bugfix version (e.g., from 1.2.3 to 1.2.4) or minor version (e.g., from 0.1.5 to 0.1.6 or from 1.2.3 to 1.3.0).

If some packages Fail and that's not expected

In this case, this PR has some issue that needs to be investigated.
Check the tests log, or try to reproduce and fix the error locally:

# Go to the downstream package folder
pkg> activate path/to/this/package
pkg> update
pkg> test

Make sure that the /path/to/this/package has this package with the PR branch checked out.

After fixing the error, you should have a Pass state, or eventually you might conclude that this Fail is expected.

If some packages Fail and that is expected

In this case, you're introducing changes in this PR that will inevitably break some package.
This is a BREAKING CHANGE, and thus you will need to release a new version of this package.
One recommendation would be to do it now, introducing a new commit with the update of the version in the Project.toml.
This should be a major update (e.g., from 0.1.5 to 0.2.0 or from 1.2.3 to 2.0.0).

If you do that, then most packages or all packages will have a Version Mismatch status.

If you have Version Mismatch

Any package with a Version Mismatch has compat bounds that don't include this version of this package.
This is not an error, just a warning, and it can happen either because the downstream package has not had its compat updated yet (consider using dependabot), or that this PR introduces a version change.

Disclaimer: The Version Mismatch might be wrong, because it's a catch-all over the develop and build steps of the workflow.
If the mismatch is completely unexpected, check the logs.

If you have an Error

You have to investigate what happened. This is a catch-all for any other issue that appears in the workflow.

Package name	Result