Sunday, June 4, 2017

User interface for Python Power Electronics

Though this is related to my circuit simulator Python Power Electronics, it is related to how Django and web interface is used which makes it more relevant in this blog. I released another version of my circuit simulator but this time the user interface is a web interface rather than the usual command line. The objective is to make the simulator more interactive and easier to use.

To begin with, I will describe the basic philosophy of using Django as a user interface. This is a concept which I don't think will be accepted by the main stream Django community as Django was never meant to be used as a user interface but as a web application to design a website that could be driven by a database. However, many of the features of Django make it very suitable for a user interface.

To begin with, any software GUI will have a few basic menu options on the start-up window which I have designed with Django's urls.py file. Every webpage has the header links that are similar to a standard GUI - browsing the simulation library, creating a new simulation, documentation (or help) and a contact page. This has been built into a base framework template file which has been extended by every other HTML template file. Clicking on a link will send you to a URL which in turn appears in the urls.py file and directs to a function which in turn renders another HTML page. This way a user can move around the software just like a GUI.

Typically, a simulation software GUI will allow you to load a simulation case which is a file stored on the user's computer. In the web app, every simulation case is a database entry stored in the database simulation_collection. The uppermost table is called SimulationCase. This table contains the title, description and parameters of every simulation created by a user. When the user clicks on the "Simulation library" link, all the entries in the table SimulationCase are listed out for the user to load any one.

Each SimulationCase entry is linked to several other tables. The first level of relationship is below:

SimulationCase
-----> CircuitSchematics
-----> CircuitComponents
-----> MeterComponents
-----> ControllableComponents
-----> PlotLines
-----> CircuitPlot
-----> ControlFile

These tables are linked to a SimulationCase as ForeignKey relationships as a single simulation case can have a large number of them. As an example, a simulation could have 10 circuit schematic spreadsheets, 100 circuit components altogether in all schematics, 20 meters, 15 controllable components, 45 elements that are to be written to the output data file and made available for user plotting, 30 circuit plots, and 5 control files. Such a hierarchy makes it convenient to segregate data and relate them in a logical manner which is useful particularly in creating forms with the models from ModelForm.

While creating a new simulation, it starts with a single new database entry for a SimulationCase with parameters. The user then adds CircuitSchematics. That results in a new database entry with the circuit file that is linked to the SimulationCase entry. From all the components in the circuit schematics, database entries are made for CircuitComponents, MeterComponents, ControllableComponents and these are also linked to the SimulationCase.

The next level of hierarchy is as follows:

CircuitSchematics
--------> Resistor
--------> VariableResistor
--------> Inductor
--------> VariableInductor
--------> Capacitor
--------> Voltage_Source
--------> Controlled_Voltage_Source
--------> Ammeter
--------> Voltmeter
--------> Diode
--------> Switch

The simulator will look for components in the circuit schematic spreadsheets and on finding a component will create a database entry in the table corresponding to the type of object. The objective behind separating the components into their respective types and having separate tables for each type was to use the ModelForm to create forms for each type rather than create a single component type. This results in customized forms, error checking and feedback messages.

CircuitPlot
--------> CircuitWaveforms

When the user creates a new circuit plot, a new data base entry in the table CircuitPlot is created. Each Circuit Plot can have numerous waveforms. When a waveform is added to a CircuitPlot, a new entry is created in the table CircuitWaveforms and linked to the entry in CircuitPlot. There is another layer:

CircuitWaveforms
--------> PlotLines

Every simulation case will have a number of data items that will be written to the output data file. These are called PlotLines. They may be meter outputs or VariableStorage elements in control files. The user can choose which PlotLine will appear in a CircuitWaveform. A CircuitWaveform can have several PlotLines and conversely a PlotLine can appear in several CircuitWaveforms. This results in a ManyToMany relationship.

ControlFile
--------> ControlInputs
--------> ControlOutputs
--------> ControlStaticVariable
--------> ControlTimeEvent

SimulationCase
--------> ControlVariableStorage

These are the input/output ports and the special variables of a control file. When a user adds a control file to a simulation case, a new entry is created in the table ControlFile. This control file entry can be configured. The user can add inputs, outputs, static variables, time events to a control file that can be used in the control code. Variable storage elements are global variables and therefore are related to the simulation case rather than a control file.

Many of these database entries are dynamic - the user can create and delete them. In some cases, the simulator creates the entries in which case they are created and deleted when the simulation is run when all the circuit files are processed. When a simulation is loaded, all data items related to the SimulationCase are also loaded. This is similar to the GUI based circuit simulators which will present the circuit in the latest state when a file is opened.