decouple GraphStructure from other modules through accessors

[hexaeder]

this is an resolves #58. Not meant for merging right now.

[lindnemi]

Looks good!

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (dev-0.5@95d7a79). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             dev-0.5      #59   +/-   ##
==========================================
  Coverage           ?   67.46%           
==========================================
  Files              ?        7           
  Lines              ?      375           
  Branches           ?        0           
==========================================
  Hits               ?      253           
  Misses             ?      122           
  Partials           ?        0           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 95d7a79...2147fe2. Read the comment docs.

[lindnemi]

Yes, PD uses StaticEdgeFunction, so we have to either rewrite that part of PD or get rid of the allocations again: https://github.com/JuliaEnergy/PowerDynamics.jl/search?q=StaticEdgeFunction.

Btw, it looks like it was allocating before, since it returns a tuple. Did allocations increase?

[hexaeder]

Tuples are of known length and size and can be stack allocated. Before it was returning a tuple containing of two pointers to heap allocatet Arrays e_s_v and e_s_d which have been allocated before therefore non allocating function call.

Now it is composing a tuple (non allocating) of to pointers but the pointers refer to arrays which will be created in the function call through these iterators (allocating). But the PD packages doesn't seem to be interested in the full arrays anyway (see my comment)

[hexaeder]

Should not be merged yet. I'll try to decouple the GraphStructure from the rest of the package. As discussed earlier it would be nice to change the module (for example switching to the GraphDataBuffer-design) without having to touch a lot of code outside of NetworkStructures.jl.

[lindnemi]

Nice to see tests for the modules and for allocations. Did you do the benchmarks yet?

Also I think GetGD and GetGS are abusing multiple dispatch and could be functions instead of types. For what reason were they chosen to be types @FHell ?

[hexaeder]

Yes, no perfomance hit compared to master (i think everything boils down to the same machine code anyway due to inlining).

Also I think GetGD and GetGS are abusing multiple dispatch and could be functions instead of types. For what reason were they chosen to be types @FHell ?

I guess because of the type of nd

nd = network_dynamics(nd_diffusion_vertex, nd_diffusion_edge, g)
typeof(nd) ## isa ODEFunction
typeof(nd.f) ## isa nd_ODE_Static

The ODEFunction forwards all function calls to its .f field. In order to put in in a function one would have to define a new method on the ODEFunction object.

function getGD(nd::ODEFunction{true, T}) where T<:nd_ODE_Static
    nd.f.graph_data
end

(in case you are wondering, the first type parameter true for ODEFunctions is whether it is in place.)

I think this not high priority but certainly something to think about (#35).