[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
feff8.20x5 code development
Dear developers,
We would like to report the progress done towards the release of
feff8.2.
We have now implemented almost everything in parts A, B (2 and 3)
and C of the list of propsed changes given in the March 21 posting,
a copy of which is appended at the end of this msg. Only the
efficient memory matrix inversion algorithm (C 1) has not been implemented,
and will be reserved for a future release. Also some document changes
and updated license information remains to be included (the latter pending
discussions with UWOTT). The FEFF8 document has been partly revised to
describe the new cards (e.g., FMSTUNE and MULTIPOLES) cards, however.
In addition to the March 21 list, we revised the Makefiles to allow one
to make either monolithic (sequential) or modular (sequential or parallel)
codes from the same source files. The major change in the structure of
the code is that in its modular form, each of the FEFF8 modules is independent
of the others, and has its own input/output structure. We hope that this
revision will answer complaints about the early modular structure. The
latest version of the code is feff8.20x5 and you can obtain it as before
from CVS (e.g., cvs update feff82).
The feff8.20x5 code has been tested extensively; it has been
compiled and run, both in parallel and sequential modes on many platforms
(SGI, AIX, Cray, Compaq Alpha, LINUX, MAC OS9) and now do not get any compiler
or run errors. There was a problem with SGI f77 with the -Ofast option: for
genfmt_tot.f and paths_tot.f we had to turn off inlining to get correct
path counts (f77 without -Ofast worked ok, but was several times slower):
f77 -Ofast -LNO:opt=0 -IPA:INLINE=OFF genfmt_tot.f -o ffmod5
We would appreciate any comments on this code development, especially
its structure, or problems you have compiling or running.
We do plan to add more comments lines and new copyright and license statements.
Unless any new bugs show up or substantial comments from the other feff developers
this version will become the source code for the feff8.2 release and we will
make the updated code, document and an announcement on the FEFF WWW pages.
At first, we plan to release only monolithic sequential code to feff users,
since only that version supports the configuration average (CFAVERAGE) card,
and we do not feel that the the modular parallel version is ready for "ordinary"
users, who are generally used to a monolithic code structure. However, we do
hope to release the pre-built feff modules either in sequential or parallel
forms soon.
Sincerely,
Alex Ankudinov and John Rehr
4/23/01
------ copy of March 21 posting -----
>From FEFFDEVEL-owner@u.washington.edu Wed Mar 21 11:23:19 2001
Dear developers,
We need to make several changes before feff8.2 can be released to general
feff users. We would greatly appreciate both comments and help on
any of the items, proposed below.
A. Changes needed for feff8.20x5
clean up I/O structure of the code and add comments for developers.
Proposed structure:
1) RDINP will read feff.inp and write separate module.inp files and
a separate geom.dat (ATOM card data).
Each module reads geom.dat, one module.inp and several previous_module.bin
files and writes single current_module.bin.
Thus each module will be independent and only have it's own input and output.
This also implies that we will get rid of all the IOR routines.
IOR is not needed since each module.inp will have just a few variables,
which are organized as in feff.inp, but in some fixed format:
CARD value1 value2 ..
We understand that this is not a perfect solution for I/O structure, and
would therefore appreciate some comments. Various I/O standards are being
discussed for toolkit implementations, so we will probably change this structure
sooner or later away from the current module.inp and/or module.bin in the future.
2) Pass more variables (header lines, repetitive input data) through module.bin
files. For example, the variable nph (number of different potentials) is set in
the POT module, and passed to XSPH through pot.bin. From XSPH to FMS it will
be passed through phase.bin, and so on until needed.
3) Add README files in each directory of feff82/src/
with basic information on the purpose of subroutines (program) in that directory.
4) Each main subroutine(program) will have a generic structure; e.g.,
subroutine genfmt
c program genfmt
c Description of the purpose.
c INPUT files
c OUTPUT files
read module.inp
read geom.dat (if needed)
call genfmt(variable list)
c Description of the variable list and comments for code developers
B. Changes for feff8.20x6
Implement new FMS algorithms:
1) Implement efficient memory matrix inversion algorithm
with recursion and Broyden methods for FMS
2) Make a card for swithching between various FMS
algorithms (the analog of the undocumented FMSTUNE card).
3) Add MULTIPOLES card (code can already calculate elec.dip.,
elec. quad. and mag.dip. transitions)
C. Release version of a monolithic feff8.20 code
1) The advantages of modular code - the code needs less memory,
but there is big disadvantage: it needs run scripts for
every possible machine (=>portability problem). Also we found our
UNIX scripts unsatisfactory, since it is currently too primitive,
and several times John and I were running code which was not in the
right directory, and wondering e.g. I just fixed the bug, why does it show
up again? Our UNIX script also disabled the CFAVERAGE card, which is
used by several researchers (e.g. Farrel Lytle, Steve Wasserman)
Also the 8.1 document would need fewer changes for release,
as well as simpler installation instructions.
Thus we want to make possible building a monolithic version of 8.2 (like 8.1)
i.e. use feff8.1 feff.f main program
program feff
call ffread(nabs)
call ffmod1
call ffmod2
do 900 iabs = 1, nabs
c sort atoms for 'configuration average' according to absorber
call ffsort (iabs)
call ffmod3
call ffmod4
call ffmod5
call ffmod6 (iabs)
900 continue
call wlog (' Feff done. Have a nice day.')
stop
end
Ideally, the change from modular to monolithic code can be handled
with a Makefile: e.g. 'Make mono' could, for example,
concatenate all .f files in all directories, but would also need some
script to read monolithic code and comment out lines program ffmod?
and uncomment line below: e.g.
c subroutine ffmod6 ( iabs)
Neither John nor I knows how to write such automatic scripts well. We would
therefore like to have some help with that. Lacking that, we will have to be content
with less automatic versions. However, it will be advantageous for all
developers to have it automated.
2) run test-suite on various platforms (e.g., SGI, LINUX gnu, pgf77, compaq,
AIX, HP, and WIN-NT; sequential and MPI versions when possible.)
These tests can/should be semi-automated, at least on unix boxes.
3) update Feff8 document
We estimate approximately 1 month for every version (8.20x5, 8.20x6, 8.20),
but this can be off by a factor of 2.
D) Modular code and dynamic memory allocation will be goals for future versions.
We have had interesting discussions on a 'toolkit' approach to modular coding for
high performance computers with Stocks group (from ORNL) during the March meeting.
The multiple scattering codes are good prototypes for this, and it appears that the
FMS codes in FEFF8 and Stocks LSMS codes can be constructed from rather similar
toolkit modules. Of course, real advantages would come from the use of LSMS tools
in feff and vice versa.
Stocks group has a number of excellent computer scientists, so FEFF will likely
be able to benefit from their expertise, and vice versa. It will be important to
consider and test various I/O standards for this work. For example, it could be
useful to enable compatibility with XML format in the future.
Sincerely,
Alex Ankudinov
Research Assistant Professor
Lead FEFF8 Developer