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 _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
