be able to simulate different '.asc' files in parallel

[mvanriet]

Now, SimCommander() reads 1 schematic.
You can manipulate this schematic and make a lot of simulations of these variations in parallel.
However, you cannot (it seems), simulate different files in parallel.

I think it can be made possible by not making SimCommander() a derivative of SpiceEditor, and make it a Singleton class (  Singleton Pattern )

Code would look something like this :

sim = SimRunner(output_dir='./sim')

circuit1 = SpiceEditor('test1.asc')
sim.run(circuit1, 'test1A.net')

ciruit1.set_component_value('R1', '1K')
sim.run(circuit1, 'test1B.net')

circuit2 = SpiceEditor('test2.asc')
circuit2.run('test2.net')         # equivalent to sim.run(circuit2,'test2.net')

sim.wait_completion()

The SpiceEditor run function would do this :

  def run( ..................... ):
       runner = SimRunner()
       runner.run( ...................)

So there will always be only 1 simcommander object, and you can simulate any number of circuits, derived from the same .asc file or not. To keep things backwards compatible, the SimCommander() class would still exist as a derivative of SpiceEditor and SimRunner.

[nunobrum]

This will implemented in a new branch called dev_space
https://github.com/nunobrum/PyLTSpice/tree/dev_space

[nunobrum]

While trying to implement this, realizing structural issue.
It would be better if the SpiceEditor class would be agnostic to the Spice tool used.
Implementing the proposed Singleton pattern proposed would violate this principle.
My counterproposal is as follows

sim = SimRunner(output_dir='./sim')
circuit1 = SpiceEditor(sim.create_netlist('test1.asc'))
# make changes to the circuit using circuit1
sim.run(circuit1, 'test1A.net')  # Netlist as output is optional

if starting directly by a netlist, then this step is not needed.

sim = SimRunner(output_dir='./sim')
circuit1 = SpiceEditor('test1.net')
# make changes to the circuit using circuit1
sim.run(circuit1)

In the future, I would like to have a class that can edit directly .ASC files

sim = SimRunner(output_dir='./sim')
schematic = AscEditor('test1.net')
# make changes to the circuit using schematic. AscEditor and SpiceEditor shall have the same interface.
sim.run(schematic)

[mvanriet]

Supporting different simulators is possible too :

You have the SimRunner singleton, however it is just a singleton.
Create an LTSpiceRunner class (which is mostly the present SimCommander).
Upon instantiation, it sets itself as the SimRunner singleton.

sim = LTSpiceRunner ()
circuit1 = SpiceEditor('test1.net')
circuit1.run()
sim.wait_completion()

Create another class NGSpiceRunner that supports Ngspice.
It has the same interface functions.

sim = NGSpiceRunner ()
circuit2 = SpiceEditor('test2.net')
circuit2.run()
sim.wait_completion()

Of course, you cannot use both Ngspice and LTspice in the same program, but that seems like an acceptable limitation.
Note that 'sim' is not a global variable. The SpiceEditor circuits get the simulator object by using the singleton.

You could support LTSpice .asc files directly in SpiceEditor, or you derive a class from AscEditor that supports reading .asc files.

sim = LTSpiceRunner ()
circuit3 = AscEditor('test3.asc')
circuit3.run()
sim.wait_completion()

Note that a SpiceEditor circuit object knows its own .net filename, so the user doesn't really need to specify it when doing circuit.run(). It is still useful as a parameter when loading a circuit and doing different simulations on that circuit.

And you can do sim.run(circuit1) or sim.run(circuit1, 'circuit1_res1K.net') as well if you like; it is equivalent.

[mvanriet]

The only difference with your proposal, is that this would allow you to write circuit1.run(), instead of having to write sim.run(circuit1).

I agree that the agnostic approach is 'cleaner' from an architectural point of view.
But circuit.run() may be handy if you have a lot of circuit manipulation code, and the 'sim' variable may in a totally different place.

Alternative is to make run() an everything else for LTSpiceRunner and NgspiceRunner a classmethod.
Then you wouldn't have to instantiate a sim variable.

from PyLTSpice import NGSpice, SpiceEditor

NGSpice.set( tempdir='./sim' )

circuit4 = SpiceEditor('test4.net')
NGSpice.run( circuit4 )

NGSpice.wait_completion()

In the beginning of any classmethod, you should then first call a function to create a NGSpice or LTSpice object if necessary. It is created on the first call and stored in a class member. Not created again in the next calls.

This way, you could even run NGSpice and LTSpice simulators side by side :-)

