Friday, April 13, 2018

The road ahead in 2018

There has been a lot of changes this year and also the past year. Moved to Germany last year in May 2017 and came back in March 2018. Now that I have published a book with Springer, I would like to keep publishing and would not like my first book to be my last. And with this, I need to set some goals particularly for this year.

To begin with, I plan to create video lectures on my YouTube channel fairly regularly. The link to the channel is:

Feel free to subscribe and check out what will be uploaded there. I find that creating a video lecture helps to put together my thoughts for more elaborate reports and tutorials.

My plan is to create mini books in different topics in power electronics, bringing together similar topics or breaking a large topic into smaller sub-topics. Each book will be introduced with a series of video lectures and accompanied by a simulation package. I am planning the first mini-book on simulating many of the known topologies of dc-dc converters.

The theme of these books will be description from fundamental concepts with the minimal amount of mathematical analysis. The reason for doing so is to make power electronics learning accessible to working people who have limited time and energy after their day jobs.

And of course, if you would like to read all about the circuit simulator, feel free to check out my book on circuit simulation:

Most of the updates to the project will be on my Facebook page:

So feel free to like and follow the page for regular updates.

Sunday, January 28, 2018

Book published with Springer International

I am happy to make a couple of announcements. The first is that my book on the circuit simulator has been published with Springer International and can be found on their website:

The second is that I have launched a video lecture series on power electronics with my circuit simulator. For this I have started a You Tube channel:

Saturday, August 12, 2017

Migration to Python 3 and virtualenv

So far Python Power Electronics has been built on Python2. I have Python 2.7.9 on computer and most of the other versions of Python I have used are quite similar i.e Python 2.7.x. Python 2 is now legacy and support will be disabled from 2020. Though that is a couple of years away, I figured I should start migrating since Python 3 is now well established and almost every OS ships with Python 3 by default and it may be soon when installing Python 2 may actually become an issue.

To start this migration, I don't want to do a system wide installation of Python 3 as it will break all my projects. So I am starting with virtualenv. To begin with, I am installing Python 3.5.4 into a separate folder.

In my Linux system, the system wide packages are installed in /usr. So I am installing Python 3.5.4 in home:
In the above user is the name of the user that you are logged in as. For that matter, you could install this in any other folder of your choice. I would strongly suggest that you install Python 3.5.4 in a user writable directory and not in a root directory.

So, download Python 3.5.4 from the Python website:

So let us suppose, this is downloaded to:
Extract the zip file to:
Change into this directory. In this directory you will find the entire source.

There will be some dependency issues - something is missing etc. I had a problem with libssl-dev being missing. I installed it using apt-get on my Debian system.

Anyway, first compile the source:
/home/user/Python-3.5.4/ $ ./confiure --prefix=/home/user/python_3_5_4

The prefix states that Python should be installed in a special folder and not in /usr/local/ which is the default.
If you get any errors and you might, Google each error and check which package is needed. Quite often it may say a package is missing when it is installed. What might actually missing is the development package. For example libssl may be installed, but libssl-dev may be missing. But that may cause it to exit with an error.

After that run the command:
/home/user/Python-3.5.4/ $ make

And if no errors:
/home/user/Python-3.5.4/ $  make install

The last command will create within /home/user/python_3_5_4 separate bin/, lib/ etc directories where Python will be installed.

Now, if you check:
python -V
You should get Python 2.7.x.

But if you run:
/home/user/python_3_5_4/bin/python3 -V
You should get Python 3.5.4.

So this means Python 3.5.4 has been installed in a separate directory. Now to begin using it.

Create a directory in home or anywhere else which will be the separate environment for Python 3.5.4. For example,

Change into this directory. Now you need virtualenv installed. I didn't have it so I used apt-get again to install virtualenv.

Run the command:
/home/user/python_3_5_4_virtual $ virtualenv -p /home/user/python_3_5_4/bin/python3 python3_install

