Tag: STM

Creating online forms and catching spam-bots

Recently, I decided to add a custom registration formĀ  to my website, as part of an effort to improve and streamline the “HIVE-STM tool experience” šŸ˜‰ . Up until now, potential users had to directly send me an e-mail, telling me a bit more about themselves and their work. I would then e-mail them the program, and add their information to a user list for future reference (i.e., support and some statistics for my personal entertainment).

This has the drawback that any future user needs to wait until I find the time to reply. To improve on the user-friendliness, I thought it would be nice to automate this a bit. A first step in this process entails making the application a bit more uniform: using an online registration form.

The art of learning something new: Do it from scratch

What started out with the intention of being an almost trivial exercise in building a web-form, turned into a steep learning curve about web-development and cyber-security. I am aware there exists many tools which generate forms for websites or even provide you a platform which hosts the form (e.g., google-forms, which I used in the past), but I wanted to do implement it myself (…something to do with pride šŸ˜‰ ). Having build websites using HTML and CSS in the past, and having some basic experience with Javascript, this looked like a fun afternoon project. The HTML for the form was easily created using the tutorials found on w3schools.com and an old second edition “Handboek HTML5 en CSS3“, I picked up a few years ago browsing a second hand bookshop. Trouble, however, started rearing its ugly head as soon as I wanted to integrate this form in this WordPress website. Just pasting this into a page or post doesn’t really work, as WordPress wants to “help” you, and prevent you from hurting yourself. This is a fantastic feature if you have no clue about HTML/CSS/… or don’t want to care about it. Unfortunately, if you want to do something slightly moreĀ  advanced you are in for a hell of a ride, as you find out the relevant bits get redacted or disabled.

Searching for specific solutions with regard to creating a custom form in WordPress I was astounded at how often the default suggestion is: “use plugin XXX” or “use tool YYY”. Are we loosing the ability to want to craft something ourselves? Yes of course, there are professional tools available which can be better than anything you yourself can build in a short amount of time…but should it discourage you of trying, and feeling the satisfaction of having created something? I digress.

In the end, I discovered a good quality tutorial (once you get past the reasons why not to do it) and I started a long uphill battle trying to bend WordPress to my will:

  1. Paste form-code in post ā‡’ WP countermove: remove relevant tags essentially killing the form.
  2. Solution: put the form in a dedicated templateĀ ā‡’ WP countermove: hard to integrate in existing theme, will be removed upon update of the theme
  3. Solution: create a child-themeĀ ā‡’ WP countermove: interesting exercise is getting the CSS style-sheet to work together with that of the parent theme. (wp_enqueue_style, wp_enqueue_scripts, get_template_directory_uri() and get_stylesheet_directory_uri() saved the day.)
  4. Add PHP back-end to the form…and deal with the idiosyncrasies of this scripting language. Crashed the website a few time due to missing “;”… error messages would be nice, instead of the blank web-page.

 

Trying not to torture future users

At this point, the form accepted input, and collected it via the PHP $_POST global variable. En route to this point, I read quite a few warnings about Cross-Site Request Forgery (CSRF) and that one should protect against it. Luckily, the tutorial practically showed how to do this in WordPress using nonces…in contrast to WordPress theme handbook which gives in formation, but not easy to understand if you are new to the subject.

With a basic sense of security, I was aiming at making things user-friendly, i.e., if something goes wrong it would be nice if you do not need to again fill out the form entirely. Searching for ways to keep this information I came across a lot of options, none of which seemed to work (cookies, PHP variables, global variables, etc). The problem appeared to originate from the fact that the information was not persistent. Once the web page started reloading, everything got erased. It was only at this point that I learned about “transients” in WordPress, and using get_transient() and set_transient() resolved all the issues instantaneously. There is only one caveat at this point: If two potential users submit their registration at almost the same time one may end up seeing the registration information of the other. (However, at this time the program is far from famous enough to present any issues, so statistics will save us from this).