[nunobrum]

Presently SimCommander needs to be object instances. It has lot of supporting properties.
Maybe a Client-Server approach could alleviate this need, but, only once we start diving into details that we can see the options we have.
Let's keep this idea in mind for the time being. My feeling is that we will need to keep track of pending tasks and server pools and doing this with static class may be complicated.

[mvanriet]

Don't underestimate the power of Python :-)

You can have a class SpiceRunner with class methods for running simulations and waiting for completion.
Then you can have different simulation engines, which derive from this class.
But these engines can be normal objects, just like SimCommander.
And you can have different kinds of circuit readers/editors, that don't have to know about any of the different simulation engines.

Please see the demonstration below that I made.
Simulations test1 - test2 - test3 - test4 demonstrate everything from simple to complex.

• github.com/mvanriet/PyLTSpice_dev/simrunner

It has all the features described above.
The SpiceRunner class with the singleton features is a bit more advanced Python.
But the simulation engines are just ordinary classes, with 10 extra lines to make it use the singleton class.

And for the user, it is really simple to use.

[nunobrum]

I see you master it :-) I'll not underestimate you.

Having just one object that acts as a gateway has some advantages.
It has also some drawbacks that I would like to bring to your attention.

• If you have two installations on your computer in different places (for example the new LTspice version that ADI just released), and want to compare the results of one with another.
• If you have more than one SpiceServer machines. Even if you treat everything with one class which implements usage leveling, you might want to have two different pools.

Maybe there is a way to integrated this at class level, but, does it really simplify things?

[mvanriet]

For having two different versions of a simulator in different locations :

Just use a method like setLTSpiceRunCommand (present in SimCommander). The different spice engines (LTSpice, NGSpice, ...) have only a few common methods (like run() and wait_completion() ), but they can have any number of engine-specific methods, like for setting the location of the engine, adding command line switches, ...

So it is really no different from the present SimCommander class. Except that it automatically instantiates itself.

For the settings you could also use a common 'set' method, where each engine can have different engine-specific settings, e.g.
LTSpice.set( ltspicedir="c:/programs/ltspice2 ) . But having dedicated methods could be more user-friendly.

[mvanriet]

For having a simulation server pool : the RemoteSpice object was just for illustration purposes.
With a server pool, it depends on how you discover or keep track of all your servers. A simple example :

from PyLTSpice import SpiceCircuit, ServerPool

ServerPool.set( servers="server_list.ini" )

test1 = SpiceCircuit('test1.net')
test1.run()
test2 = SpiceCircuit('test2.net')
test2.run()

ServerPool.wait_completion()

Note that all the code not related to the spice engine just stays the same.
So you can make a new spice engine, or make a different circuit editor, and everything will work nicely together.
The fact that all these classes don't need to know anything about each other really simplifies things.

Imagine that you have a class that reads a PCB and looks at the type and location of all decoupling capacitors for resonance analysis (see Impedance of high-speed PCB power. ) It could then make a network representing the interaction between the decoupling capacitors.
So this would be a totally different and very complicated kind of a SpiceCircuit class.
Yet all it has to do for starting the simulations is write out .net files and call SpiceRunner.run().

[nunobrum]

Let's start with the design approach of using class only representations of simulators. I'm ready to give it a go, but, to be honest...
I'm not 100% sure that everything can be done with class and static methods only without having to stretch a bit.

One thing I don't understand on your example above, is how test1.run() knows which simulator to use. There must be a way to bind the two together.

Anyway, we have time to discuss this, test and make it proper on my 'dev_space'. Meanwhile, don't be surprised with the commit I'll make later today directly to the 'master'. I'm introducing a quick fix for supporting the new LTspice version that came up just this week.

This quick fix doesn't implement a class only representation of the simulator, or implements the singleton structure being discussed here. I think we need a bit more time to make it right. It does already the notion of 'default' simulator for compatibility sake.

[mvanriet]

The SimRunner class knows which simulator is active, because the simulator registered itself when it was created. So SpiceCircuit.run() calls SimRunner.run().
The simulators are only provided with .net-files, so they don't have to know about the SpiceCircuit classes.

Note that this is just 1 approach. There are probably other solutions.

But I do think that it is necessary to split the simulator part from the SpiceCircuit part.
This reduces complexity, and allows for more growth both on the circuit part and on the simulator part.

Which way to do it - in keeping backwards compatibility - is something that must be carefully considered.
If you like, I can help in making some proof-of-concept protypes to evaluate different approaches.