Category: blog

HIVE reaches 40K lines

HIVE 3.x BannerCode statistics for HiveWith the inclusion of the phonon-module and some minor fixes and extensions to existing code, the hive 3.x program now counts over 40.000 lines, spread over 60 files. 8% of all lines are blank lines, 71% of all lines contain code, and 21% contain comments, an indication of the extent of the documentation of the code.

The code now provides access to 33 command line options of varying complexity. The simplest options (extracting a geometry, or creating a cif-file) are nearly instantaneous, while more complex options (such as Hirshfeld-I calculations) can take up to several hours.

Also from this point onward, HIVE will require to be linked with a lapack-library during compilation, to allow for the efficient solution of eigenvalue-problems.

Time for a little celebration.

Happy Tau-day

June 28th or 6/28 the first three digits of 2\pi aka \tau. In response to the creation of \pi-day (March  14th), June 28th was suggested as \tau-day to celebrate the number representing the ratio between the circumference of a circle and its radius. (And as with most opinions these days there needs to be a lot of controversy and discussion 😎 ) Having no religious preferences for either, I suggest to celebrate both, one with a single pie, and the other with two.

Phonons: shake those atoms

In physics, a phonon is a collective excitation in a periodic, elastic arrangement of atoms or molecules in condensed matter, like solids and some liquids. Often designated a quasi-particle, it represents an excited state in the quantum mechanical quantization of the modes of vibrations of elastic structures of interacting particles.

— source: wikipedia

Or for simplicity: sound waves; the ordered shaking of atoms or molecules. When you hit a metal bell with a (small) hammer, or make a wineglass sing by rubbing the edges, you experience the vibrations of the object as sound. All objects in nature (going from atoms to stars) can be made to vibrate, and they do this at one or more specific frequencies : their eigenfrequencies or normal frequencies.

Also single molecules, if they are hit (for example by another molecule bumping into them) or receive extra energy in another way, start to vibrate. These vibrations can take many forms (elongating and shortening of bonds, rotating of parts of the molecule with respect to other parts, flip-flopping of loose ends, and so forth) and give a unique signature to the molecule since each of these vibrations (so-called eigen-modes) corresponds with a certain energy given to the molecule. As a result, if you know all the eigen-modes of a molecule, you also know which frequencies of infrared light they should absorb, which is very useful, since in experiment we do not “see” molecules (if we see them at all) as nice ball-and-stick objects.

From the computational point of view, this is not the only reason why in molecular modeling the vibrational frequencies of a system (i.e. the above eigen-modes) are calculated. In addition, they also tell if a system is in its ground state (which is what one is looking for most of the time) or not. Although this tool has wide-spread usage in molecular modeling, it is seldom used in ab initio solid state physics because of the associated computational cost. In addition, because of the finite size of the unit cell, the reciprocal space in which phonons live also has a finite size, in contrast to the single point for a molecule…making life complex. 😎

Continue reading

Tutorial OOP(II): One problem, different possible classes

additional resources
agent paper: Sobkowicz
source-code: AgentTutorials
Arxiv: Full Tutorial

In the previous tutorial, we saw how to tackle an opinion dynamics problem using agents as a class in an Object Oriented Programming (OOP) approach. In many topics of interest in (socio-)physics and chemistry, we deal with a large number of particles, be it electrons, atoms, agents, stars, … These are contained in a superstructure (electrons⇒atom, atoms⇒molecule/solid, agents⇒population, stars⇒galaxy,…) which is generally represented in the code as an array. As we noted in the previous tutorial, there were several variables which were global to the agents, but we implemented them as properties of the agents anyhow. As a result, a significant amount of additional memory needed to be allocated for storing in essence the same data. This was done to prevent the need of having to provide this information at every function call.

