Most commented posts
- Phonons: shake those atoms — 3 comments
- Start to Fortran — 1 comment
Nov 28 2015
Met dit essay nam ik deel aan de Robbert Dijkgraaf essay-prijs 2015.
Dit jaar was het thema verbeelding, en in mijn bijdrage doe ik een
poging de rol van verbeelding naar voren te brengen binnen
computationeel materiaalonderzoek. Ik probeer eveneens uit te
leggen hoe ik computationeel onderzoek zie als onderzoeksdomein.
Een vertaling naar het Engels kan hier gevonden worden.
Stel je een wereld voor waarin je atomen kunt zien. Meer nog, je kunt ze stapelen als legoblokken en manipuleren naar eigen goeddunken. Stel je een wereld voor waarin je de natuurwetten kunt aan- of afzetten, een wereld waar je zelf nieuwe natuurwetten kunt schrijven. In zo een wereld heb jij het voor het zeggen. Welkom in mijn wereld, de wereld van het “computationele materiaalonderzoek“.
Het zou een mooi begin zijn van een reclamespot voor dit onderzoeksgebied. In de bijhorende clip krijg je in elkaar overgaande beelden te zien van supercomputers enerzijds en animaties van chemische en biochemische processen op de atomaire schaal anderzijds. Het geheel wordt dan doorgelinkt aan onze eigen toekomst met sciencefictionachtige laboratoria waar de berekende materialen direct worden omgezet tot nieuwe medicijnen, flinterdunne beeldschermen en toepassing voor de ruimtevaart. De steeds sneller elkaar opvolgende beelden culmineren dan in de slotslogan: “Simuleer de toekomst!” met als onderschrift de aansporing om computationeel materiaalonderzoek te gaan studeren. Ik stel me voor dat zo’n reclameclip wel tot de verbeelding zou spreken. Het spreekt onze menselijke drang om te creëren aan met de belofte dat je alles kunt, als je het je maar kunt voorstellen. Je verbeelding is de enige beperkende factor.
Zoals bij de meeste reclamespots wordt ook in deze de werkelijkheid iets mooier voorgesteld dan ze is. Zoals voor elke andere wetenschapper geldt immers dat je bijdrage aan de vooruitgang beperkter is dan je zou willen. De gepresenteerde goddelijke almacht en alwetendheid liggen wel binnen handbereik. Als computationeel onderzoeker heb je immers absolute controle over de plaatsing van atomen en de inwerkende krachten, iets waar een experimenteel onderzoeker deels is overgelaten aan de grillen van de natuur en zijn of haar apparatuur. Deze controlevrijheid laat je toe, binnen een computer, elke wereld te creëren die je maar kunt bedenken.
Als wetenschapper wil je de wereld om je heen begrijpen, wat bovenstaande vrijheden inperkt, tenzij je ervoor kiest om in een team van computergame-designers aan de slag gaan. Dit betekent niet dat je creativiteit wordt beknot, integendeel. Waar bij het ontwerpteam het volledige verhaal bekend is, inclusief de regels en natuurwetten van de wereld waarin je speelt, is dat niet het geval bij computationeel materiaalonderzoek. Meer nog, vaak is het net je opdracht het verhaal gaandeweg te ontdekken, inclusief de natuurwetten die relevant zijn. Je wordt als het ware een verteller die telkens nieuwe verhalen moet bedenken, of bestaande plots moet aanpassen, uitbreiden of beperken, tot de verhaallijn past in de vorm van de werkelijkheid.
Je staat er gelukkig niet alleen voor om een goede afloop te regelen. Je wordt bijgestaan door je trouwe sidekick: je supercomputer. Deze is in staat met brute kracht de gekste plotwendingen door te rekenen. Op basis van jouw inleidende hoofdstuk, waarin je de wereld en haar natuurwetten schetst, zal hij het verhaal verder laten ontplooien. Door dan de juiste vragen te stellen en de antwoorden met de werkelijkheid te vergelijken kom je erachter waar je verhaal nog niet helemaal in de werkelijkheid past.
Hoe je je inleidende hoofdstuk daarop moet aanpassen verschilt per geval. Soms is het duidelijk wat er aan de hand is: er ontbreekt een cruciaal personage (bijvoorbeeld een onzuiverheidsatoom dat het kristaalrooster verstoord) of het personage woont op de foute plaats (toch niet op de plaats van atoom A, atoom B dan maar?). Moeilijker wordt het als sommige personages weigeren de hun toebedeelde rol te spelen (Die platina-atomen zijn onzichtbaar voor de rastertunnelmicroscoop, wie speelt nu de rol van de zichtbare nanodraad?). De lastigste situatie is wanneer een volledige herschrijving van het inleidende hoofdstuk nodig is. Hierdoor krijg je te veel vrijheid in handen, terwijl het net de gekende beperkingen zijn die je houvast geven bij het opstellen van het verhaal. Je hebt dan een idee nodig dat je een link geeft met de werkelijkheid. Inspiratie kan hier velerlei vormen aannemen en op willekeurig moment komen. Een bekende anekdote is deze van de theoretische chemicus Kekulé, die in een dagdroom een slang zichzelf in de staart zag bijten en daardoor de ringvormige structuur van de benzeenmolecule uitdokterde. Zulke wonderlijk probleemoplossende gedachtenkronkels komen zelden spontaan, maar zijn veeleer het gevolg van lang en intens werk op eenzelfde vraagstuk. Dergelijke situaties drijven je tot het uiterste, je moet je immers iets voorstellen waar je nooit eerder aan gedacht hebt. In managementkringen wordt zoiets “buiten het kader denken” genoemd, wat bedrieglijk eenvoudig klinkt. Je mag immers niet vergeten dat voor onderzoek dit niet betekent dat alles plots toegelaten is (met andere woorden, je mag het kader zeker niet uit het oog verliezen bij het dagdromen).
Als computationeel materiaalonderzoeker moet je dus je almacht over je virtuele wereld combineren met je eigen vermogen nieuwe werelden in gedachten te scheppen, in de hoop zo onderweg een glimp van de buitenwereld in je siliciumchip op te vangen.
Nov 26 2015
In the current academic world, there are two often heard mantra’s: publish more and publish open access. In a world where there are ever more researchers competing for limited financial resources, distribution of these resources needs persistent justification. While funding agencies seem to be in a relentless quest for ‘excellence‘ in research (or just more publications, because that is easily quantifiable), a new side-quest has emerged: ‘open access publication’. This side-quest can either be considered as a move against scientific publishers requesting huge subscription fees from universities or as a further way of justifying what is being done with tax-payer money (with open access the tax-payer can go find out him-/herself ).
The publish or perish culture has lead to the birth of predatory journals and publishers. These journals more and more act as regular journals (e.g. promising/claiming peer review). However, in the end, as long as a publishing fee is paid your paper will get published. Researchers of ill intend can easily get their work published in such journals and as such inflate their CV. Unfortunately, also poorly informed researchers, with no ill intend, can be trapped by such journals. These journals use rather aggressive mailing campaigns (I generally get a few of these e-mails every week on my academic mail account) and present journals with names rather similar to well established journals. Luckily, after a while you start to recognize the usual predatory publishers such as scirp, bentham science publishers or hindawi publishing. The setup of their mailings are rather similar. There are two main types: the professional journal type and the personal interest type. The first setup starts by presenting their journal as brand new and of high interest to field, indicating that the journal is indexed in several listings (giving it the impression of validity) and finally that there is a publishing charge (which generally isn’t that steep, 100-200$). The second type approaches you noting they have read one of your recent publications, and consider it to be of great quality and interest to the world. After sufficient flattery you are then invited to publish new work with them (which can be done at a special discount).
Lately, with the recent quest for open-access publishing (funding agencies/universities requiring of their researchers to publish open access*) these predatory journals moved on. Nowadays, you do not need to pay for publication any longer, you now pay for the “open access” of your work. In my case, the most recent invitation was by intechopen. I was invited to write a chapter in a book on Metal-Organic Frameworks, and since it is open access, it would only cost 670€ in processing charges. No thank you. After a reminder by the publishing process manager I put in the effort to check if they are already blacklisted as a predatory journal/publisher, and yes they are: Jeffrey Beal’s list of predatory publishers. (For the record, if you are invited to write a paper/book-chapter there should be no page/processing charges at all, on the contrary you should actually get a (small) fee.)
This question is becoming harder to answer every year. With open access, also regular publishers have discovered a new gold-mine which they are rather eager to excavate. Also with the huge flood of publications that all need to be reviewed by multiple referees, quality in that area starts to degrade slightly but steadily. So what to do?
*They, however, tend to have conflicting standards in this regard. You are on the one hand encouraged to publish in high impact journals and you are required to publish open access. On the other hand however, no additional funding is provided to pay for the open access costs in high impact journals. These costs are often several thousand euros for one publication, or more than half an FWO bench-fee which is to be used for visiting conferences, buying lab equipment or computational resources.
Nov 13 2015
Authors: | Thomas Bogaerts, Louis Vanduyfhuys, Danny E.P. Vanpoucke, Jelle Wieme, Michel Waroquier, Pascal Van Der Voort, and Veronique Van Speybroeck, |
Journal: | CrystEngComm. 17(45), 8565 (2015) |
doi: | 10.1039/C5CE90198G |
IF(2015): | 3.849 |
export: | bibtex |
pdf: | <CrystEngComm> |
The cover image depicts an X-ray beam hitting a sample of MIL-47(V) Metal-Organic Framework (reddish powder), resulting in an X-ray diffraction pattern. This leads to the atomic structure on the left, Where the spin-densities are indicated for the anti-ferromagnetic ground state. (The related paper can be found here.)
Aug 29 2015
In the previous fortran tutorials, we learned the initial aspects of object oriented programming (OOP) in fortran 2003. And even though our agent-based opinion-dynamics-code is rather simple, it can quickly take several minutes for a single run of the program to finish. Two tools which quickly become of interest for codes that need more than a few minutes to run are: (1) a progress bar, to track the advance of the “slow” part of the code and prevent you from killing the program 5 seconds before it is to finish, and (2) a timer, allowing you to calculate the time needed to complete certain sections of code, and possibly make predictions of the expected total time of execution.
In this tutorial, we will focus on the progress bar. Since our (hypothetical) code is intended to run on High-Performance Computing (HPC) systems and is written in the fortran language, there generally is no (or no easy) access to GUI’s. So we need our progress bar class to run in a command line user interface. Furthermore, because it is such a widely useful tool we want to build it into a (shared) library (or dll in windows).
What do we want out of our progress bar? It needs to be easy to use, flexible and smart enough to work nicely even for a lazy user. The output it should provide is formatted as follows: <string> <% progress> <text progress bar>, where the string is a custom character string provided by the user, while ‘%progress’ and ‘text progress bar’ both show the progress. The first shows the progress as an updating number (fine grained), while the second shows it visually as a growing bar (coarse grained).
- type, public :: TProgressBar
- private
- logical :: init
- logical :: running
- logical :: done
- character(len=255) :: message
- character(len=30) :: progressString
- character(len=20) :: bar
- real :: progress
- contains
- private
- procedure,pass(this),public :: initialize
- procedure,pass(this),public :: reset
- procedure,pass(this),public :: run
- procedure,pass(this),private:: printbar
- procedure,pass(this),private:: updateBar
- end type TProgressBar
All properties of the class are private (data hiding), and only 3 procedures are available to the user: initialize, run and reset. The procedures, printbar and updatebar are private, because we intend the class to be smart enough to decide if a new print and/or update is required. The reset procedure is intended to reset all properties of the class. Although one might consider to make this procedure private as well, it may be useful to allow the user to reset a progress bar in mid progress.(The same goes for the initialize procedure.)
- subroutine run(this,pct,Ix,msg)
- class(TProgressBar) :: this
- real::pct
- integer, intent(in), optional :: Ix
- character(len=*),intent(in),optional :: msg
-
- if (.not. this%init) call this%initialize(msg)
- if (.not. this%done) then
- this%running=.true.
- this%progress=pct
- call this%updateBar(Ix)
- call this%printbar()
- if (abs(pct-100.0)<1.0E-6) then
- this%done=.true.
- write(*,'(A6)') "] done"
- end if
- end if
-
- end subroutine run
In practice, the run procedure is the heart of the class, and the only procedure needed in most applications. It takes 3 parameters: The progress (pct), the number of digits to print of pct (Ix),and the <string> message (msg). The later two parameters are even optional, since msg may already have been provided if the initialize procedure was called by the user. If the class was not yet initialized it will be done at the start of the procedure. And while the progress bar has not yet reached 100% (within 1 millionth of a %) updates and prints of the bar are performed. Using a set of Boolean properties (init, running, done), the class keeps track of its status. The update and print procedures just do this: update the progress bar data and print the progress bar. To print the progress bar time and time again on the same line, we need to make use of the carriage return character (character 13 of the ASCII table):
write(*,trim(fm), advance='NO') achar(13), trim(this%message),trim(adjustl(this%progressString)),'%','[',trim(adjustl(this%bar))
The advance=’NO‘ option prevents the write statement to move to the next line. This can sometimes have the unwanted side-effect that the write statement above does not appear on the screen. To force this, we can use the fortran 2003 statement flush(OUTPUT_UNIT), where “OUTPUT_UNIT” is a constant defined in the intrinsic fortran 2003 module iso_fortran_env. For older versions of fortran, several compilers provided a (non standard) flush subroutine that could be called to perform the same action. As such, we now have our class ready to be used. The only thing left to do is to turn it into a dll or shared library.
There are two types of libraries: static and dynamic.
Static libraries are used to provide access to functions/subroutines at compile time to the library user. These functions/subroutines are then included in the executable that is being build. In linux environments these will have the extension “.a”, with the .a referring to archive. In a windows environment the extension is “.lib”, for library.
Dynamic libraries are used to provide access to functions/subroutines at run time. In contrast to static libraries, the functions are not included in the executable, making it smaller in size. In linux environments these will have the extension “.so”, with the .so referring to shared object. In a windows environment the extension is “.dll”, for dynamically linked library.
In contrast to C/C++, there is relatively little information to be found on the implementation and use of libraries in fortran. This may be the reason why many available fortran-“libraries” are not really libraries, in the sense meant here. Instead they are just one or more files of fortran code shared by their author(s), and there is nothing wrong with that. These files can then be compiled and used as any other module file.
So how do we create a library from our Progressbar class? Standard examples start from a set of procedures one wants to put in a library. These procedures are put into a .f or .f90 file. Although they are not put into a module (probably due to the idea of having compatibility with fortran 77) which is required for our class, this is not really an issue. The same goes for the .f03 or .f2003 extension for our file containing a fortran 2003 class. To have access to our class and its procedures in our test program, we just need to add the use progressbarsmodule clause. This is because our procedures and class are incorporated in a module (in contrast to the standard examples). Some of the examples I found online also include compiler dependent pragmas to export and import procedures from a dll. Since I am using gfortran+CB for development, and ifort for creating production code, I prefer to avoid such approaches since it hampers workflow and introduces another possible source of bugs.
The compiler setups I present below should not be considered perfect, exhaustive or fool-proof, they are just the ones that work fine for me. I am, however, always very interested in hearing other approaches and fixes in the comments.
The windows approach is very easy. We let Code::Blocks do all the hard work.
Creating the dll : Start a new project, and select the option “Fortran DLL“. Follow the instructions, which are similar to the setup of a standard fortran executable. Modify/replace/add the fortran source you wish to include into your library and build your code (you can not run it since it is a library).
Creating a user program : The program in which you will be using the dll is setup in the usual way. And to get the compilation running smoothly the following steps are required:
The entire setup is the same as for the shared library. This time, however, choose the “Fortran Library” option instead of Fortran dll. As the static library is included in the executable, there is no need to ship it with the executable, as is the case for the dll.
For the unix approach we will be working on the command line, using the intel compiler, since this compiler is often installed at HPC infrastructures.
After having created the appropriate fortran files you wish to include in your library (in our example this is always a single file: PBar.f03, but for multiple files you just need to replace PBar.f03 with the list of files of interest.)
ifort -fpic -c -free -Tf Pbar.f03
Where -fpic tells the compiler to generate position independent code, typical for use in a shared object/library, while -c tells the compiler to create an object file. The -free and -Tf compiler options are there to convince the compiler that the f03 file is actual fortran code to compile and that it is free format.
ar rc PBarlib.a PBar.o
ifort TestProgram.f90 PBarlib.a -o TestProgram.exe
Note that also here the .mod file of our Progressbarsmodule needs to be present for the compilation to be successful.
For the shared library the approach does not differ that much.
ifort -fpic -c -free -Tf Pbar.f03
In this case the fpic option is not optional in contrast to the static library above. The other options are the same as above.
ifort -shared PBar.o -o libPBar.so
The compiler option -shared creates a shared library, while the -o option allows us to set the name of the library.
ifort TestProgram.f90 libPBar.so -o TestProgram.exe
Note that also here the .mod file of our Progressbarsmodule needs to be present for the compilation to be successful. To run the program you also need to add the location of the library file libPBar.so to the environment variable LD_LIBRARY_PATH
HPC systems may perform extensive buffering of data before output, to increase the efficiency of the machine (disk-writes are the slowest memory access option)…and as a result this can sometimes overrule our flush command. The progressbar in turn will not show much progress until it is actually finished, at which point the entire bar will be shown at once. There are options to force the infrastructure not to use this buffering (and the system administrators in general will not appreciate this), for example by setting the compiler flag -assume nobuffered_stdout. So the best solution for HPC applications will be the construction of a slightly modified progress bar, where the carriage return is not used.
Special thanks also to the people of stack-exchange for clarifying some of the issues with the modules.
Source files for the class and test-program can be downloaded here.