example script: MethodError: no method matching fieldnames(::PSA.network_mutable)

[fleimgruber]

Given this example script (modified for local development)

# Cf. PyPSA example https://github.com/PyPSA/PyPSA/tree/master/examples/ac-dc-meshed

import PSA

using Clp

network = PSA.import_network("c:/Users/LeimgruberF/dev/PyPSA/examples/ac-dc-meshed/ac-dc-data/")

solver = ClpSolver()

m = PSA.lopf(network, solver)

print(m.objVal)

print(network.generators_t["p"])

and using Julia 1.5.1 I see this traceback:

ERROR: LoadError: MethodError: no method matching fieldnames(::PSA.network_mutable)
Closest candidates are:
  fieldnames(::Core.TypeofBottom) at reflection.jl:175
  fieldnames(::Type{var"#s9"} where var"#s9"<:Tuple) at reflection.jl:177
  fieldnames(::DataType) at reflection.jl:172
  ...
Stacktrace:
 [1] static_components(::PSA.network_mutable) at C:\Users\LeimgruberF\dev\PSA.jl\src\auxilliaries.jl:19
 [2] import_network(::String) at C:\Users\LeimgruberF\dev\PSA.jl\src\PSA.jl:147
 [3] top-level scope at C:\Users\LeimgruberF\dev\PSA.jl\examples\ac-dc-lopf.jl:8
 [4] include(::Function, ::Module, ::String) at .\Base.jl:380
 [5] include(::Module, ::String) at .\Base.jl:368
 [6] exec_options(::Base.JLOptions) at .\client.jl:296
 [7] _start() at .\client.jl:506
in expression starting at C:\Users\LeimgruberF\dev\PSA.jl\examples\ac-dc-lopf.jl:8

I am not sure whether this is due to changes in Julia internals (Julia 1.0 was released August 8th 2018, the latest commit on master is from June 15th 2018) or due to changes in PyPSA CSV file format. @nworbmot could you please give me a quick heads up on where you suspect the root cause, I would then try to work it out.

[fleimgruber]

FYI, I am just working through upgrading the code to Julia v1.5+ and create a PR for it.

[FabianHofmann]

hey @fleimgruber, thanks for your input. As you probably noticed, the repo is kind of out-of-date. Since pypsa allows to perform the lopf withtout pyomo, the solving process is very fast and the relative advantages of the julia code vanished. But we are still happy for any contribution.

[fleimgruber]

@FabianHofmann thanks for checking back. I read up on the reasons and motivation for PSA.jl and the nomopyomo approach in PyPSA. If speed and all-in-Python are the main objectives, then fair enough, Julia does not add much. But for benchmarking, validation and also for readability (IMHO, in this regard JuMP is superior to Pyomo and to most hand-crafted frameworks I have seen - without a deeper look into the nomopyomo code, just a guess) I think PSA.jl might still be valuable. I would not see it as a "vs." or replacement, more a companion project.

Please see also #4.

[fleimgruber]

I just noticed #2. Was there any progress on it? It looks like a good roadmap, but development on https://github.com/PyPSA/EnergyModels.jl has also ceased it seems.