Only one thing remained to be done: put all relevant information into two e-mail messages, one to be sent to myself, and one to be sent to the potential user. For this, I made use of the PHP mail() function. It works quite nicely, and after playing around with it for a bit (and convincing myself a nice HTML formatted layout will not work for example in gmail) the setup was complete. That evening, I went to bed, happy with the accomplishment: I had created something.

Too popular for comfort

Bot Activity on the HIVE registration form during February and March of 2021.

Bot Activity on the HIVE registration form during February and March of 2021.

The next morning, I was amazed to find already several applications for the HIVE-STM program in my mailbox (that is, in addition to my own test runs). These were not sent by real humans, but appeared to be the work of bots just filling out the form and sending it off. This left me a bit puzzled, and I have been looking for the reason why anyone would actually bother writing a bot for this purpose. So far I’ve seen the suggestion that this is to improve the SEO of websites, generate spam-email (to yourself or with you as middleman), DOS-attacks, get access to your SQL database via code injection,…and after all my searches, I start to get the impression this may also be a means of promoting all the plugins, tools, frameworks that block these bots?Ā In roughly each discussion you find, there will be at least one person promoting such a foolproof perfect tool šŸ˜Æ šŸ™„ …but might just be me.

So how do we deal with these bots, preferably without driving potential users crazy? Reading all the suggestions (which unfortunately provide extremely little information on the actual working and logic of spam-bots themselves) I added, in several rounds, some tricks to block/catch the bots, and have been tracking the submits since the form went live. As you can see there is a steady stream of some 50 bots weekly trying to fill out the form. The higher number in the first week is due to any submission being redirected to the original form page, as such the same bots performed multiple attempts within the time-range of a few minutes. In about two months, I collected the results of 400 registration attempts by bots (and 4 by humans).

Analyzing the results, I learned learned some interesting things.

How to catch a bot? I track 4 different signals which may be indicative of bot behavior.

How to catch a bot? I track 4 different signals which may be indicative of bot behavior.

1. To Captcha or not to Captcha?

One of the first things to add, from a human perspective is “a captcha”. The captcha is manually implemented simple random sum/product/subtraction. It should be easy for humans, but it is annoying as they need to fill out an extra field (and may fill it out incorrectly). Interestingly, 56% of the bots fill out the Captcha correctly. Of course more complicated versions could be implemented or used…but the bottom line is simple: it generally does not do the job, and annoys the actual human being.

2. Bot Trapping for furs?

Going beyond captcha’s, a lot of tutorials suggest the use of a honeypot. One can either make use of automated options of existing frameworks, plugins or …implement these oneself. This option appears to be very successful in targeting bots. The 1% successful cases coincided with the only human submissions. At this point we appear to have a “fool-proof” method for distinguishing between humans and bots.

3. Dropping the bot down the box?

Interestingly, drop-down menu’s with not generally used topics seem to throw off bots as well. The seniority drop-down menu shows failure rates even better than the captcha.

Conclusion

Writing your own form from scratch is a very interesting exercise, and well worth the time if you want to learn more about web-security as well as the inner workings of the framework used for your website. Bots are an interesting nuisance, and captcha’s just bother your user as most bots can easily deal with them. Logging the inputs of the bots does show a wide range in quality of these bots. Some just fill out garbage, while others appear to be quite smart, filling out reasonable answers. Other bots clearly have malignant purposes, which becomes clear from the code they try to plug into the form fields.

For now, the registration form seems to be able to distinguish between human-and bot-users. As such, we have successfully completed another step in upgrading the STM-program.Ā 

A new life for the HIVE-STM program

“Once upon a time, there was a young researcher studying the formation of Pt nanowires on Ge substrates using quantum mechanical simulations. The results of the experimental counterparts were excellent; they provided Scanning Tunneling Microscopy images of ridiculously high quality …but not really atomistic structural information or detailed electronic band structures. On the other hand, the calculation-software of the young researcher provided only ground state energies and electronic band structures…but no Scanning Tunneling Microscopy images. So the young researcher set out to resolve this discrepancy.”

