Subject: OOP in comp. chem.

From: [email-masked] (Ferenc Molnar)
Date: Wed, 9 Feb 94 14:37:20 +0100

>Oh, I guess something went wrong with my last mail!
>So here is another try, excuse me!

It was an accidental dot in the first column! Please excuse!

Leif Laaksonen wrote:

>This is really a long time dream of mine. Just imagine if there would be
>more object oriented classes in computational chemistry code. You could
>just plug in and use a class for PM3, MP2, Leap-Frog algorithm and so on.
>All code would be easier reused. Today too much code is still developed
>for one particular approximation or application.
>
>
>
>I believe this is something we 
>quantum chemists have in front of us very soon. The whole consept
>has to be redefined. Perhaps this will never happen because there is
>so much "old" code available which will never be rewritten. But for
>the sake of science I wish this will happen. After all as Ron Shepard
>said we all appreciate more the kind of knowledge that remains useful
>for decades rather than months or years.

I agree with you, "something" has to happen.
The old code shold be rewritten and the concepts should be altered.
For example, a molecular dynamics program could be written 
very efficiently in the framework of an object oriented approach.
Atoms and molecules designed as class objects, interacting by some
virtual functions, would make it easy to add new types of features.
The whole thing could be done for example in C++ 
(don't say C++ is not OOP).

And as a bonus the administration of the code would be easier.

These were my ideas when I started the project I am currently
working on. But there are at least three drawbacks.

First:
You need quite a long time for designing your program in an OOP-language
when you are used to modular programming. 

Second:
FORTRAN 77 is the most portable language (C programmers forgive me!).

Third and most important:
As you always have a lack of hardware resources, you
need a compiler which optimizes efficiently.
Often the raw speed of your calculation is the crucial point.
FORTRAN compilers have quite a history and are very effective in
"number crunching" and are essentially bug free.
The advantage of C++ (or say FORTRAN 90) is that you can handle
dynamic memory allocations, but this can slow down the program and
prevent effective optimization.

And thus I decided (with considerable regrets) to use the hereditary 
style of programming for my project.

In my oppinion OOP methods should only be used for large scale projects.
These projects have to be supported by some organization like an
university or a company and are scheduled for years.
I think that in this case the financial grounds are there for even
reprogramming functioning code (e.g. Hyperchem from Hypecube).

I wonder if there are more such projects going on somwhere out there
and I would be very much interested in details.

Yours sincerely,

Ferenc Molnar

---------------------------------------------------------------------------
Institut fuer Physikalische und Theoretische Chemie
- Lehrstuhl Prof. Dick -                   Tel.:  (+49) 941 943-4466 /-4486
Universitaet Regensburg                    Fax.:  (+49) 941 943-4488
Universitaetsstrasse 31
D-93053 Regensburg
Deutschland / Germany
---------------------------------------------------------------------------
EMail (SMTP):  [email-masked]
               [email-masked]
               [email-masked]
---------------------------------------------------------------------------
:-) There is more to live than increasing its speed.
                                       -- Ghandi  ;-)
---------------------------------------------------------------------------

---

From: Gustavo Mercier <[email-masked]>
Date: Wed, 9 Feb 1994 14:03:28 -0500 (EST)

Hi!

My 0.02!

A few years ago I had to make a decision about expanding my computational
skills. Learn C, C++ ... etc.

I was finished with my M.D.-Ph.D. and had extensive experience with
Fortran, in fact all my Ph.D. work was done with it. Unfortunately,
I was about to start my postgraduate medical training in Radiology, with
one year of internal medicine. This meant severe constraints in my schedule
for any research, particularly any programming. I needed a programming
language for fast programming with little maintenance.

I decided to become conversant with MATHEMATICA, although along the way
I learned C, and now I am wetting my feet in C++.

I have been very happy with MATHEMATICA. I do ALL my programming with it.
The learning curve was steep since you have to think in terms of 
functional programming. Getting rid of Do Loops and IF statements was
difficult (although these are present in Mathematic for
Fortran diehards), but I have written an entire Integral,
package (albeit not the most efficient) in about 100 lines of code
by literally just transcribing the recursive formulae from Obaira
and Saika (JCP 86(7),1986)!

Moreover the symbolic capabilities allow you to explore the
contribution of numerical methods to the errors.

For example, Lowdin
introduced Resolvent methods to solve the Schroedinger equation in the 
'60's. Experience in Numerical Methods suggests that Resolvent methods
should be better than Perturbation or Variational techniques. Unfortunately,
the Resolvent Method requires the Inverse of (H-z.I.E) where z is the
resolvent variable, something difficult to program in Fortran.
Without symbolic methods you need to implement a
numerical method to solve for z within a host of other approximations.
These could degrade the suspected power of the Resolvent technique.
The symbolic capabilities of Mathematica allow you to compute this
inverse exactly avoiding these limitations. Unfortunately, I never
carried the project through since DFT became popular!

Finally, now that I am learning C++ I am even more impressed with
Mathematica. Many concepts of C++ like operator overloading are
already included in Mathematica.

Sure, Mathematica is not a perfect solution. You have to have the kernel
running for your program to run. Moreover, I am sure that you can write
very specific and more efficient numerical code in Fortran, C etc., if
you are an expert and invest enough time.
You won't write a graphical user interface with it, either. But 
given the cost of many commercial packages that don't have
script languages built-in nor release their source code ...

I think Mathematica is still a good idea. I am convinced that you can
write and mantain what would normally be extensive code with less effort,
an important factor in determining the cost of software.  
Noteworthy is the ability to use 
MathLink, a fully supported package included with many Mathematica
platforms, to connect your own Fortran, C, C++ code with the Mathematica 
kernel. Communication is then possible from either program to the other,
whether you are within Mathematica or your own program. In fact some
commercial suppliers of such as Spyglass are already link their
visualization software to Mathematica using MathLink.

Finally, it seems to me that Mathematica has never "made it" within
the computational chemistry community. As such, it probably falls
within the area that mathematicians and physicists have exploited more
extensively. In fact, the only application in chemistry published
in the Mathematical Journal (that I can remember) was in coding the
vibrational Schroedinger equation for molecules. The authors were using
the symbolic capabilities of Mathematica together with its ability to
generate Fortran Code to derive and code the high order terms in the
potential (n> 2) expressed in powers of normal modes, these are
messy from the algebraic point of view and prone to errors in
programming.

In the end OOP will take over, whether we like it or not. The key
is how much we are willing to change and how much support large
scale machines will have for it. Will programs vectorize? Will they
ever do array boundary checks automatically? Will the perception that
C cannot number crunch as fast as Fortran change? In the mean time, as
long as I don't intend to write my own full blown Gaussian package,
I will continue to write my Mathematica programs and run them in my SGI.

gus mercier
[email-masked]