next up previous contents
Next: Resources and Bibliography Up: ATOMS 3.0 Documentation Previous: Experimental Corrections

   
Contributing to the ATOMS Project

As mentioned in the Abstract of this document and in Frequently Asked Question [*], ATOMS is Open Source software. Among other things, this means that I welcome contributions to the effort. Someday ATOMS will be part of a large, sophisticated x-ray absorption spectroscopy theory and analysis package. Before that happens, lots of chores need to be finished. Eventually, I will get around to doing everything that needs to be done with ATOMS, but I am quite eager for any interested parties to step up and offer code or other useful services. I cannot offer fame, fortune, and glory to anyone who helps out, but I can offer my profound gratitude and a prominent spot for your name in the document.

Here is a list of things that remain undone as of ATOMS 3.0beta1. They are in no particular order and they range in size from fairly quick and easy to fairly challenging. One could surely think of other interesting things to do. Virtually any contribution will be welcomed. Suggestions, comments, criticisms, and bug reports (see FAQ [*] on page [*]) are also quite welcome.

Write a good algorithm for reading arbitrary angles.
OK, this one is not really that hard, but I have been too lazy to do it. The idea is that one might write eighty seven and one half degrees as 87 30'. What I am looking for a is a fast, reliable algorithm for correctly interpreting decimal degrees or minute/seconds. The algorithm should be highly fault tolerant. 87 30', 87.5, 87 30m, 87 29' 60", 87 29m 60s, and other sensible combinations, including varying amounts of whitespace, should all evaluate to the same number of radians.
Generalize the self-absorption correction
The self-absorption correction calculated in the 'Atoms.pm' module uses the assumptions of infinite thickness and equal entry and exit angles. This would be easy enough to modify.
Translation of language data
I already have a good start on the Spanish translation thanks to Dani Haskel and a mostly complete French translation thanks to Stephane Grenier. Other languages would be great. Soon (i.e. with Perl 5.6) we will have the possibility of multi-byte languages, such as Japanese, Chinese, and Korean. I estimate that a native speaker who is reasonably fluent in English could finish a translation about 6 hours spread out over a few days. Contact me for how to get started.
Translations of element names
I have already started work on the internationalization of APT, but I am lacking a way of getting element names in any language. Chemistry::Elements provides object methods for handling element data. It seems that a good way of internationalizing element names would be to use it. A few hours of coding plus a few hours of collecting element names in other languages.
Object methods for reading molecular structure data
By this I mean reading, for example, a BNL Protein Data Bank file, parsing out the atom coordinates and storing them in an appropriate data structure. The Xray::File module is a start on this, but it doesn't do much yet. I would be happy to write a test harness for anyone interested in working on this. I suspect that it would take a day or two get a single inherited method working and tested once the basic structure of Xray::File is clear. Others should then go faster.
Streamline the Mac distribution
The 'atoms.pl' and 'dafs.pl' programs (i.e. the non-Tk programs) work fine on the Mac, but there are some installation difficulties. I would love to see a streamlined pure-perl installation procedure for the Mac. This should be a day or two of work for someone who knows both Perl and the Mac pretty well.
Write a GUI for the Mac using Chris Nandor's Mac-GUI toolkit.
Unless perl/Tk ever gets ported, this is the only good way of doing a Mac GUI. This is probably a pretty big project. Perhaps it would be better to help with the Mac port of perl/Tk or wait for the holy grail of OS X.
Help me test the distribution on platforms I do not have access to.
I develop ATOMS on Linux and can get my hands on HP workstations and a Windows 95 box. With some more difficulty, I can get onto a Sun Station and an SGI machine. That leaves out a lot of important platforms! Are you using something else? Let me know how it goes.
Help me port ATOMS to VMS
The Tk part may be a bit tricky. The last time I looked, the VMS port of perl/Tk was incomplete. This could be a sizable chore, although I have been careful about things like file paths. ATOMS runs on the Mac, after all!
Port the Cromer-Liberman Kit to new platforms.
This currently works on SGI and Linux. Porting to other Unixes shouldn't be too hard. In fact, I cannot imagine it would take me more than an hour or two for any platform if I set my mind to it. I suspect it would be possible for both Windows and the Mac, but it would require some familiarity with those development environments. You need to compile Fortran source code into a shared object and link it with some C code.
Niftier appearance of WebATOMS
It would be nice to use style sheets to make the web application look extra spiffy. A style sheet for the html version of the document would be great also.
Input file database
It would be handy to build some kind of database architecture for storing ATOMS input files in a way that ATOMS, TkATOMS, and WebATOMS can all get at them. Using real DB concepts (B-trees, queries, and so on) seems appropriate so that the database can scale well.
Write the framework of a ball-and-stick browser
I am thinking that the perl/OpenGL interface is the way to go, but its all rather opaque to me. If someone with experience in OpenGL or Mesa could help me get started, that would be splendid. This is a huge project.


next up previous contents
Next: Resources and Bibliography Up: ATOMS 3.0 Documentation Previous: Experimental Corrections

2001-01-14