Returning to our problem of interest, we now consider two object classes: The TAgent-class and the TPopulation-class. This leads to several possible ways this problem can be implemented.

  1. Array of TAgents: As was done in the previous tutorial, we only make a class of the agents, and put them in an array.
  2. TPopulation of TAgents: In this case we construct a class called TPopulation of which one property is the set of TAgents. The TPopulation-class also contains some of the global variables as properties, and operations on this set are methods of the TPopulation-class.
  3. TPopulation-class without TAgent-class: In this last case, the agents are dissolved, and their properties are stored in array-properties of the TPopulation-class. The methods of the TAgent-class now become methods of the TPopulation-class. And the global variables become additional properties of the TPopulation-class.

Although the true OOP-programmer may only consider the  second option the way to go, we will consider the third option in this tutorial.

Continue reading

Fabulous Famelab

Sylvia convincing the jury at the Famelab heat in Ghent. (thanks to jury member Philippe Smet)

Sylvia convincing the jury at the Famelab heat in Ghent. (Thanks to jury member Philippe Smet)

These days, a scientist is no longer the lone researcher, hiding away in dark rooms and cellars, never coming out, except to ask a servant to mail a letter with his/her newest findings to a like-minded scholar hidden in some other dungeon. Nowadays, we have email to do the latter. In addition, “the scientist” has also had to become the inspiring teacher, the diligent administrator/manager, and the quick salesman/woman pitching his/her ideas for new project-funding. More recently, becoming a rock star was added to this list. (One may start to wonder when she/he should be doing research.)

Since 2005, Famelab, which is part of the Cheltenham Science Festival, has been a platform for young scientist to become such a rock star. In only three minutes, they have to explain a scientific topic of their own choice (and expertise) to the lay public. For this they are allowed only the use of a prop, which they have to be able carry by themselves onto the stage (i.e. no PowerPoint-slides or projected video). Their presentation is then judged by a panel with experience in science communication, focusing on 3 c’s: clarity (the general public should understand what you are going on about), content (it’s not because you present for a general public that you are allowed to cut corners and tell things which aren’t really true) and communication charisma (can you inspire people).

This year, my girlfriend decided to enter the Famelab competition (she’s by far the better communicator of the two of us). During the regional Famelab-heat on April 24th, in my hometown Ghent, she explained in three minutes why we see colours in soap-bubbles (video). The competition during the heat was quite impressive, and of the 25 people who started that day, she was one of the eight national finalist who will be competing, coming May 12th in Leuven, for a single spot in the international Famelab final in the UK. On her blog you can find more on the entire Famelab experience: (1),(2),(3) )

She will be presenting a different story than during the regional heat, which I am not yet allowed to disclose. All I can say is that you will look differently at yourself afterward, and we already made a video of the act/presentation in the streets of Ghent.

In her rise to science-rock-stardom, she already has her first groupie signing this post.

Tutorial OOP(I): Objects in Fortran 2003

After having set up our new project in the first session of this tutorial, we now come to an important second step: choosing and creating our Objects. In OOP, the central focus is not a (primitive) variable or a function, but “an object”. In Object Oriented Programming (OOP) most if not all variables and functions are incorporated in one or more (types of) objects. An object, is just like a real-life object; It has properties and can do things. For example: a car. It has properties (color, automatic or stick, weight, number of seats,…) and can do things (drive, break down, accelerate,…). In OOP, the variables containing the values that give the color, weight, stick or not,… of the car are called the properties of the car-object. The functions that perform the necessary calculations/modifications of the variables to perform the actions of driving, breaking down,… are called the methods.

Since we are still focusing on the opinion dynamics paper of Sobkowicz, let us use the objects of that paper to continue our tutorial. A simplified version of the research question in the paper could be as follows:

How does the (average) opinion of a population of agents evolve over time?

For our object-based approach, this already contains much of the information we need. It tells us what our “objects” could be: agents. It gives us properties for these objects: opinion. And it also tells us something of the methods that will be involved: opinion…evolve over time.

Let us now put this into Fortran code. A class definition in Fortran uses the TYPE keyword, just like complex data types.

  1. Type, public :: TAgentClass
  2. private
  3. real :: oi !< opinion
  4. contains
  5. private
  6. procedure, pass(this), public :: getOpinion
  7. procedure, pass(this), public :: setOpinion
  8. procedure, pass(this), public :: updateOpinion
  9. end type TAgentClass

