Menu Close

Author: Luca

How to best describe the interactions in discrete-particle materials models

Bunch of happy water molecules taking a selfie! Copyright Aatto Laaksonen (2018)

We know that atoms and molecules are attracted to each other simply because we know that matter condenses around us. We also know that they repel each other as molecules cannot be pushed very close to each other due to a strong repulsion. This means that in all attempts to describe inter-molecular interactions we need a wall at the short distances and a well at longer distances. A common wall-well model is the Lennard-Jones potential.

When we do ab initio modelling with nuclei and electrons the interactions between the nuclei, in the presence of the electrons, come from the first-principles and are calculated from the laws of physics. No need to think about attractions or repulsions separately. But when we go over from quantum mechanics (electronic models) to classical mechanics (atomistic models) we have to model both the sizes of the atoms and their mutual interactions. For this we have the several decades old molecular mechanical (MM) force fields (FF) which still have a strong position in all-atom (AA) molecular simulations. More sophisticated terms (polarizable, reactive, cross-terms, non-additive, three-body, etc) are being developed worldwide but most simulations are still performed with the simplest possible terms as they often are very robust and established models in classical physics. A development is in progress where machine learning techniques are applied to create accurate potential energy surfaces and force fields.

However, when we go from atomistic models to mesoscopic models we do no more have similar well-defined conceptual interaction blocks as in AA models to construct a mesoscale force field. Mesoscopic particles are generally very much softer than atoms, thus requiring much simpler and softer potentials. Nearly all the internal degrees of freedom that we have in molecules are gone except artificial bonds to connect the beads and sometimes artificial angles for three neighbouring beads. A few types of mesoscale force fields exist, but they can rather be characterized as ad hoc where some very simple objects (spheres) have been fitted to roughly reproduce some experimental data. It is not clear at all how to construct generally valid or transferable mesoscale force field. In the future, there will be an increased need for mesoscale and coarse-grained simulations as there will be a need to move towards larger and more complex soft-matter systems, simulated over longer times. But as long as we do not have accurate mesoscopic models it is difficult to couple and link these models with continuum or more macroscopic models. In materials science it may simply be better to connect atomistic models with continuum models, for example using, with finite elements and skip the third level of discrete models, namely the mesoscopic models.

We would like to initiate an informal discussion about mesoscopic discrete particle models. What is/are the best model(s) for soft-particle mesoscopic simulations according to you ? Tell us about your experiences and visions!

Kersti Hermansson & Aatto Laaksonen – Uppsala University

From debugging to validation & verification

Every one of us who writes computer programs to solve scientific and engineering problems knows that the coding itself takes only a small part of total development time. What takes most of the time is the tedious debugging of the program before the programmer and the users are satisfied. Sometimes not all of the bugs will ever be found which may, or may not, have consequences.

There are many ways to carry out the debugging, from placing simple write statements in the code, to checking that calculated numbers are reasonable, to using debugging and optimization tools. Some programming languages are safer than others. In general syntax errors are relatively easy to find and fix already by the compiler, while, for example, logical errors may take a long time to spot as the program runs well and keeps producing results. Additional types of errors are those when we attempt to divide by zero or an undefined number while running the program.

We learn to find the errors (most of them at least) in our own ways by systematically or randomly searching for them. There exist many well-known and embarrassing errors, from computer chips being rather bad in maths to maps for GPSs not leading anywhere or rather over a cliff or satellites not starting to orbit. Long ago as a post-doctoral fellow at the IBM laboratories, a colleague of us shared a story from the lab he came from where an office mate had changed a sign in the program he had been writing for the last three months. Not as a practical joke but rather to make his life miserable in a tough and competitive environment.

By writing this blog we would like you to tell about your own experiences concerning bugs in the program. What was the most fatal or curious bug you had in your own software or in a software written by other? And how did you find it? Share your experiences with us!

Kersti Hermansson & Aatto Laaksonen – Uppsala University