[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Solid State Toolkit Development
The question of how best to formulate a solid state toolkit
to foster independent development and portability is an
important one, which is of interest to several groups in
the US. Besides the toolkit development e.g., at UW that
would be an extension of the FEFF Project, Malcolm Stocks group
at Oak Ridge and Richard Martin at U. Illinois are both actively
interested in the design of such toolkits. For definiteness,
I will assume that such a toolkit has the capability to calculate
various properties of materials, and is also compatible with analysis
tools used to compare calculations and experiment.
In my view, portability should be a very high priority, so that
the components of a kit developed on one architecture can be used
on another. The use of f77 and cc codes to build the modules and
libraries are good choices in this respect, since they are widely
portable. Also, they are now well adapted for parallel computation.
Since linkers can mix cc and f77 objects, these choices are also
compatible.
There are some good arguments for using f90, due to the efficient
memory management capability, but not many f90 extensions are
available in g77 as yet, so portability is a problem at present.
The need to buy expensive compilers for some applications (e.g.,
the Portland Group pgf77 f90 hpf77 etc, Absoftf77 or Compaqf90 etc.)
is probably secondary, since they are usually less expensive than
the hardware. In any case, it seems to me that being able to link
fast codes and libraries should have a high priority.
Another priority is the development of a reasonably generic i/o
policy, that fosters independent development. It's not clear to
me what is best for this. However, a clean formatted input statement
at the top of the main program (wrapper) with sufficient annotations
and other comments may be adequate. This will probably require some trial
and error. However, it would be desirable for a few independent groups
to try one or more such schemes to see which is most workable.
In my view a prototype effort aimed at linking a few modules
could help settle this question.
There are clearly many other issues, such as those brought up by
B. Ravel and M. Newville, e.g. how to link software together
via scripting languages like perl, java, etc. Thus it's important
to consider these too and foster compatibility.
Toward this end, Malcolm Stocks and I are scheduling a mini-meeting to discuss
the solid state toolkit issues, on the last day of the APS meeting in
Seattle (Fri. March 16) and a follow up meeting at the UW the next day
(Sat. March 17). Details will be announced at a later date.
J. J. Rehr
Dept. of Physics, BOX 351560
University of Washington
Seattle, WA 98195-1560
e-mail: jjr@phys.washington.edu
URL: <http://WWW.phys.washington.edu/~jjr>
Office: (206) 543-8593
Fax: (206) 685-0635
Dept: (206) 543-2770