WIP: Taking PSA.jl to the next level

[fneum]

• more robust accessing of network data (potentially with NamedTuples)
• separate functions for adding variables and constraints; more modularity
• nice registration of variables and constraints of JuMP model
• switch to Julia v1.1 and JuMP v0.19 with MOI
• better documentation with Documenter.jl and stickers
• provide REQUIRE and environment
• write test cases
• adapt .nc import and output functionality from PSA.jl#pathway_optimization
• add fix for getting cycle basis for multigraphs from PSA.jl#pathway_optimization
• PowerModels interface for network formulations
• add cycle, kirchhoff and ptdf formulation inheriting from PowerModels.DCPlosslessForm

Potential features:

• Model building as StructJuMP
• warmstart in iterative linear optimal power flow

[coroa]

Comments on the above:

• named tuples are built into core julia since 0.7

  t = (min=0.5, max=1.0)
  t.min

• REQUIRE has been superseeded by an environment in the top-level directory for each Package, defined by a Project.toml file. The relevant docs are from the Pkg.jl package. In a nutshell, you execute ]activate . in the root directory of your package and add dependencies, while compatibility requirements have to be added manually as described in the Compat docs. Project.toml should be tracked by the git repo. It might make sense to watch the Pkg.jl talk at JuliaCon2018 by Carlsson and Karpinski.

[coroa]

Side note: I decided to continue the development on EnergyModels. If I can provide you an easy example on a possible merge strategy with PSA.jl would you two be interested to try to combine the three code-bases? Perhaps we could meet in Karlsruhe for a couple of days around mid-June to make that happen? -> I'll write you two a mail on Monday!

[fneum]

Yes, I think that makes sense and I would be very interested in participating in it!

Features, I would love to have included:

• PowerModels interface for network flow formulations
• add cycle, kirchhoff and ptdf formulation as inheriting from PowerModels.DCPlosslessForm
• an in-built iterative lopf function (using the heuristics, maybe with warmstart capabilities, e.g. with JuMP.set_coefficient)
• (maybe keeping a door open to build the model as a StructJuMP model in the future)

[FabianHofmann]

I totally agree! I think it's also worthwhile to ensure compatibility with original pypsa networks (even if they have then less features in the resulting energymodels/psa, or some values have to be defaulted). Perhaps a good way to go would be similar to the override_components function in pypsa. Therefore ports from one to the other could be easily provided.

[coroa]

Great to hear! I started issues on the EnergyModels.jl tracker.

[coroa]

I totally agree! I think it's also worthwhile to ensure compatibility with original pypsa networks (even if they have then less features in the resulting energymodels/psa, or some values have to be defaulted). Perhaps a good way to go would be similar to the override_components function in pypsa. Therefore ports from one to the other could be easily provided.

It's not the right place to discuss this, I know. But I just now passed over it again and wanted to clear something up. EnergyModels was built on the premise that there is NO fixed set of components. All components are added by:

• Creating a new type that derives from Component or more particularly from OnePort, ActiveBranch or PassiveBranch
• Defining functions nodalbalance, cost and build for them, and
• Calling addelement on the type with a CSV file describing its attributes, this makes sure, the methods around the PypsaNcData type know which type it needs to add to the network

That's it. All components are defined in this way! So you do not need any override_components, it's implicit in the design.