Continue reading

Tutorial: Starting a new Object Oriented Fortran-project in Code::Blocks

Because Fortran has been around since the time of the dinosaurs, or so it seems, one persistent myth is that modern constructs and techniques are not supported. One very important modern programming approach is Object Oriented Programming (OOP). Where procedural programming focuses on splitting the program in smaller functional units (functions and procedures), OOP is centered on “Objects and Classes”. These objects, just like real life objects, have properties (eg. name, color, position, …) and contain methods (i.e. procedures representing their functionality). This sounds more complex than it actually is. In a very simplistic sense, objects and classes are created by extending complex data types in procedural programming languages with internally contained functions/procedures, referred to as methods. In the table below, you see a limited comparison between the two. The first three languages are procedural oriented languages, while the last two allow for OOP.

C Pascal F95 C++ OOP F2003 OOP
data type keyword struct record type class type
containing variables field field field property property
containing functions / / / method method
inheritance no no no yes yes

In this tutorial series, I want to show how you can use OOP in Fortran in scientific codes. As a first example, I will show you how to create an agent based opinion dynamics code implementing the model presented by Sobkowicz in a publication I recently had  to review.

I choose this as our tutorial example (over for example geometric shapes) because it is a real-life scientific example which is simple enough to allow for several aspects in scientific and OO-programming to be shown. In addition, from the physicists point of view: particle or agent, it is all the same to us when we are implementing their behavior into a program.(You could even start thinking in terms of NPC’s for a game, although game-dynamics in general require quite a bit more implementation)

So let us get started. First, you might wish to grab a copy of the paper by Sobkowicz (it’s freely accessible), just to be able to more easily track the notation I will be using in the code. After having installed code::blocks it is rather straight-forward to create a new Fortran program.

  1. Open code::blocks, and start a new project (File > New > Project) by selecting “Fortran application”newProject
  2. Provide a “Project title” and a location to store the files of the new project.setupProject1
  3. Choose your compiler (GNU Fortran Compiler, make sure this is the one selected) and Finish.setupProject2
  4. Now Code::Blocks will present you a new project, with already one file present: main.f90 HelloWorld
  5. First we are going to rename this main file, e.g. to main.f95, to indicate that we will be  using Fortran 95 code in this file. By right-clicking on the file name (indicated with the red arrow) you see a list of possible op w this option while the file is open in the right-hand pane. Close the file there, and now you can rename main.f95.
  6. Although we will be following the OOP paradigm for the main internal workings of our program, a procedural setup will be used to set up the global lines of the program. I split the code in three levels: The top-level being the main program loop which is limited to the code below, the middle level which contains what you may normally consider the program layout (which you can easily merge with the top level) and the bottom level which contains the OO innards of our program. All subroutines/functions belonging to the middle level will be placed in one external module (Tutorial1) which is linked to the main program through the use-statement at line 2 and the single subroutine call (RunTutorial1).
  1. program AgentTutorials
  2. use Tutorial1;
  3. implicit none
  4.  
  5. write(*,'(A)') "Welcome to the Agents OOP-Fortran Tutorial"
  6. call RunTutorial1()
  7. write(*,'(A)') "-- Goodbye"
  8. end program AgentTutorials
  1. Next step, we need a place for the RunTutorial1 subroutine, and all other subroutines/functions that will provide the global layout of our agents-program. Make a new file in Code::Blocks as followsNewFile
  2. and select a Fortran source file and finish by placing it in a directory of your choice and click OK.NewFile2
  3. In this empty file, a module is setup in the following fashion:
  1. module Tutorial1
  2. implicit none
  3. private
  4.  
  5. public :: RunTutorial1
  6.  
  7. contains
  8. !+++++++++++++++++++++++++++++++++++++
  9. !>\brief Main program routine for the first agents tutorial
  10. !!
  11. !! This is the only function accessable outside this module.
  12. !<------------------------------------
  13. subroutine RunTutorial1()
  14. write(*,'(A)') "----Starting Turorial 1 subprogram.----"
  15. write(*,'(A)') "-------End Turorial 1 subprogram.------"
  16. end subroutine RunTutorial1
  17.  
  18. end module Tutorial1
  1. implicit none : Makes sure that you have to define all variables.
  2. private : The private statement on line 3 makes sure that everything inside the module remains hidden for the outside world, unless you explicitly make it visible. In addition to data/information-hiding this also helps you keep your namespace in check.
  3. public :: Runtutorial1 : Only the function Runtutorial1 is available outside this module.(Because we want to use it in program  AgentTutorials.)
  4. contains : Below this  keyword all functions and subroutines of the module will be placed.
  5. “!” : The exclamation marks indicate a comment block. In this case it is formatted to be parsed by doxygen.
  6. subroutine XXX  / end subroutine XXX : The subroutine we will be implementing/using as the main loop of our agents program. Note that in recent incarnations of fortran the name of the subroutine/function/module/… is repeated at their end statement. For small functions this may look ridiculous, but for larger subroutines it improves readability.

