Add min flow limit without unit commitment constraint

[datejada]

The implementation includes:

• SQL: Two new cons_min_output_flow_without_unit_commitment_* tables in create-constraints.sql
• Registration: Keys added to create.jl
• Constraint logic: New file min-output-flow.jl with aggregated and compact vintage method variants
• Expression attachment: Loop added in model-preparation.jl
• Add to the Model: @timeit call added in create-model.jl
• Tests: test-constraint-min-output-flow.jl
• Update docs: update the formulation, how-to, and outputs sections in the docs.

For the test, different edge cases are included:

• producer, aggregated, non-investable
• producer, aggregated, investable
• conversion asset, aggregated
• CO2 output with zero capacity coefficient
• compact profiles vintage method
• unit commitment asset is excluded
• zero min operating point is excluded
• full solve integration test

Related issues

Closes #1597

Checklist

• I am following the contributing guidelines
• Tests are passing
• Lint workflow is passing
• Docs were updated and workflow is passing

[github-actions]

🤖 CompareMPS report

✅ MPS files match

[github-actions]

Benchmark Results

	2caf0d4...	688ef52...	2caf0d4... / 688ef52...
higher_level/EU/create_model	47 ± 1.7 s	45.8 ± 2 s	1.03 ± 0.058
higher_level/EU/input_and_constructor	11.4 ± 0.12 s	11.5 ± 0.22 s	0.992 ± 0.021
lower_level/EU/constraints	0.538 ± 0.0052 s	0.535 ± 0.0089 s	1.01 ± 0.019
lower_level/EU/create_internal_tables	10.2 ± 0.47 s	9.92 ± 0.25 s	1.03 ± 0.054
lower_level/EU/create_model	49.3 ± 0.51 s	47.2 ± 1 s	1.04 ± 0.025
lower_level/EU/profiles	0.425 ± 0.036 s	0.419 ± 0.012 s	1.01 ± 0.091
lower_level/EU/variables	0.495 ± 0.01 s	0.489 ± 0.0072 s	1.01 ± 0.026
time_to_load	2.57 ± 0.016 s	2.57 ± 0.026 s	0.997 ± 0.012

	2caf0d4...	688ef52...	2caf0d4... / 688ef52...
higher_level/EU/create_model	0.244 G allocs: 13.9 GB	0.244 G allocs: 13.9 GB	1
higher_level/EU/input_and_constructor	0.0413 G allocs: 1.59 GB	0.0413 G allocs: 1.59 GB	1
lower_level/EU/constraints	3.84 k allocs: 0.177 MB	4.04 k allocs: 0.187 MB	0.949
lower_level/EU/create_internal_tables	0.0409 G allocs: 1.56 GB	0.0409 G allocs: 1.56 GB	1
lower_level/EU/create_model	0.244 G allocs: 13.9 GB	0.244 G allocs: 13.9 GB	1
lower_level/EU/profiles	0.415 M allocs: 26 MB	0.415 M allocs: 26 MB	1
lower_level/EU/variables	0.764 k allocs: 0.0371 MB	0.764 k allocs: 0.0371 MB	1
time_to_load	0.145 k allocs: 11 kB	0.145 k allocs: 11 kB	1

Benchmark Plots

A plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR.
Go to "Actions"->"Benchmark a pull request"->[the most recent run]->"Artifacts" (at the bottom).

[github-actions]

📝 Check the documentation preview: https://tulipaenergy.github.io/TulipaEnergyModel.jl/previews/PR1614

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.61%. Comparing base (2caf0d4) to head (688ef52).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1614      +/-   ##
==========================================
+ Coverage   98.60%   98.61%   +0.01%     
==========================================
  Files          55       56       +1     
  Lines        1862     1880      +18     
==========================================
+ Hits         1836     1854      +18     
  Misses         26       26              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[datejada]

@abelsiqueira Sorry to bother you. Since Ni is on paternity leave, would you mind having a look at this PR? It is a simple one, since it adds constraints; it doesn't change any of the current logic or structure. The benchmark shows basically no impact in the EU case study, which is good and expected (since there are no constraints like this there). Of course, there is always the question of how these new constraints scale, but since this one doesn't change any current logic and follows the same pattern as other constraints, it should be fine. Until we take benchmarking all the different constraints more seriously (which I think should be the way).

Anyway, please let me know your comments, and if you don't have time for this, it is okay. I will see what we can do internally.

As always, the changes read better by commit.

Thanks!

Diego

[abelsiqueira]

Hi @datejada, sorry for the delay on answering, and thanks for pinging on slack, otherwise I'd miss it.

I took a quick look.
The constraints tables and objects seems to be correct. I haven't checked the mathematical formulation in the docs or the issue to compare to what is implemented, since it's beyond my expertise.
I took a quick look at the tests, and they seem to capture the relevant main cases. I haven't evaluated corner cases.
The benchmark speed changed are well within our expected variation. Since you mentioned that EU doesn't have these constraints, I think the memory changes are due to either just creating small (order of Kb) variables, or type instabilities that we still can't avoid.

Let me know if this review is enough.

I made small suggestions that don't affect correctness, so it's approved (with the caveats above)

[datejada]

@abelsiqueira, thanks for the comments and suggestions. I have included them in the latest commit in this PR.