Solidify some interface for create_system

[cmhyett]

Look to MethodOfLines.jl for inspiration. What function do they call to obtain a ODEProblem?

• Implement abstract/types
• Decide what types are inputs, what are outputs?
• Do we allow user to choose discretization dx,dt? Is it an input? Is it inherited from the method?

[cmhyett]

MethodOfLines first creates a PDESystem, and a MOLFiniteDifference discretization that are then combined into a SciMLProblem

We need to perform an additional step, which is to link the internal PDEs with BCs at nodes.

I think we can follow MoL and simply add a discretizer type, and then specialize the discretize method for our discretizer.

How do we specialize equations for different node types though? Metadata! If you can supply boundary conditions for the node types (one per node type), and then list which nodes belong to which type, the discretizer can handle it downstream.

NetworkDiscretizer <: AbstractEquationSystemDiscretization should have some common fields as the MoLFiniteDifference, but also include the node types and the graph representation.

[cmhyett]

Upon further reflection, stuffing everything into metadata seems laborious, and we ought to rather implement "factories" for the different network components.

The tough part is determining how to create the factories so that we can instantiate the objects and then connect them later...especially considering there isn't a guaranteed number of connections per node..or can we just build this into the factory? Something like:

function flux_node_factory(node_num, num_incoming_edges, num_outgoing_edges)
    function instantiate_and_connect(...)
        ...
    end
    return FluxNode(..., instantiate_and_connect);
end

Really comes down to interfaces - what do we know when we call a factory, what do we expect when we call instantiate_and_connect?

[cmhyett]

This seems to work...

julia> function flux_node_factory(N)
           @variables tmp_vars[1:N]
           function connect(eq, vars)
               @assert length(vars) == N
               substitute(eq, Dict([tmp_vars[i]=>vars[i] for i in 1:length(vars)]...))
           end
           return connect, Symbolics.scalarize(sum(tmp_vars) ~ 0)
       end

The symbolic variables defined inside flux_node_factory become object members of the function, somehow preserved in construction of the function.

This is nice though, as we can make factories that themselves construct objects with programmatically defined @variable members, and provide "connection" mechanisms that handle tying these objects together.

[cmhyett]

From MTK, a "component" decay is created, and decay1 is an ODESystem

function decay(; name)
    @parameters a
    @variables x(t) f(t)
    ODESystem([
            D(x) ~ -a * x + f
        ], t;
        name = name)
end
@named decay1 = decay()

We can ask for edge equations, and have components that return PDESystems

function edge_pde(; name, e::Edge, eqs)
    @parameters get_metadata(e, ...)
    @variables get_dvs(eqs)
    ....
    PDESystem(eqs, [], ...)
end

These PDESystems can be discretized, and queried for dependent variables, allowing their connection at a later time.