At this point or program doesn’t do that much, we have only set up the framework in which we will be working. Compiling and running the program (F9 or Build > Build and run) should show you:

AgentsRun1 In the next session of this tutorial we will use OO-Fortran 2003 to create the agent-class and create a first small simulation.

 

 

Spring School Computational Tools: Day 5 – CP2K

Today was the fifth and last day of our spring school on computational tools for materials science. However, this was no reason to sit back and relax. After having been introduced into VASP (day-2) and ABINIT (day-3) for solids, and into Gaussian (day-4) for molecules, today’s code (CP2K) is one which allows you to study both when focusing on dynamics and solvation.

ensembles

If ensembles were coffee…

The introduction into the Swiss army knife called CP2K was provided by Dr. Andy Van Yperen-De Deyne. He explained to us the nature of the CP2K code (periodic, tools for solvated molecules, and focus on large/huge systems) and its limitations. In contrast to the codes of the previous days, CP2K uses a double basis set: plane waves where the properties are easiest and most accurate described with plane waves and gaussians where it is the case for gaussians. By means of some typical topics of calculations, Andy explained the basic setup of the input and output files, and warned for the explosive nature of too long time steps in molecular dynamics simulations. The possible ensembles for molecular dynamics (MD) were explained as different ways to store hot coffee. Following our daily routine, this session was followed by a hands-on session.

In the afternoon, the advanced session was presented by a triumvirate:  Thierry De Meyer, who discussed QM/MM simulations in detail, Dr. Andy Van Yperen-De Deyne, who discused vibrational finger printing and Lennart Joos, who, as the last presenter of the week, showed how different codes can be combined within a single project, each used where they are at the top of their strength, allowing him to unchain his zeolites.

CP2K, all lecturers

CP2K, all lecturers: Andy Van Yperen-De Deyne (top left), Thierry De Meyer (top right), Lennart Joos (bottom left). All spring school participants hard at work during the hands-on session, even at this last day (bottom right).

The spring school ended with a final hands-on session on CP2K, where the CMM team was present for the last stretch, answering questions and giving final pointers on how to perform simulations, and discussing which code to be most appropriate for each project. At 17h, after my closing remarks, the curtain fell over this spring school on computational tools for materials science. It has been a busy week, and Kurt and I are grateful for the help we got from everyone involved in this spring school, both local and external guests. Tired but happy I look back…and also a little bit forward, hoping and already partially planning a next edition…maybe in two years we will return.

Guests from the VASP (Martijn Marsman, top left) and ABINIT group (Xavier Gonze, top right, Matteo Giantomassi, bottom left, Gian-Marco Rignanese, bottom right)

Our external lecturers from the VASP group (Martijn Marsman, top left) and the ABINIT group (Xavier Gonze, top right, Matteo Giantomassi, bottom left, Gian-Marco Rignanese, bottom right)

Spring School Computational Tools: Day 4 – Gaussian