About 15 years ago, when starting out as a fresh Ph.D. student, I faced this mismatch between what my calculations could do and what my experimental counterparts had on offer. High quality ground state energies are nice, but rather useless in an experimental context governed by meta-stable states and high temperature transitions (especially since DFT represents only 0K results). I had to find a way to connect my calculations directly to the available experimental data, which boiled down to simulating Scanning Tunneling Microscopy (STM) images.

Original Delphi program: Graphene

Original Delphi program: Graphene

At that time, my programming skills were still nascent, but I felt king of the world knowing both pascal/Delphi and C/C++. I had written toy-programs in both languages, going from a text based battleships in turbo-pascal over a brick-buster game in C/C++using the djgpp compiler and allegro library to create the GUI, and many GUI programs in Delphi (e.g., the programs needed to numerically calculated Bose-Eistein condensation behavior for molecular condensates during my masters thesis). Based on those experiences, I knew that writing a GUI programĀ  was much more straight forward in Delphi. So I set out writing my STM program using Delphi in the year(s) 2005-2006**. On the right you can see an screenshot of this program, generated today 15 years later, on the electron density of graphene. The program written in windows XP, ran smoothly and without modification or required recompile on both windows 7 and the current windows 10. Not to bad, if I say so myself. Try that with a python “program” šŸ˜ˆ .[1]

Free-standing Pt-induced nanowire on Ge(001).

Simulated STM image of the Pt-induced nanowires on the Ge(001) surface. Green discs indicate the atomic positions of the bulk-Ge atoms; red: Pt atoms embedded in the top surface layers; yellow: Ge atoms forming the nanowire observed by STM.

The program was designed to work for my specific use-case at the time: a germanium 001 surface, with a nice rectangular surface unit cell (see figure on the left). This has the unfortunate consequence that systems with a non-rectangular unit cell appear skewed, as is seen for the graphene example above. However, as I never needed such systems myself, no fix was ever included.

After presenting STM results in my first published paper in 2008,[2] I got some questions if it was possible to share the program. I shared the program on an as-is basis: free to use, and I hope it works for you as well, but no support.

Reading the above you may wonder: “Why didn’t you put the source on GitHub, such that other people could collaborate with you on it, and extend it and fix bugs?” The answer is rather simple (and sobering at the same time): GitHub didn’t exist yet when I wrote the program, as it was founded only in February 2008. It grew rapidly since then (surpassing SourceForge in mid 2011), but as I was working on other projects there was no time to support such a setup.

The number of people asking for the program grew steadily, and there was the nagging feeling at the back of my head that I should really clean up the code and make it cross-platform. In 2011, I had a short period when I decided to start from scratch and write the program anew in Java. Unfortunately, my available time ran out, and initial tests showed the program had a hard time reading the large charge-density files fast. So the original Delphi version remained in use being distributed to new users. By September 2012, this program developed for my own purposes had been requested by 100 researchers (which is a lot considering the boundary conditions: (1) needing atomic scale STM simulationsĀ  and (2) using VASP for DFT calculations), and over 200 researchers had requested it by 2015. Currently, in January 2021, the counter indicates over 400 requests. Still the same piece of software, being used by people I never imagined would be interested on OS’s it was never designed for. Despite its simplicity, this unexpected interest makes me extremely proud. šŸ˜ŽĀ 

Distribution of users over the continents and evolution of requests over the years.

Distribution of users over the continents and evolution of requests over the years.

Thorny roses: Some issues popping up

