Category Archives: bash

ll4D: the LXD(LXC)-LAMP environment For Development

There are plenty of tools for development, but I really wanted to take advantage of LXD for web development, so I ended up writing ll4d: the LXD(LXC)-LAMP environment For Development environment.

There are probably better ways to do this, and highly optimized juju charms to build something much better. But for my persona use case, this script is just perfect. It takes just 48 seconds to build everything and it has 100% all the functionality I need.

It is a very simple script, which works as follows:

  • Sets up a basic LXC/LXD environment
  • Creates a container with a LAMP (Linux Apache MySQL PHP) server
  • Creates a fancy symbolic link from the apache root directory at the LAMP container to somewhere in your home or desktop. This allows you to work on your code using your visual tools and view the result on the fly
  • Create a simple website to test Apache, PHP and MySQL

Here is an screenshot of a working environment. You work from a directory directly under your home, access the LAMP server for working with configurations and MySQL databases and access the server on at the given IP.

Screenshot of a work environment with ll4d.

Screenshot of a work environment with ll4d.

ll4d is available on my github repository:

The few instructions on how to download and exectute it, can be found at the README file.

I hope you find it useful… if you don’t, you can remove it completely in 3 simple steps:

./ –clean
rm -rf ll4d*
sudo aptitude purge lxd


Logo of BOMSI

The easiest way to install OpenStack: BOMSI GUI

Installing OpenStack is quite difficult, specially for the people who is not really into basically most of IT topics. In my attempt to get started, and after searching for the easiest way to install OpenStack, I ended up writing my own automated tasks in BASH, and at some point I decided to generalice those scripts a little bit more and release them to the community.

I named the installer as BOMSI: the Bash OpenStack Multinode Scripted Installer. Descriptive and catchy, isn’t it? 🙂

BOMSI follows the official install guide at OpenStack Docs for CentOS7, and it does it in plain BASH, so it is easy to understand whatever is going on during the installation, and easily improve it. It’s GPL v2 license, so you are all very welcome to contribute on GitHub repository.

The command line API is very simple and it allows to install OpenStack on a virtual environment with just 3 commans:

git clone
cd BOMSI/CentOS7-Kilo/
for NODE in controller compute1 network; do ./ -n=$NODE; done

… and that’s it. In some 15 minutes a horizon dashboard will be waiting for you at

For generating the 3 node virtual environment it is recommended that have 8 or 16 Gb of RAM, a i5 or i7 processor (or equivalent) and some 20 Gb of free space on the hard disk, to host the KVM virtual machines. Ideally the computer should be running Ubuntu, but it should work somehow in other GNU/Linux distributions.

Furthermore, being aware that some people prefer graphical user interfaces (GUIs) to work on the configuration files and execute the options, I also added a very simple GUI.

This GUI can be run the same as the API, but with even less letters on the command line:

git clone
cd BOMSI/CentOS7-Kilo/

And you’ll get this:

Graphical User Interface for installing OpenStack with BOMSI

If you are OK with the default options, just click on the “Local KVM” square button and wait for some 15 minutes. That’s it.

Additional features of BOMSI:

  • Generate a fully automated multiboot ISO file, which can be burned onto a CD or provisioned via PXE
  • Install this ISO file into a pen-drive
  • Install a temporal CentOS machine with kickstart. This machine can be used to download all necessary packages to allow full offline installations

So… 3 commands, or 3 commands and a click, isn’t this the easiest way to install OpenStack at the moment?

IR and Raman spectra calculated with Quantum Espresso

Infrared (IR) and Raman spectra are two very valuable tools for the characterization of chemical compounds. And although there seem to be many different possibilities to produce them computationally, I didn’t find any clear tutorial on how to produce them using free software tools. Some of them, give complicated instructions on how to calculate second derivatives or Raman tensors, or stuff like that, but in the end one wonders: Where are the numbers I have to plot!

…Thereby, here is my post about computing IR and Raman spectra with Quantum Espresso.

For the impatient: most of this post is resumed in my Quantum Espresso example for the PHonon code, which will run for some 15-17 minutes and pop-up the IR/Raman spectra of CO2 and ZnO (Wurtzite).

Continue reading

Checking the optimum cutoff for QE

Rise your hand if you have ever gotten a pseudo-potential from somewhere and you started to use it just by checking the recommended values of the cutoffs inside the file.

Are we sure these values are good?
If you are an skeptic scientist and you do not thrust what you don’t do by yourself, now there is a really simple and cheap way for you to test for the optimum cutoff of any pseudopotential with Quantum Espresso: my pw_cutoff checking script.

The ecutwfc is described in the manual as the kinetic energy cutoff for wave functions in Ry. Continue reading

resend: Long calculation vs. short walltime

A typical problem in the life of a computational scientist: your calculations take longer than the wall time in the supercomputer. If the job can be restarted, we can work around that by re-sending it manually but that is quite tedious sometimes.

My solution: use the “resend” BASH script 😉 (which you can download here)
As in the case of the most of my scripts, there is a “-h” option. This helps if you don’t remember the syntax,  this option will remind you about the few possibilities.
You need the job script you submit to the queue, and the input(s). The script keeps checking the qstat for the current user, and searching for the path from where the resend was executed. Whenever there is no job running or in queue with the same path, it submits another one. If there is a job with the same path, it waits for one minute and tries again.

The resend script is as easy to use as:

user> nohup resend -n 5 -f /path/to/script.cmd &

were “-n” option specifies the number of times the job will be resent (default: 3) and “-f” the path to the batch job script (default: ./job.cmd). It is useful to include the last option in order to be able identify the process (by i.e. “ps”) if necessary.

For killing the script, you can use:
>touch STOP
this will break the internal loop and exit the script.

From the same directory, or just search the PID and kill it.

Another trick: if you already have executed the program, but you notice that you would like to run the job some more times, you can resend it again and the job will be sent as many times as the sum of resend’s both scripts request.