After having focused on solids during the previous two days of our spring school, using either VASP (Tuesday) or ABINIT (Wednesday), today’s focus goes to molecules, and we turn our attention to the Gaussian code.

Dietmar Hertsen introduced us into the Gaussian code, and immediately showed us why this code was included in our spring school set: it is the most popular code (according to google). He also explained this code is so popular (among chemists) because it can do a lot of the chemistry chemists are interested in, and because of the simplicity of the input files for small molecules. After pointing out the empty lines quirks of Gaussian it was time to introduce some of the possible editors to use with Gaussian. The remainder of his lecture, Dietmar showed us how simple (typical) Gaussian calculations are run, pointing out interesting aspects of the workflow, and the fun of watching vibrations in molden. He ended his lecture giving us some tips and tricks for the investigation of transition states, and the study of chemical reactions, as a mental preparation for the first hands-on session which followed after the coffee-break.

Lecturers for the Gaussian code.

Lecturers for the Gaussian code: Dietmar Hertsen (left) introducing the basics of the code, while Patrick Bultinck (right) discuses more advanced wave function techniques in more detail.

In the afternoon it was time to take out the big guns. Prof. Patrick Bultinck, of the Ghent Quantum Chemistry Group, was so kind to provide the advanced session. In this session, we were reminded, after two days of using the density as a central property, that wave functions are the only way to obtain perfect results. Unfortunately, practical limitations hamper the application to the systems of interest from a practical physical point of view. Patrick, being a quantum chemist to the bone, at several points stepped away from his slides and showed on the blackboard how several approximations to full configuration interaction (full-CI) can be obtained. He also made us aware of the caveats of such approaches; Such as size consistency and basis(-type) dependence for truncated CI, and noted that although CASSCF is a powerful method (albeit not for the fainthearted), it is somewhat a black art that should be used with caution. As such, CASSCF was not included in the advanced hands-on sessions guided by Dr. Sofie Van Damme (but who knows what may happen in a future edition of this spring school).

Spring School Computational Tools: Day 3 – Abinit

Today is the third day of our spring school. After the introduction to VASP yesterday, we now turn our attention to another quantum mechanical level solid state code: ABINIT. This is a Belgian ab initio code (mainly) developed at the Université Catholique de Louvain (UCL) in Wallonia.

Since no-one at CMM has practical experience with this code and several of us are interested to learn more about this code, we were very pleased that the group of Prof. Xavier Gonze was willing to support this day in its entirety. During the morning introductory session Prof. Xavier Gonze introduced us into the world of the ABINIT code, for which the initial ideas stem from 1997. Since then, the program has grown to about 800.000 lines of fortran code(!) and a team of 50 people worldwide currently contribute to its development. Also in recent years, a set of python scripts have been developed providing a more user friendly interface (abipy) toward the users of the code. The main goal of the development of this interface, is to shift interest back to the physics instead of trying to figure out which keywords do the trick. We also learned that the ABINIT code is strongly inspired by the ‘free software’ model, and as such Prof. Xavier Gonze prefers to refer to the copyright of ABINIT as copyleft. This open source mentality seems also to provide strength to the code; leading to its large number of developers/contributors; which in turn leads to the implementation of a wide variety of basis-sets, functionals and methodologies.

After the general introduction, Dr. Matteo Giantomassi introduced the abipy python package. This package was especially developed for automating post-processing of ABINIT results, and automatically generating input files. In short, to make interaction with ABINIT easier. Matteo, however, also warned that this approach which makes the use of ABINIT much more black box, might confuse beginners, since a lot of magic is going on under the hood of the abipy scripts. However, his presence, and that of the rest of the ABINIT delegation made sure confusion was kept to a minimum during the hands-on sessions, for which we are very grateful.

After the lunch break, Prof.  Gian-Marco Rignanese and Prof. Xavier Gonze held a duo seminar on more advanced topics covering Density Functional Perturbation Theory and based on this spectroscopy and phonon calculations beyond the frozen phonon approach. Of these last aspects I really am interested in seeing how they cope with my Metal Organic Frameworks