Given the original intent of the program and its eventual use, one should not be amazed that some issues popped up over the years. However, no serious bugs were encountered (which still amazes me).

  • Non-orthogonal surface units: This is the oldest known limitation of the program. It assumes a rectangular surface unit as it uses the direct grid used in the VASP CHGCAR file as a pixel grid. This suited my own purposes well, but is unfortunate for the user studying hexagonal surfaces.
  • “Smart” Antivirus software (1): In the early days, I just sent a zipfile with the program and manual to new users. Unfortunately, AVs do not like people mailing executables, leading to mails being blocked. For some time the problem could be circumvented by zipping the zipfile and later even renaming the extension of the second zip round to prevent the AV of trying to look inside. I know, one should not do this and applaud the AVs for protecting their users, as people did spread trojan horses and other viruses like this back in the days. (Who clicks on those strange attachments anyhow?) So we ended up storing the program and zip online with password protection. We are not yet safe of AVs as some still complain about the risks of downloading things of the internet…but at least we are not (yet) back at the automatic shredding of the program.
  • “Smart” Antivirus software (2): Ā Did I say the program was written in Delphi? Apparently so were a lot of computer viruses and worms. (Must be a sign of being a nice and easy to use language šŸ™‚ ) With smart AVs training on pieces of code from such fraudulent software it becomes rather hard to write any code using Delphi which has not been part of a virus…and thus your program gets flagged. Some AVs are nice enough to tell the user, and even provide an option to keep the program. Others just shred it without even mentioning it (not cool). This is unfortunately becoming more of a problem. Online multi-virus-scanners give a rather bleak picture, as can be seen below.

    smart AVs giving false positives on the old HIVE executable.

    smart AVs giving false positives on the old HIVE executable.

  • Windows 10: Extending on the previous, windows 10’s anti-virus protection follows suit trowing up warnings and messages of possible security threats.
  • Mac and 64bit: Although the program was written for windows, it also runs smoothly in unix environments when using an emulator such as Wine, making the program available to Linux and Mac users as well. Unfortunately since the Mac OS version Catalina, Mac has dropped support for 32bit executables, making it no longer possible to run the 15 year old executable. [1] Remember that in 2006 64bit programs were new and not generally supported. Furthermore, 32bit executables tend to work smoothly on a 64bit system, they just “waste” half the memory.

 

The Future of HIVE-STM

Over the years, I’ve often considered it time to clean up the code, and upgrading it. Unfortunately time was always a major issue. In addition, I no longer had a working Delphi compiler so I was lured to the idea of rewriting it in a different programming language (I seriously considered reworking it in fortran, though the easy access to a GUI stopped me from doing this).

The latest issue with Macs and the zealous persecution of Delphi programs by AVs finally got me to the point of starting a full rework of the HIVE-STM program as a hobby project. The maturity of the Lazarus IDE and free-pascal compiler is an important second component. During the summer holidays of 2020, I started porting the original Delphi code to the Lazarus IDE and free-pascal. This successful port gave me the courage to continue working on it, and I am currently performing a full rewrite of the internals (so far things have gone smoothly). The new version will become available via GitHub once I am confident it is working well and a have setup a good method of keeping track of new users.

New years resolution 2021:
“Finally build a new ‘updated’ version of HIVE-STM “

 

References

[1]Challenge to scientists: does your ten-year-old code still run?“, J.M. Perkel, nature technology feature, august 24th 2020.
[2]Formation of Pt-induced Ge atomic nanowires on Pt/Ge(001)“, D.E.P. Vanpoucke & G. Brocks, Phys. Rev. B 77, 241308(R) 2008.

HIVE-STM: A simple post-processing tool for simulating STM

While I was working on my PhD-thesis on Pt nanowires at the university of Twente, one of the things I needed was a method for simulating scanning-tunneling microscopy (STM) images in a quick and easy way. This was because the mainĀ experimental information on on these nanowires was contained in STM-images.

Because I love programming, I ended up writing a Delphi-program for this task. Delphi, being an Object Oriented version of the Pascal-programming language containing a Visual Components Library, was ideally suited for writing an easy to use program with a graphical user interface (GUI). The resulting STM-program was specifically designed for my personal needs and the system I was working on at that time.

In August 2008, I was contacted by two German PhD students, with the request if it would be possible for them to use my STM program. In October, an American post-doc and a South-Korean graduate student followed with similar requests, from which point onward I started getting more and more requests from researchers from all over the world. Now, seven years later, I decided to put all “HIVE-users” in a small data-base just to keep track of their number and their affiliation. I already knew I send the program to quite a lot of people, but I was still amazed to discover that it wereĀ 225 people from 34 countries.

Hive Requests December 2015

Bar-graph showing the evolution in requests for the HIVE-STM program.

There is a slow but steady increase in requests over the years, with currently on average about one request every week. It is also funny to see there was a slight setback in requests both times IĀ started in a new research-group. For 2015, the data is incomplete, as it does not include all requests of the month December. Another way to distribute the requests is by the month of the year. This is a very interesting graph, since it clearly shows the start of the academic year (October). There are two clear minima (March and September), for which the later is probably related due to the fact that it is the last month of before the start of the academic year (much preparation for new courses) and, in case of the solid state community, this month is also filled withĀ conferences. The reason why there is a minimum in March, however, escapes me ( šŸ’” all suggestions areĀ welcome šŸ’” ).

Hive requests per month.

Distribution of requests for the HIVE-STM program on a monthly basis.

The geographic distribution of affiliations of those requesting the STM-program shows Europe, Azia and America to take roughly equal shares, while African affiliations are missing entirety. Hopefully this will change after the workshop onĀ visualization and analysisĀ of VASP outputsĀ delivered atĀ theĀ Center for High Performance Computing‘s 9th National Meeting in South Africa by Dr. David Carballal. By far the most requests come fromĀ theĀ USA (57), followed by China(23) and then Germany(15). South-Korea(14) unexpectedly takes the fourth place, while the fifth place is a tie between the UK, Spain and India(12 each).

Hive requests demographics 2015

Distribution of Hive requests per country and continent.

All in all, the STM program seems to beĀ of interest to many more researchers than I would have ever expected, and has currently been cited about 25 times, so it is time to add a page listing these papers as examples of what can be done with HIVE(which has in the mean time been done, check out useful link nĀ°2).

Happy Hiving to all of you, and thank you for your trust.

 

UsefulĀ link:
[1] More information on the HIVE-STM program and how to acquire it.

[2] List of publications using and citing the HIVE-STM program.

Modeling 1D structures on semiconductor surfaces: Synergy of theory and experiment

Authors: Danny E. P. Vanpoucke
Journal: J. Phys.: Condens. Matter 26(13), 133001 (2014)
doi: 10.1088/0953-8984/26/13/133001
IF(2014): 2.346
export: bibtex
pdf: <J.Phys.Condens.Matter> <arXiv>

Abstract

Atomic scale nanowires attract enormous interest in a wide range of fields. On the one hand, due to their quasi-one-dimensional nature, they can act as an experimental testbed for exotic physics: Peierls instability, charge density waves, and Luttinger liquid behavior. On the other hand, due to their small size, they are of interest not only for future device applications in the micro-electronics industry, but also for applications regarding molecular electronics. This versatile nature makes them interesting systems to produce and study, but their size and growth conditions push both experimental production and theoretical modeling to their limits. In this review, modeling of atomic scale nanowires on semiconductor surfaces is discussed, focusing on the interplay between theory and experiment. The current state of modeling efforts on Pt- and Au-induced nanowires on Ge(001) is presented, indicating their similarities and differences. Recently discovered nanowire systems (Ir, Co, Sr) on the Ge(001) surface are also touched upon. The importance of scanning tunneling microscopy as a tool for direct comparison of theoretical and experimental data is shown, as is the power of density functional theory as an atomistic simulation approach. It becomes clear that complementary strengths of theoretical and experimental investigations are required for successful modeling of the atomistic nanowires, due to their complexity.

