Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CIF development strategies

  • Subject: RE: CIF development strategies
  • From: "Bollinger, John Clayton" <jobollin@xxxxxxxxxxx>
  • Date: Fri, 5 May 2000 23:04:14 +0100 (BST)

Deal All,

> > Like PLATON, SHORTEP places a few restrictions on the order of items
> > in the CIF -- specifically that the atom type symbols come before
> > the atoms and that the atoms come before the thermal 
> parameters or in
> > the same loop with them.  These restrictions permit SHORTEP to read
> > and process a CIF in one pass, without storing any unnecessary data
> > in memory or scratch space.  The approach does not require 
> the overhead
> > of a large (albeit rigorous) API like CIFtbx, yet is still 
> flexible and
> > extensible.
> 
> Do you suffer a real performance hit by hooking in CIFtbx routines to
> reorder your input data? I'm just curious, because it seems a pity to
> impose order dependence - the application is then unable to read any
> arbitrary CIF. To my mind that need not be considered as completely
> devaluing the application; on a Unix box it's easy enough to knock up
> a script using a standalone utility (such as the great-grandaddy
> of them all, QUASAR) to pre-order your input. Nevertheless, it does 
> seem to hobble it a bit.
> 
> Is there a need for a lightweight subroutine library to input data in
> a specific order? Is that achievable in Fortran in any more 
> efficient way
> than CIFtbx?

I have not conducted a performance experiment to evaluate the relative
merit -- by that metric -- of CIFtbx vs. my custom code.  I would expect
my code to do better, simply because it has less overhead, but the
difference might not enough to be significant.  Performance is not the
driving factor, however.  I am more concerned with the size and
complexity of the source code, with the resource demands of the object
code, and with having access to and familiarity with the details of the
engine.  I could remove all order dependencies from my own code by
providing for taking multiple passes through the CIF; I did not do so
because the program already handles all the cases we ever encounter.
It is simpler and easier to document the restrictions and handle the
oddball case specially if it ever comes up.

As for the lightweight subroutine library, I'm not sure how light you
can go while still efficiently providing the features you propose.
Lighter than the input side of CIFtbx, I suppose, but I'm not sure how
much lighter.  I don't think it is a critical target.


John Bollinger
Indiana University
Molecular Structure Center

jobollin@indiana.edu

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links