New Program!

The new program for doing electron-nuclear dynamics is now in progress. I settled on a name, too: Python Accelerated Coherent states Electron-nuclear dynamics = PACE.

So far, it can handle basis sets using NWChem-like syntax, geometry in Angstrom or Bohr, perform UHF SCF and gradients, has geometry optimization using steepest descent, and has a job database system. Some of the ideas in NWChem are shamelessly copied. After all, imitation is the sincerest form of flattery. As an aside, the design philosophy of NWChem is excellent, but I think they made a grave error in committing to Fortran as the language.

This program is basically a set of tools implemented as Python modules. The job interpreter just strings together basic tasks in a user-friendly way. For example, the algorithm for geometry optimization should not have to be aware of all possible theories for computing energy and gradients and the user should just be able to specify a level of theory and start the optimization.

Python allows rapid prototyping, getting an algorithm hammered out and bugs identified and fixed. One of the really beautiful features is that once a procedure has been solidified, it can be made faster by implementing it in C++. In this way, data flow is performed in Python (where it is easy to handle) and computational bottlenecks are compiled and hence very fast.

I just finished getting UHF gradients to work after a peculiar bug that caused diatomics having p-orbitals to be computed incorrectly. Now the normal Born-Oppenheimer molecular dynamics algorithms are conserving energy. Once I finish this test run, I will be able to have a direct comparison with CSTechG (the old code), both in results and time taken.

CUDA bug - sort of

We just got an ASUS GeForce GTX 470 (Fermi, 1280MB RAM) to use when HPCC is unreliable. (The CUDA server went down once already, with the SCSI driver complaining about the hardware and the fs crapping all over itself. Their "fix" was to reboot.) I did not think about the power consumption of the card: it draws 250W by itself. The recommended power supply is 550W, but this computer has 525W. So far, it works.

The point of this post is actually an annoying "bug" that I could not find a direct answer to online. Specifically, when I compiled CSDFT on my local machine, the kernels would not run, failing with the error "invalid device function." For the vast majority of posts online, this is a problem in Windows or using device emulation mode. Neither of those apply. While the programming guide states that compute capability is backward-compatible, I found that the kernels would not run at all unless I specified -arch=sm_20 in the compilation (compiling for capability 2.0 instead of 1.3). For the new program, I will have to see how to support both compute capabilities in a consistent way.

First bit of real business

So, we are creating a new program to run dynamics that will replace CSDFT nee CSTechG nee ENDyne. Your challenge, should you choose to accept it, is to come up with a snappy name.

I have been playing with the idea of making a backronym from the name of a god of change, see below.

Roman - Janus

Greek - Vertumnus

Hindu - Kali

Additionally, the Greek gods Hecate (crossroads) and Chronos (time) are in the running. (Tartarus comes to mind, but I don't think Morales will go for it.)

Inaugural Post

If you are reading this message, you successfully found the technical blog for Mustela Technica. The purpose of this blog is to journal the development of new technologies in the Jorge Morales group at Texas Tech University. However, there is a conundrum: certain research details need to be kept private to prevent being scooped. I was playing with the idea of secure timestamping, but it looks like it will be more practical to simply record the posts and make them public when safe. Alternately, I can abstract enough specifics to allow general posts which can be clarified when the project status is public.