Pt Nanowires on Ge(001): Sheep in Wolf’s Clothing?

Authors: Danny E. P. Vanpoucke
Journal: Belgian Physical Society Magazine 3, 11-16 (2011)
(Featured Article for the BĪ¦)
pdf: <local>

Abstract

The deposition of small amounts of platinum on a germanium (001) surface gives rise to the formation of monatomic nanowires. These nanowires are defectā€“and kink-free and their length is only limited by the underlying terrace, to which they are uniquely connected. Using ab initio calculations and simulated scanning tunneling microscopy (STM) images we model these nanowires, and show them to consist of germanium atoms, in contrast to earlier proposed models.

CO adsorption on Pt-induced Ge nanowires

Authors: Danny E. P. Vanpoucke and Geert Brocks
Journal: Phys. Rev. B 81, 235434 (2010)
doi: 10.1103/PhysRevB.81.235434
IF(2010): 3.774
export: bibtex
pdf: <Phys.Rev.B> <arXiv>

Abstract

Using density-functional theory, we investigate the possible adsorption sites of CO molecules on the recently discovered Pt-induced Ge nanowires (NWs) on Ge(001). Calculated scanning tunneling microscope (STM) images are compared to experimental STM images to identify the experimentally observed adsorption sites. The CO molecules are found to adsorb preferably onto the Pt atoms between the Ge nanowire dimer segments. This adsorption site places the CO molecule in between two nanowire dimers, pushing them outward along the NW direction, blocking the nearest equivalent adsorption sites. This explains the observed long-range repulsive interaction between CO molecules on these Pt-induced nanowires.

Pt-induced nanowires on Ge(001): A density functional theory study

Authors: Danny E. P. Vanpoucke and Geert Brocks
Journal: Phys. Rev. B 81, 085410 (2010)
doi: 10.1103/PhysRevB.81.085410
IF(2010): 3.774
export: bibtex
pdf: <Phys.Rev.B> <arXiv>

Abstract

We study formation of the nanowires formed after deposition of Pt on a Ge(001) surface. The nanowires form spontaneously after high-temperature annealing. They are thermodynamically stable, only one atom wide and up to a few hundred atoms long. Ab initio density functional theory calculations are performed to identify possible structures of the Pt-Ge(001) surface with nanowires on top. A large number of structures are studied. With nanowires that are formed out of Pt or Ge dimers or mixed Pt-Ge dimers. By comparing simulated scanning tunneling microscopy images (STM) with experimental ones we model the formation of the nanowires and identify the geometries of the different phases in the formation process. We find that the formation of nanowires on a Pt-Ge(001) surface is a complex process based on increasing the Pt density in the top layers of the Ge(001) surface. Most remarkably we find the nanowires to consist of germanium dimers placed in troughs lined by mixed Pt-Ge dimer rows.

Density functional theory study of Pt-induced Ge(001) reconstructions

Authors: Danny E. P. Vanpoucke and Geert Brocks
Journal: Phys. Rev. B 81, 035333 (2010)
doi: 10.1103/PhysRevB.81.035333
IF(2010): 3.774
export: bibtex
pdf: <Phys.Rev.B> <arXiv>

Abstract

Pt deposited on a Ge(001) surface spontaneously forms nanowire arrays. These nanowires are thermodynamically stable and can be hundreds of atoms long. The nanowires only occur on a reconstructed Pt-Ge-surface where they fill the troughs between the dimer rows on the surface. This unique connection between the nanowires and the underlying substrate make a thorough understanding of the latter necessary for understanding the growth of the nanowires. In this paper we study possible surface reconstructions containing 0.25 and 0.5 of a monolayer of Pt. Comparison of calculated scanning tunneling microscope (STM) images to experimental STM images of the surface reconstruction reveal that the Pt atoms are located in the top layer, creating a structure with rows of alternating Pt-Ge and Ge-Ge dimers in a c(4Ɨ2) arrangement. Our results also show that Pt atoms in the second or third layer cannot be responsible for the experimentally observed STM images.

