Skip to content

chore: expose dynamic network propertys#1249

Merged
lkstrp merged 6 commits intoPyPSA:masterfrom
lkstrp:network-propertys
Jun 19, 2025
Merged

chore: expose dynamic network propertys#1249
lkstrp merged 6 commits intoPyPSA:masterfrom
lkstrp:network-propertys

Conversation

@lkstrp
Copy link
Copy Markdown
Member

@lkstrp lkstrp commented Jun 10, 2025

Changes proposed in this Pull Request

  • Uses internal properties for network data attribute
    • n.model/n.objective/n.objective_constant/n.pypsa_version are read-only without a setter
    • n.nameis also wrapped around but can be set
    • This is one more step to a NetworkData class which will separate logic from data, which will make things more stable
  • Allows to expose them to API/ docs and they are not just hidden attributes
  • I guess there is no use case why someone would need to set objective or objective_constant manually?
  • Removes io backwards compatibility for v0.13.1 and v0.18.0

Checklist

  • Code changes are sufficiently documented; i.e. new functions contain docstrings and further explanations may be given in doc.
  • Unit tests for new features were added (if applicable).
  • I consent to the release of this PR's code under the MIT license.

@lkstrp lkstrp requested a review from fneum June 10, 2025 15:01
@fneum
Copy link
Copy Markdown
Member

fneum commented Jun 11, 2025

All good about exposure of network attributes.

This is one more step to a NetworkData class which will separate logic from data, which will make things more stable.

Not quite sure what a NetworkData class would improve. Let's discuss when I'm back.

I guess there is no use case why someone would need to set objective or objective_constant manually?

No, it wouldn't be good style.

Removes io backwards compatibility for v0.13.1 and v0.18.0

Does it hurt much to keep the compatibility? Would allow import of archived networks with newer PyPSA versions.

@lkstrp
Copy link
Copy Markdown
Member Author

lkstrp commented Jun 11, 2025

Does it hurt much to keep the compatibility? Would allow import of archived networks with newer PyPSA versions.

It does not, I added 0.18.0 again. 0.13.1 is only relevant for HDF5, too. We don't test on old network versions, so we can't be sure if this still works with the current dependencies. With this release, we save the nc and csv versions for every release, so we can test them from here. But if there is a need to load older versions from an archive, we should add tests for those as well

@lkstrp lkstrp enabled auto-merge (squash) June 11, 2025 11:56
@lkstrp lkstrp disabled auto-merge June 11, 2025 12:01
@Irieo
Copy link
Copy Markdown
Contributor

Irieo commented Jun 13, 2025

(@lkstrp I’m afraid I’m thinking about this suggestion without enough context.) That said, in general there are plenty of use cases where it’s useful to work with the objective term (and more broadly n.model) manually:

  • You might want to solve an optimization problem that isn’t (yet) supported by PyPSA, but still benefit from everything PyPSA provides. For example, a stochastic problem: https://resilient-project.github.io/pypsa-workshop-202505/pypsa-stochastic.html

  • You may want to implement a specific subclass of stochastic problems. For example, assigning higher weights to costly branches for risk aversion. In such cases, you would need to formulate your own objective.

  • In other cases, users might rely on PyPSA to formulate the objective for a complex, multi-component system, but then patch it. e.g. by appending it with a penalty term for res curtailment.

  • similar argument extends to constraints in n.model

@lkstrp lkstrp merged commit f541b98 into PyPSA:master Jun 19, 2025
20 of 23 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants