Graphical = good and command line = bad?

It is not uncommon to hear (mostly from Windows users berating Linux and its “useless console”) that one of the benefits of Windows is that everything can be done through a GUI. After all, clicking on icons and finding stuff in menus is more intuitive, and everything is easier that way. In contrast, with Linux you have to “type an awful lot of things, which is boring, slow, and difficult. And ugly”.

Now, don’t get me wrong, GUIs are great. I quite like them. What annoys me is the lack of command-line interface for some tasks. Both GUIs and CLIs have their place in computer use, and the wise should use each when appropriate. In this post I will try to illustrate a case where the automation allowed by using the CLI and some scripting is largely missed. The user (me) is forced to use an “intuitive” GUI, with the result that my patience takes a direct hit below the flotation line.

The first task I faced was to plot some orbitals of a molecule. The data for each orbital is saved in one file, and I am running a program that can read them and plot the given orbital (Molekel).

The following YouTube video, made by myself, shows the process of plotting 2 orbitals (I had to plot 17). Notice that, due to the program running so slow, the process takes around 1 minute per orbital!

Notice also that all the previous work has been done: choosing the colors of the background, atoms and orbitals, choosing the orientation, opening the atomic geometry… The comprehensive list of what to do for each orbital follows, with each line preceded by the point in time (seconds) when it happens:

  1. 00.00 – Click on “Delete surface” to remove previous orbital
  2. 07.80 – Click on “Load” to load a new orbital
  3. 12.67 – Choose a file from the dialog window, and click on “Accept” to load it
  4. 30.27 – Click on “Both signs”, because we want both positive and negative part of the orbital
  5. 31.33 – Introduce a value for the isosurface (0.05) in the “cutoff” box
  6. 33.13 – Click on “Create surface” to have Molekel render the isosurface
  7. 37.33 – Isosurface appears
  8. 37.93 – From a drop-down menu (called with right-click of the mouse), choose Snapshot -> RGB
  9. 52.66 – “Save as” dialog box appears
  10. 62.73 – Introduce filename for snapshot, and click “Accept”
  11. 65.00 – We’re done, and can repeat the process for the next orbital

One can’t help but notice that 65 seconds are needed to make eight clicks and introduce a short text in two boxes! The issue is that human attention is necessary during the whole 65 seconds, because the time between actions is too short to do something else in between (although long enough to get on your nerves, like the full 15 seconds to have the “Save as” dialog appear).

Another obvious point is that from the two short texts introduced by the user, one (the value of the isosurface) is always the same, and only the other (the name of the file to save the snapshot as) varies. Also, only one click of the 8 we do is ever different (the choice of orbital file to read). It would be nice to have a robot do this task, the only data we would have to feed it being a list of orbitals (to read, and then to save a snapshot). But we can’t. We are stuck with this sluggish process!

In contrast, I will next show a case where some automation was made. The process is that of cropping the snapshots taken in the previous step (the Molekel thing). Sure, we could use GIMP, or some other GUI tool, but applying exactly the same process to a list of 17 images (and this is a short list, it could have been 1000) is the kind of thing that cringes for automation.

The following video shows the process:

Recall that it takes 4 minutes to process ALL the images. This may not sound like a huge improvement over the 18:25 that it (in principle) took the process above (17 x 65 sec). However, the time spent with Molekel scales linearly with the number of orbitals. 100 orbitals would need almost 2h. The automated cropping process would have taken more than 4 minutes, but only slightly more: maybe 5 or 6.

Also notice that the 4 minutes are full of decisions, and there is no repetitive, unnecessary task (except the fact of committing errors). Let’s take a look at the actions taken during the 4 minutes:

  1. 00:11.00 – Open a Perl script I had half-done (another benefit of automation: you can reuse old stuff)
  2. 00:17.87 – Shade window to take a look at the number and name of files to process
  3. 00:21.33 – Change script accordingly
  4. 00:47.93 – Save changes
  5. 00:51.60 – Back to the CLI, and run the script
  6. 00:55.00 – Ups, nothing happened!
  7. 00:58.27 – Reopen the script, and look for the error
  8. 01:05.53 – Found it. Fix it.
  9. 01:07.33 – Save and execute
  10. 01:06.87 – It works!
  11. 01:13.00 – Finished running (0.36 sec per picture)
  12. 01:21.73 – Open a cropped image in viewer
  13. 01:22.93 – Realized the crop is wrong!
  14. 01:30.73 – Alt-Tab to script file, to modify it
  15. 01:55.67 – Save and execute again
  16. 02:11.73 – Open the cropped images. The first one seems to be OK!
  17. 02:29.80 – We reach one that is wrong
  18. 02:34.20 – Back to the script, and fix it
  19. 02:45.07 – Save, and back to CLI to re-run
  20. 02:53.00 – Reopen in image viewer
  21. 02:56.00 – Cropped part is not centered!
  22. 03:02.00 – Back to the script, and fix it
  23. 03:12.33 – Save and re-run
  24. 03:19.73 – Reopen in image viewer
  25. 03:27.87 – Yet another error: an image could have been cropped more, to hide an unwanted part
  26. 03:32.40 – Back to the script
  27. 03:40.80 – Rerun
  28. 03:47.13 – Reopen images
  29. 03:59.93 – See that all of them are correct. Stop and rest

Recall also that if I were to repeat both processes tomorrow, the image cropping would simply require to run the script again (0.36 seconds per image, and you can do something else in between, if you have 1000 images and don’t want to waste time waiting). The creation of the orbitals, on the other hand, would require to repeat the whole process again!! (65 seconds per orbital, plus you have to spend that time paying attention to the process. You can not run something and go away). And the whole problem with the creation of the orbitals is that there is no command-line way of doing it, to be able to automate it.

3 Comments »

  1. Christine said,

    January 7, 2009 @ 18:24 pm

    Hi!
    What a nice post, I completely agree with you! The thing is, I am using Molekel the first time and I am facing the same problem as you did – but I did not find out how to do it. Could you maybe post your perl script? This would help me a lot.

    Cheers
    Christine

  2. isilanes said,

    January 8, 2009 @ 12:36 pm

    Thanks Christine!

    I don’t know what you actually expect, but I fear you will be disappointed. The Perl script does not automate the operations with Molekel, just the cropping of the images. If that is what you want, here you are:

    #!/usr/bin/perl -w

    use strict;

    
    my $basename = 'dip'; # for files "$basename.NUMBER.$ext
    my $ext = 'rgb'; # extension
    my $crop = '736x330+0+160' # WidthxHeight+Xoffset+Yoffset (pixels)
    
    for my $n ('071'..'087')
    {
      print "Converting $n... ";
      system "convert $basename.$n.*.$ext -crop 736x330+0+160 $basename.$n.jpg";
      system "convert $basename.$n.jpg eps3:$basename.$n.eps";
      print "\n";
    };
    

    The program will convert from orbital 071 to 087, cropping the original and then converting to EPS (to include in LaTeX documents). You can modify to your heart’s content, of course.

  3. Christine said,

    January 8, 2009 @ 21:00 pm

    Thanks for the answer!
    I finally finished rendering 3\times14 orbitals (to compare qualitatively the orbitals from CASSCF and DFT calculations with 2 different functionals) – by hand, one after the other… ;-)

    Christine

RSS feed for comments on this post · TrackBack URI

Leave a Comment