Ab Initio study of Pt Induced Nanowires on Ge(001)

Authors: Danny E.P. Vanpoucke
Ph.D. Thesis at University of Twente, The Netherlands
date: September 11th, 2009
Promoters Prof. Dr. Paul J. Kelly and Dr. Geert H. L. A. Brocks
doi: 10.3990/1.9789036528733
ISBN: 978-90-365-2873-3
#pages 193
export: bibtex
pdf: <PhD.Thesis> <UTwente>
researchĀ page with more information

Abstract

The aim of this thesis: ā€œAb Initio Study of Pt Induced Nanowires on Ge(001)ā€, is to model the experimentally observed ā€˜Pt nanowiresā€™ on Ge(001). These one-atom-thick wires can be hundreds of nanometers long while remaining defect and kink free, providing the ultimate wire any chip designer dreams of. However, experiments show the wires not to be conducting; on the contrary, one-dimensional states are discovered between the wires. To model these nanowires, we combine state of the art density functional calculations with calculated scanning tunneling microscope (STM) images. First, the Ī²-terrace substrate is modeled, showing a checkerboard pattern of Pt-Ge and Ge-Ge surface dimers in a Ge(001)-reconstructed surface.

Starting from this substrate model, different models with increasing Pt density are developed in an iterative fashion showing increasing agreement with the experimentally observed nanowires. We show that, contrary to previous assumptions, the observed wires are not Pt atoms but Ge atoms, explaining the lacking conductivity. The germanium nanowires consist of Ge dimers located in a Pt-lined trough. In addition, the 4Ɨ1 periodicity observed in the nanowire-arrays is traced back to the bonds of the Ge nanowire dimers to an extra Pt atom at the bottom of the trough, resulting in the buckling of the nanowires dimers.

In the last part of the thesis we investigate the adsorption of CO on the Ge nanowires under study. The observed adsorption of CO seems to contradict our proposed model due to the high sticking probability of CO on Pt, where it is low on Ge. We show that no contradiction exists. The CO molecules bind to the Pt atoms in the surface, but because they are tilted toward the nanowires, the resulting STM images give the impression that they are located on top of the nanowire giving rise to the apparent contradiction. In this last study, we also discover a very stable CO adsorption configuration in which the CO molecules remain invisible for STM, but could allow for the formation of one-dimensional molecular chains. This would open the door to one-dimensional molecular electronics.

Front cover of the PhD thesis.

The formation of Self-Assembled Nanowire Arrays on Ge(001): a DFT study of Pt Induced Nanowire Arrays

Authors: Danny E. P. Vanpoucke and Geert Brocks
Book title: Symposium Zā€“Computational Nanoscienceā€“How to Exploit Synergy between Predictive Simulations and Experiment
proceeding: Mater. Res. Soc. Symp. Proc. 1177, 1177-Z03-09 (2009)
doi: 10.1557/PROC-1177-Z03-09
export: bibtex
pdf: <MRS Proceeding> <arXiv>

Abstract

Nanowire (NW) arrays form spontaneously after high temperature annealing of a sub monolayer deposition of Pt on a Ge(001) surface. These NWs are a single atom wide, with a length limited only by the underlying beta-terrace to which they are uniquely connected. Using ab-initio density functional theory (DFT) calculations we study possible geometries of the NWs and substrate. Direct comparison to experiment is made via calculated scanning tunneling microscope (STM) images. Based on these images, geometries for the beta-terrace and the NWs are identified, and a formation path for the nanowires as function of increasing local Pt density is presented. We show the beta-terrace to be a dimer row surface reconstruction with a checkerboard pattern of Ge-Ge and Pt-Ge dimers. Most remarkably, comparison of calculated to experimental STM images shows the NWs to consist of germanium atoms embedded in the Pt-lined troughs of the underlying surface, contrary to what was assumed previously in experiments.