PyDaylight More Science, Less Time

• Need fast turnaround
• Get an idea, try it out
• The faster you can refine your idea, the better.

• Throw it away if it doesn't work.

One way is to use computers as an exploration tool

• Make the computers go fast
• Make it easy to write and modify programs
  • Programs can mean macros, scripts or applications

This graph is from Dave's talk at EuroMUG'98.

Doubling rate of chemical data is 20 years, compared to 18 months for processors.

I believe the bottleneck is writing and customizing software, and making the different tools work together.

> To make that happen, Wal-Mart will purchase a Pentium Pro-powered
> NCR WorldMark 5100M massively parallel processing server and upgrade
> an existing 5100M machine. The new machine will have 32 nodes, 256
> 200-MHz Pentium Pro chips, and 8 terabytes of storage, while the
> upgraded machine will move from 32 nodes to 96 nodes, 768 processors
> and 16 terabytes of storage.

• modular design
• orthogonal components
• abstractions
• ...

The Daylight toolkit has these, but they are hidden under a layer of C and behind opaque, untyped handles. There are better ways!

• Object-oriented programming
  A molecule is a molecule, not an integer handle. A molecule has atoms. An atom has charge. You've all heard about OO programming so I won't go into detail.

• Exceptions
  Explicit error checking doubles the amount of code you write. More clutter. More code means more chances for error, and errors in error checking code is harder to find.

  Exceptions allow you to omit most error checks, but still catch problems. Plus, diagnostics are better since exceptions point out exactly where an error occured.

• Automatic Memory Management
  Usually called garbage collection. About 20% of the toolkit calls are to dt_dealloc, so it's important. But it's hard to know when something should or shouldn't be dealloced (should you call dt_dealloc on a fieldtype?). You've all dealt with memory leaks. There are ways to deal with them automatically.

There has to be a way to reduce the needless complexity of programming, without simplifying the meaning!

For the last few years I've been exploring very high level languages as a solution.

• Tcl - most programmers don't like it
• Perl - most scientists (non-programmers) find Perl too complicated
• Python - used and enjoyed by both

Python is a dynamically-typed language which supports both procedural and object-oriented programming models. It is very easy to interface with existing C and C++ code, which is reflected in the large number of available modules. For more info, try www.python.org.

Norah and I worked on a demonstration web viewer for the VCS data. Overall it took about three days to write and debug. Try it out at http://sun5/cgi-bin/vcs_viewer/index.cgi.

Here's the source code:

  config.py
  login.cgi
  logout.cgi
  index.cgi
  utilities.py
  query.cgi
  search.cgi
  tdt2html.cgi
  Cookie.py

Depiction Expectations

When doing it, we noticed there was a problem with the images:

Looking at it, I wondered if there was a scaling problem, so I wrote some code to test it out. Turns out, depictions expect a size for the molecules, which isn't always the range in VCS. What to see?

Bioreason

Bioreason builds most of their internal viewers in Python. Here's a screenshot to show that it can be done. .
This is in Python with the GTK GUI library.

XML

I like XML as a data exchange format. So today during lunch I wrote a converter from TDT to XML, and back again. Here's the source code and example output