1.1. Multiple options added to response command. Now the way to call response command is:
    response -vext vext_file [-RPA or -IPA] [-amplitude amplitude] [-parallel_write] nitscf [nite]
    a) -RPA option will freeze the update of Vxc (only work for semilocal functional now); IPA will freeze the update of Vxc and Vhartree (not implemented yet since it will involve major change of EnergyFunctional class). In order to implment RPA, some changes are made to EnergyFunctional class and XCPotential class. Additionally, two boolean flags are added in Control class to indicate whether Vxc or Vhartree is freezed.
    b) -amplitude option can set the amplitude of Vext. Right now it seems that this option is very convenient since it facilitates the test on whether the magnetitude for Vext is in linear-response regime. So I suggest keeping this option.    c) -parallel_write: not implemented yet. By this option I intend to realize parallel I/O, like in SampleReader or SlaterDet::write. We may need to change the format of file into binary (e.g. base64) to implement this.


2. Improvement of implementations:
  2.1. Now response command will use the GS charge density and charge density under +Vext to generate an initial guess (by 2*rho0 - rho(+Vext)) for the calculation under -Vext. By doing this improvement it is observed that for silane the convergence of SCF iterations under -Vext becomes 3 times faster. In order to implement this there are some minor changes made to BOSamplerStepper.
  2.2. Now in ExternalPotential::update process 0 will first read the file and MPI_Scatterv to other processes in column 0; then processes in column 0 will perform in-row MPI_Bcast to send Vext to all other processes. Likewise, now in ResponseCmd::responseVext process 0 will MPI_Gatherv drho_r from all processes on column 0. These functionalities are encapsulated in two functions in ExternalPotential.C and ResponseCmd.C respectively, to make the code more modular. As mentioned before, the IO performance might be further improved by resorting to binary format and MPI file operations.

3. Other comments:
  3.1.  Regarding whether Vext should be updated when "set vext" command is called: right now our construction of Vext strongly depend on the ChargeDensity instance passed to update() function, so it seems that we can only update vext during "run" or "response" command. It would be interesting to consider if we can have a ChargeDensity member in Sample class, as you mentioned earlier. But it involves major changes. 
  As a compromise, would it be possible if we keep a ChargeDensity member in Sample class (and we still have another ChargeDensity instance created in a BO sampler) and only update it manually by explicit command, or at the destruction of BO sampler? In this way, the awkwardness that Vext can only be updated inside a BO sampler where a charge density exists can be removed.
  3.2. In ResponseCmd::responseVext function, a previous modification that changes s->wf.spincontext() to cd.context() seems to cause some tricky problem... Right now I rearlly don't understand why this will happen, but it appears that things work fine after I reverted this change. There might be some hidden bugs here that may be significant when we test against large calculations where the context is complicated. I will return to this problem later.
  3.3. I understand that the option list of response command is too long compared to other commands in Qbox and it may be unpleasant. Later we may simplify it.


git-svn-id: http://qboxcode.org/svn/qb/branches/vext@1884 cba15fb0-1239-40c8-b417-11db7ca47a34