[Gnucap-devel] coupling (was: Re: Qucs, Gnucap, and gsoc)

[Felix Salfelder]

On Sat, Mar 25, 2017 at 08:48:50AM +0000, Richard Crozier wrote:
> Thanks, this second one [state space inspection] sounds a lot more
> like what I would be interested in. In my case, I want to do things
> like run a finite element simulation of an electrical machine which
> provides the back emf, while the circuit solver then does the power
> electronics simulation, but perhaps also being supplied with a control
> signal from matlab. In other cases I just want a loosely coupled
> electrical system simulation that interacts with a larger system
> simulation (renewable energy systems in my case).

to me that sounds much like gnucap-jack. "just" replace jackd with a
non-realtime simulation interconnect/sync daemon. if that daemon exists
(plus a non-patented standard protocol based on a useful abstraction),
we likely want component plugins that connect to it. or just provide
that daemon functionality.

in the other case, it might be best to use custom component plugins that
talk to your specific FEM simulation. using sockets or shm will be one
such possibilty. alternatively, spice-wrapper.cc demonstrates how to
directly instanciate component models that were never meant to run in
gnucap. there is no limit on what is "behind" a component...

NB: there is also "extpwl". some way to externally read/control
probes/sources in an attempt to (not only?) connect (link? talk?) to
icarus vvp. i have never seen it fully working though.

> This sockets scheme sounds similar to what another library I'm using does
> (MBDyn, a multibody dynamics library).

let me explain a bit more. tl;dr; things are possible, make sure to get
it right/fit your needs etc.

the "sock" command plugin provides a way to take control over the
simulation rather than a way to add a component to a circuit. the
protocol has afaik never been documented much. sock implements "opcodes"
that resemble what you can already to in gnucap interactive cli (via
"commands"). there are a few more opcodes such as "set charge
contraints", "find consistent operating points" or "give direct (read)
access to the internal ac/dc matrices". it's all aligned to the protocol
that entangles these steps in various ways.

in contrast to what (i think) you need, the purpose of controlling
sources from "the outside" in sock has never been in order to add a
component to the circuit. rather, it is done to stimulate a circuit at
its input ports.

for some (technical) reasons, "sock" has not been implemented as a set
of standalone interactive commands in the first place. a rewrite would
very likely be in terms of a language plugin (implementing socket and
binary i/o) + the extra commands doing (potentially) useful stuff
independently.

cheers/hth
felix