Subject: High Cost of Comp. Chem.

From: Michael Sennett <[email-masked]>
Date: Mon, 7 Feb 94 15:16:34 EST

Dear netters, 

	In the past there has been some discussion here about
quantifying the value of computational chemistry activities to
various organizations, principally industrial firms which want a
certain rate of return on any investment made in R&D.   These
discussions have generally revolved around the notion that we
(modelers, simulators, theorists, or whatever..) need a collection
of case studies or success stories which we can publicize to enhance
the image of the field in the eyes of the R&D managers who are asked
to fund our efforts.   The response to calls for such success
stories never seems to be forthcoming to any great extent, probably
because (as has been previously pointed out) any such stories would
involve proprietary information which cannot be disclosed.  Also, it
is difficult to assess the value of "negative success."  By this I
mean the scenario where the modeling group advises the synthesis
group NOT to proceed with the preparation of their proposed compound
based on the results of simulations.  Is the modeling group credited
with saving the organization the hundreds or thousands of man-hours
the synthetic project would have consumed?  Not likely. 

	At any rate, there are two sides to the cost/benefit ratio
being considered here.  Since we can't get a firm grip on the
benefits (for whatever reasons), what about the costs?  I bring this
up since I find myself in a bind which I expect is extremely common,
though I don't think I've seen it discussed explicitly.  

The situation is this:  After making a substantial (don't ask for
specifics.... this will be the proprietary part of THIS end of the
equation) investment in hardware and software to inaugurate a
molecular modeling effort a VERY few years ago, and paying
maintenance fees  (large enough to be noticed by the budget
analysts)  in the meantime, we find ourselves with FUNCTIONALLY
OBSOLETE hardware, the capabilities of which have been largely
outstripped by upgrades of:

	a) the application software

	b)  the OPERATING SYSTEM (for crying out loud)

This revolting development comes about as a result of a series of
events that goes something like this....   

1)  You need software support both for the applications and the OS.

	You have a staff of people whose principal training is in
chemistry using the application.  You don't have dedicated
programmers or software developers or system operators.  You have to
have on-line support to keep the system going when bugs, etc. are
encountered.  You also find the support of the software vendor
valuable in developing your applications for the software.  So.....

2)  You procure software maintenance, which includes phone support
AND periodic software upgrades.  

	These agreements typically require you to be running the
current release of software.  You may get away with being one
version behind but no more than that.  But....

3)  Each new release has more capabilities.

	Which is great, right?  Except that these additional
capabilities demand additional hardware resources.  But....

4)  Your hardware isn't being upgraded at the same rate as your
software.

	Hardware doesn't upgrade the same way that software does.
It is rarely economical to upgrade a CPU with hardware "patches"...
discard and replace is the only cost effective thing to do.  But....

5)  Your budget division says you JUST BOUGHT a lot of expensive
hardware.

	Even very up-to-date R&D managers have a hard time
swallowing the idea of total system obsolescence in a 3-year period.
Word processing hardware lasts longer than that.... so do the
computer controllers on typical lab instruments.  There are plenty
of PC-AT's still happily running IR's, HPLC's and a whole bunch of
other analytical equipment. 

6)  So the answer is just to stand still, right?  

	That is, don't upgrade hardware or software for as long as
possible.  If it ain't broke, don't fix it....?  This will work only
as long as something doesn't break, which probably won't be long.
If your hardware holds out, you are bound to try something new with
the software which will cause a problem.  When you call for support,
you find that the problem was fixed in an upgrade (which you didn't
get) or that no one will talk to you about your situation since you
aren't running the current software release.   So... 

7)  You try to get funding to upgrade your system.... 

	So the R&D manager wants to see what the money so far
invested has purchased, and you end up back on the BENEFIT side of
the equation, which we have seen is hard to quantify.  (Especially
for  a non-profit organization).  Faced with this situation, only
individuals with extremely high levels of vision, intestinal
fortitude and conviction will opt to continue to spend the kind of
resources necessary to operate a molecular modeling activity based
on the big commercial software packages.   

	It is easy to see how this kind of scenario can and probably
will force (or keep) small industrial labs and even many government
labs out of computational chemistry or keep them on the fringes in
terms of the level of theory or size of  calculations being
performed.  This in turn delays the realization of the enormous
potential of computational chemistry (I'm biased) and makes it hard
on the ever-increasing number of computational chemistry graduates
being turned out by academia.  There is also the potential for
backlash by the R&D management community against computational
chemistry (modeling, simulation etc...) (this idea has been
mentioned in previous cost/benefit discussions) which could lead to
retrograde steps for the field as a whole.

	The academics can continue to play,  aided by enormously
discounted licensing fees and what I perceive as generally easier
access to high performance computing than the average industrial R&D
facility.

	Sure, you don't have to buy the big commercial software
packages.  You can go to QCPE and get a whole suite of programs for
relatively small change that will enable you to do lots of valuable
things.  But this collection of software still has to be mastered
and maintained.  Also, there is no real universal molecular data
format which guarantees the interoperability of all these
applications, so your comp. chem. staff has to divert its time from
working on chemical development to working on the software
applications themselves.  What is gained through reduced software
costs is lost to increased labor costs, reduced productivity, etc.

	Well, what is to be done?  At the risk of opening the
floodgates, I'd be interested in seeing some discussion of this
issue.  Is this experience as common as I think?  Is everyone else's
comp. chem. program thriving?  How can small R&D organizations
maintain high-level molecular modeling capabilities long enough for
the value of the methods to be "proven?"  

	The experience of the pharmaceutical industry should be
relevant here. Computational chemistry is a pretty secure fixture in
that industry (or so it seems to me), but it wasn't always this way.
How did computational chemistry come to be accepted as a valuable
and necessary part of an R&D operation in the drug industry?   Are
the issues addressed by the modeling efforts in pharmaceutical firms
so much more tractable than those of interest to materials
scientists (by virtue of being focused on small molecules and on
bi-molecular, i.e. probe-receptor, interactions) ?

	I look forward to seeing people's comments.

Michael Sennett

***************** disclaimer *******************

The ideas and opinions expressed above are entirely my own and do
not  represent the position or policy of any other person or agency
whatsoever.
**************************************************