24小时热门版块排行榜

返回列表

当前主题已经存档。

zxzj05

荣誉版主 (著名写手)

1ST强帖: 1
应助: 0 (幼儿园)
贵宾: 1.242
金币: 5912.5
红花: 2
帖子: 1528
在线: 144.5小时
虫号: 406147
注册: 2007-06-18
性别: GG
专业: 金属功能材料
管辖: 第一性原理

[交流] 【分享】ABINIT快速上手10步

10 steps to hike ABINIT 5
1. Installing and learning Bazaar
Bazaar is "yet another implementation of GNU Arch". The ABINIT Forge is a collection of Bazaar repositories, owned by developers. It can be accessed through SSH, after requesting an account and sending a SSH public key to the archmaster (currently J.-M. Beuken, see page footer). If you don't know what this is all about, just go to step 2.

Installing Bazaar is extremely easy on many platforms, as its sole true software requirement is Python 2.4. However, to be able to use its SSH-capable features you need to have a few Python packages installed. Please follow the installation instructions found on the Bazaar website, or ours in case you need to perform a non-standard install.

To learn Bazaar, we suggest you go through the Bazaar Tutorials and read the documents provided on the ABINIT website.

2. Getting the source tree
User's trail: if you do not have an access to the ABINIT Forge, please download the latest source tarball from the ABINIT web site. Then go directly to step 4.

Developer's trail: useful instructions are given in the Bazaar Quick Reference on how to get a working tree from the archive.

3. Running makemake
User's trail: if you downloaded the source tarball from the web site, please go directly to step 4.

A certain number of files are generated by scripts. They cannot be managed by Bazaar, as they would cause a huge number of conflicts to occur at each merge operation. This means that they are missing just after you have the source code fetched, and the working tree is not yet functional. The build system provides a series of scripts which are in charge of producing a buildable source tree. They are located in the config/scripts directory, and their front-end is called makemake.

In order to do their job, these scripts will require that the following software be present on your machine:

Perl ≥ 5.005 (5.8.8 recommended)
Python ≥ 2.4 (2.5 in test)
GNU M4 ≥ 1.4.4 (1.4.9 highly recommended)
Autoconf ≥ 2.57 (2.61 highly recommended)
automake ≥ 1.9 (1.10 highly recommended)
Libtool ≥ 1.5.0 (1.5.22 highly recommended)
The recommended versions do not only fix bugs, they will produce better configure scripts. Please install either the minimal versions or the recommended ones. Do not mix them.

After checking that all these pieces of software are installed, please run the makemake script. Just type:

./config/scripts/makemake

You will have to run it once each time you get a source tree, and each time you make a structural change to the sources. All this is explained in the developer's manual and developer's FAQ (still work in progress).

4. Configuring ABINIT
There are two ways to configure ABINIT:

giving command-line options to the configure script; a full list can be obtained by typing "./configure --help" from the top of the source tree;
writing a config file.
Using a config file is a more convenient way to set-up options for ABINIT. And anyway, you can override it with command-line options at any time. A self-documented template is provided in doc/config/build-config.ac. Please follow the instructions contained therein.

This config file will be read by the configure script each time you want to build ABINIT, regardless of the version. This is good news for you, because it means that you can write it once and for all, adjusting it from time to time when your configuration evolves. The naming convention adopted makes it usable on platforms where a home directory is shared among several computers (e.g. through NFS).

Now we suggest you to create a build directory inside the ABINIT source tree. Let's call it tmp. Just type:

mkdir tmp && cd tmp

Note for Bazaar users: bzr has been configured to ignore directories named "tmp" and "tmp-*".

Then you can configure ABINIT by typing:

../configure

The configure script will display a lot of messages related to its attempts of auto-detecting your configuration. The command-line options you give it are hints for things it cannot guess by itself. At the end of the process, it will generate all the makefiles you need to build ABINIT.

5. Generating a source tarball
Being able to generate a source tarball is important when you want to build modified sources on a machine which does not provide the required build environment (i.e. the GNU Autotools).

To create a tarball, just type: make dist

Generating the source tarball will take between 1 and 3 minutes on a modern PC. Once done, you'll find the file in the current directory.

6. Building ABINIT
To build ABINIT, just type "make". This may take between 3 minutes and 1 hour, depending on your configuration and the level of optimisation you are requesting. If you want more information about what you can build, just type make help.

a. Sequential binaries
If you want to (re)build a sequential binary, just type "make ".

b. Parallel binaries
WARNING: this section is outdated.
The MPI libraries available within most Linux distributions still come with Fortran 90 support disabled. This means that you will have to build MPI yourself or have it built for you if you want to use the parallel binaries of ABINIT. For more information, you may have a look at the MPI options provided by configure.

7. Enabling external libraries
WARNING: this section is outdated.
You may try to enable or disable optional features, either editing the config file (remember step 4), or providing command-line arguments to the configure script.

a. NetCDF library
NetCDF is now well supported and should build straightforwardly on most platforms. To enable it, just uncomment the "enable_netcdf" flag in your config file or use the "--enable-netcdf" option of configure.

b. ETSF Input/Output library (ETSF I/O)
The ETSF I/O library allows platform-independent exchange of data, mainly electronic densities and wavefunctions. It depends on NetCDF. To enable it, just uncomment the "enable_etsf_io" flag in your config file or use the "--enable-etsf-io" option.

c. ETSF exchange-correlation library (ETSF XC)
Support for the NQXC library is experimental and should be used by fully-aware developers only. To enable it, just uncomment the "enable_etsf_xc" flag in your config file or use the "--enable-etsf-xc" option.

d. XML Fortran 90 library (XMLF90)
XMLF90 library support is back from Spring 2007. The library should build well and be usable, but we have just made some tests on the PC platform. To enable it, just uncomment the "enable_xmlf90" flag in your config file or use the "--enable-xmlf90" option.

Please note that this library is not well-maintained anymore, and that current development efforts are now found in the FoX library. Preliminary FoX support has been added for developers, but still require the current ABINIT bindings to be rewritten.

e. BigDFT
BigDFT has been recently added into ABINIT and is still experimental. It allows the simulation of systems composed of more than 1000 atoms. At this point it should be used by fully-aware developers only. To enable it, just uncomment the "enable_bigdft" flag in your config file or use the "--enable-bigdft" option.

8. Running tests
In order to perform tests, just go to the tests directory and type "make". You will get some help on how to perform them. Some tests are known to make ABINIT crash. If you have time to help fixing these bugs, feel free to participate to the hunt and keep the project leader posted.

Here ends the user's trail.

9. Sending patches
This step is only for developers using tarballs.

When you have found and fixed a bug, the best is to send back your corrections upstream, so that they may be included in the upcoming releases. Here is what we suggest you to do:

Make a full backup of your changes (we'll say they are in NEWDIR).
Untar a pristine version of the source tree you have used for your fixes.
Create a patch with the command:
diff -urN OLDDIR NEWDIR > abinit-x.y.z-myfixes.patch
Compress the patch if it is too big to be sent directly by email.
Attach your patch to a message explaining what you've done and send it to the project leader.
10. Commiting bug fixes
This step is only for committers (developers using Bazaar).

When you want to have bug fixes quickly included in the next release of ABINIT, remember to commit your changes in your x.y.z-public branch, where x is the current major version number, y the current minor version number, and z the patch level of the next release. Your branch will then be scheduled automatically for the next nightly build.

[ Last edited by zxzj05 on 2009-3-21 at 15:56 ]

回复此楼