What this will do it create a virtual environment but will use this Python 3.5.4 installed in an isolated directory to create an install environment in the directory called python3_install. So python3_install will contain all software related to Python - django, matplotlib, numpy, scipy etc.

Once this is done, activate it:
/home/user/python_3_5_4_virtual $ source python3_install/bin/activate

Now a special session will start. If within this session, you run:
(python3_install) /home/user/python_3_5_4_virtual $ python -V
You will get Python 3.5.4. The (python3_install) in bracket means you are in a virtual environment.

If you exit this environment by running:
(python3_install) /home/user/python_3_5_4_virtual $ deactivate

You exit. Which means:
/home/user/python_3_5_4_virtual $ python -V
Gives Python 2.7.9. Notice that (python3_install) has disappeared meaning you have exited the virtual environment.

So, to perform the migration, I will enter this virtual environment, install dependencies with Python 3.5.4 as the base. I will check the operation of the simulator bit by bit.

Wednesday, July 26, 2017

Tutorial on PV panel simulation

I released a tutorial on how to simulate a PV panel.

This is the first step towards simulating the interaction of renewable energy systems with the grid and also on how to build smart grids and microgrids with renewable energy. In the past I have simulated converters for interfacing PV to the grid and I have usually assumed the PV panel as a dc source. As I was focused on the control of the power converter, assuming the PV panel as a dc source, was not a problem. But if I need to simulate how PV can be used in any system, I need a more accurate model of a PV panel. In the least, I need to be able to replicate the V-I characteristics of the PV panel. It would be a good addition if I could also model how the output of the PV panel is affected by radiation, temperature etc.

The problem is that a lot of the papers that deal with PV are pretty heavy into solid state physics. The widely popular current-source with anti-parallel diode equivalent circuit for a PV panel is usually used. However, where most of the papers defer is how to generate the constants that the current generated and drawn by the diode are expressed with respect to. The only data available from a PV panel specification are of limited use when it comes to solving these equations. In order to be able to completely express the equations, constants have to be determined by solving non-linear equations.

My objective was to generate a PV model that was reasonably accurate and also understandable to a power electronics engineer without an in-depth understanding of device physics. And I found that several approximations were possible to determine many of the constants that appeared in the equations.

The most important assumptions were around the two extreme operating points - open-circuit and short-circuit. At short-circuit, the entire photo current generated flows into the short. The short-circuit current at a reference temperature is provided in the datasheet. Therefore, the photo current can be equated to the short-circuit current. Conversely, at open-circuit, the entire photo current flows into the anti-parallel diode. Therefore, the diode current is now equal to the photo-current which at the reference temperature is equal to the short-circuit current. The concept is that the value of the photo current generated depends only on the temperature and solar radiation. At short-circuit, this current flows into the short while at open-circuit, it flows into the diode.

The remaining calculations are merely procedure. Finally, the PV current that has been calculated is modeled as a voltage behind a resistance. A capacitance is connected across the PV terminals to stabilize the voltage.

Check out the report in the tutorial link for more information.

Thursday, June 22, 2017

Launching the tutorial series with PLL

I am starting a series of tutorials on topics in power electronics and power systems. The purpose of these tutorials is to provide an educational resource for practicing engineers. The tutorials are made as simple and visual as possible and uses simulation to demonstrate concepts. Mathematical equations are used when necessary but every attempt is made to NOT make the tutorial mathematically rigorous so that the report is an easy read.

The first tutorial is on PLL and can be found in the link:

The report is available for free but the simulation examples have to be purchased from the e-commerce website Gumroad:

If all you need is a brief idea about PLL, the report is all you need. But if you would like to follow the tutorial step-by-step, the simulation examples will help you tinker with control gains and other parameters.

The objective behind the tutorials is to use the flexibility and convenience of simulations in understanding complex problems in advanced power systems. In this tutorial, you learn how grid synchronization is important and what happens without it, how to design a PLL for single and three-phase systems. The simulation files are just a starting point. You could always use them to try out some additional control.

Friday, April 28, 2017

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:

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

Monday, April 17, 2017

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.