Command line versus web application

The development of the web application for the circuit simulator is under way and can be found on my GitHub account:
https://github.com/shivkiyer/circuit-simulator/tree/sim_with_django

For a while, both command line and the web app will be available simultaneously for those who would prefer command line. The main disadvantage of the web application is the need to have Django installed. Though not a significant task, for someone who doesn't want a server running on their computer, it may not be the best option. I am still thinking of ways to automate the setup of the Django server so that maybe a single script could have everything up and going.

The first few steps in this direction seem promising. For example, so far, I have been able to replace the circuit_inputs.csv file. When a new simulation is created, the first form is the one that contains the fields similar to circuit_inputs.csv. Django provides features where error messages can be automatically generated when the user enters wrong data. For example, the user needs to specify the working directory that will contain the circuit schematic spreadsheets and other files. This working directory will be used also to write the output data file and therefore needs to have write permission to it. Since this Django app should be preferably run as user rather than root or Administrator, the working directory chosen should be writable by a user. This check is performed at the model level where a validation method has been written. This validation method writes a dummy file just to check if the app can write into the directory and failure to do so results in an error which shows up in the form. So the user can't submit a form without choosing an appropriate directory.

The user interface is divided into several segments. The first form above will only ask for basic parameters like time duration, time step, data storage interval, working directory etc. Once done, these parameters will appear as a table and the next form will ask for the user to choose the circuit spreadsheets from a file browser form. The user can still go back and edit the simulation parameters with an Edit parameter option. The file browser button makes life easier in choosing files rather than write them in circuit_inputs.csv. It would also be possible to check if the files are .csv files an also if they actually exist in the working directory.

The same goes for control files. They will have similar file browser buttons that can allow the user to choose Python control code.

As compared to the command line, the major advantage is that errors are pointed out right away and in a little more friendlier manner. The command line does provide error messages and I will try to bring it close to the web app in terms of how immediately the errors are pointed out. This might save the user progressing to the last stage and then seeing the simulator point out an error in the schematic which should have been picked up right away after the circuit_inputs.csv file was provided.

In the web app, errors in the circuit file and also errors in parameters can be generated by processing all these files. The same checks could be imposed - paired jump labels, closed branches etc. Since, a circuit can only really be checked after all circuit spreadsheets have been read and processed, this error generation will need to take place at a higher level.

What will be challenging is to generate parameters for all the circuit spreadsheets. The simplest way to do this will be create models for every component and add them to the circuit files as ManyToMany objects. This also allows a ModelForm to be created to every component model and further to connect each component to the circuit spreadsheet. Eventually, the parameters obtained from the ModelForms will need to be returned to the classes in circuit_elements. Which means the read_parameter methods of every class will need to be changed or overloaded for an interface to the web app.

Django seems to provide a fairly convenient and hierarchical structure.

Simulation Case  ---> Circuit files ---> Component objects
                            ---> Control files ---> Control objects

User interface

One of the biggest drawbacks of the circuit simulator has been the lack of a graphical user interface. For a Linux user, running a software from a command line is not too much of a hassle, but for users of other operating systems, it usually is. A graphical user interface where one or a few windows gives you everything you need is what everyone wants. Something like that may be too much to build at this point of time, but I have been considering options that can provide a consolidated interface without a full-scale graphical component.

Since the time I have been using Django for web development, I have been thinking of using it to create a user interface for the simulator. Django is fairly easy to install in any operating system. It is fairly easy to setup particularly as a standalone server with the SQLite database good enough for development applications and also easy to configure. The database setup scripts are not too hard. And once the server is running, you could access the app through a web browser.

There are aspects of the simulator that are good the way they are. For example, designing circuits through spreadsheets. That will remain for a long time as it is fairly convenient and also spreadsheet software are available for any operating system. So trying to replace the design of the circuit at the current moment is not really necessary. However, many other aspects are. For example, entering the circuit parameters. This could be made much more interactive through a web app. Once the circuit design is processed, instead of asking the user to change the parameters in the spreadsheet, an interactive form can be designed to help the user out with entering circuit data. The next is in designing controllers. Right now, every controller has a descriptor spreadsheet which lists the inputs, outputs and also special variables. This process can be made interactive as the user can be allowed to choose meters from any spreadsheet or outputs from any sheet. The last and the most important is the plotting of circuit data. Using Gnuplot is extremely convenient but for most this just isn't interactive enough. If a plotting interface can be built into the web app where a user can choose the x and y axis of every plot and simply click a button to get the plot either embedded in the web browser or as a separate window, it would be much simpler. Eventually, the result is what is most important to the user, and I need to make the viewing of results a little easier.

Since this simulator is for large circuits with a large amount of data being generated, trying to run the simulator remotely over a server is not a feasible option. It may be for smaller circuits that do not require much data being transmitted over the network but for larger circuits, it wouldn't work. So the purpose of using Django is merely to build an interface that is almost graphical but without using something like Tkinter or PyQt that would take me a lot of time.

Django allows the user to enter data in forms similar to any web form. The only additional layer is to make the forms relevant to the circuit by creating a model layer. Moreover, this model layer will have to be dynamic as every circuit is unique. Therefore, Django will merely replace the cells in a spreadsheet with HTML forms that hook up to a database.