[Pw_forum] Environ failed with graphene

Tue Oct 4 17:58:42 CEST 2016

Dear Rolly,

I see the problem of your command: evidently pw.x searches the the environ.in file in the directory where you are running. While you run from the location of the executable and specify the input/output with their full path, I usually run pw.x inside the directory with the input files and specify the path for the executable (which usually is QE-dir/bin/ )

~/path-to-pw.x/pw.x -environ -inp input.in !tee output.out 

This way the environ.in file needs to be in the same directory as the input.in file. Could you do it like this (i.e. run the above command inside the ~/rolly/ directory)? Or is there any problem that forces you to run from the bin of QE? Maybe we will consider changing the way the environ.in file is handled in the next releases, but for the time being I am not sure there are other ways around this problem. 

Best,

Oliviero 

________________________________________
From: pw_forum-bounces at pwscf.org [pw_forum-bounces at pwscf.org] on behalf of Rolly Ng [rollyng at gmail.com]
Sent: Tuesday, October 04, 2016 5:30 PM
To: PWSCF Forum
Subject: Re: [Pw_forum] Environ failed with graphene

Dear Oliviero,

Thank you very much for the detailed explanation. I am stating 'relax'
calculation with optimized structure in vacuum so I revised my
environ.in as,

&ENVIRON
         verbose = 0 ,
     environ_restart = .true. ,
            environ_thr = 0.5 ,
        environ_type = input ,
env_static_permittivity = 78.3 ,
              tolrhopol = 1.d-12 ,
           mixrhopol = 0.5 ,
/

I am using the following command to run pw.x with Environ plugin,
rolly at node06:~/QE530-CPU/espresso-5.3.0/bin> mpirun -np 24 ./pw.x
--environ -inp ~/rolly/file.in |tee ~/rolly/file.out
It works but I have to place the environ.in at the same directory as
pw.x, that is ~/QE530-CPU/espresso-5.3.0/bin

How can I place environ.in at the same directory as file.in? What
command should I use to instruct pw.x to look for the environ.in?
rolly at node06:~/QE530-CPU/espresso-5.3.0/bin> mpirun -np 24 ./pw.x
-environ ~/rolly/environ.in -inp ~/rolly/file.in |tee ~/rolly/file.out

Thanks for your patient.

Best,
Rolly

On 10/04/2016 06:25 PM, Oliviero Andreussi wrote:
> Dear Rolly,
>
> There may be "physical" reason or "numerical" reasons that explain why your calculation explodes. The latter are easier to solve, by tuning some of the parameters in environ.in, the former are a bit more tricky and I would leave them to a second analysis.
>
> Roughly speaking, in a calculation with environ you need to include some extra terms to the Kohn-Sham potential of the system in vacuum. These terms depend on the electronic density itself, in particular due to the fact that the interface between the system and the environment is defined in terms of the electronic density. Moreover, to compute one of these terms (probably the most important, the electrostatic interaction with the dielectric continuum) Environ uses an iterative approach, so every time you need to add the environ potential in an SCF step, Environ performs an additional iterative procedure to compute it: let's call this the polarisation iteration, in contrast to the SCF iteration.
>
> Having said this, there are two environ parameters which are crucial to help convergence of the total SCF calculation:
>
> tolrhopol: this parameter controls the convergence of the polarisation iteration. If you decrease it, the extra term coming from the interaction with the dielectric will be computed more accurately, but it will require more time to be computed. On the other hand, if you don't compute it accurately enough, the SCF accuracy will probably not go down as fast as it should and you may end up with an SCF accuracy that oscillates above the selected threshold (so that pw.x spends lots of time without converging). Since a single polarisation step only costs as much as a few FFTs, while a single SCF step costs more, it is generally better to INCREASE THE ACCURACY OF THE POLARISATION CALCULATION (I.E. DECREASE TOLRHOPOL) until you have a steep convergence of the SCF.
>
> environ_thr: since the extra terms depend in a delicate way on the electronic density (the shape of the environment depends on it), it is advisable not to add these terms at the very beginning of the SCF, which in pw.x usually initialise the electronic density in a random fashion. Thus, to enforce that the environment potentials are only added when the electronic density has a sensible shape, Environ only acts if the SCF accuracy is below a certain threshold, defined by environ_thr. On the other hand, you don't want to wait too long to add these extra terms, because it makes no sense to converge the density in vacuum and then add a very strong unexpected potential: the SCF accuracy will go banana and you need to redo all the SCF again. The net result is the one that you see in your output, you spend quite a lot SCF iterations to achieve the required SCF accuracy, then environ adds its additional potential and the SCF accuracy goes up again, with an oscillating down and up trend which may eventually explode. Thus, if you see poor convergence of the SCF the way to go is to INCREASE ENVIRON_THR, NOT TO DECREASE IT. As a side problem, SCF accuracy is an extensive quantity (it becomes larger for bigger systems), so that it is not possible to fix a default hardcoded value for this parameter. Nonetheless, as a rule of thumb, environ_thr should be set so as to skip only a few (three, four, five) SCF steps, so you may want to set environ_thr to the value of the SCF_accuracy at the third/fourth/fifth SCF step in vacuum. In your case a value of 0.3-0.5 could work better than the 0.0001 that you set up. NOTE: if your SCF starts from a previous run in vacuum and the electronic density has an already well defined shape, you may want to start adding Environ potentials from the very beginning: you can do this by setting environ_restart = .true. inside the environ.in input file.
>
> Apart from these two numerical parameters, you may want to simplify a bit the physics of your problem. In particular, since in most applications the most important effects of the environment are the electrostatic ones, you may want to switch off all the other terms. You may do this by using environ_type = 'input' instead of the default ones (environ_type = 'water') and then by only specifying the dielectric constant of the environment env_static_permittivity = 78.3 for water at room temperature. Since by default all environ contributions are turned off, by doing this you are only including the dielectric continuum in your environ calculation. This is analogous to what is done in example02 and example03 in the Environ/examples directory.
>
> Moreover, sine you are simulating a 2D system, convergence of the polarisation potential may be made more difficult by the artificial finite electric field coming from periodic boundary conditions. To avoid this, it would be better to use a PBC correction, in particular for slabs in Environ it is implemented a simple parabolic correction, which corrects most of the artefacts and helps converging the polarisation iterations. You can set it up by setting assume_isolated = 'slabz' in the &SYSTEM namelist in your pw input file (NOT the environ.in input file). Note that you can use the same correction also for a calculation in vacuum, you still need to run pw.x --environ and set environ_type = 'vacuum' inside environ.in (similarly to what is done in example03).
>
> Eventually, one reason of poor convergence of an Environ calculation may arise if your system's interface with the environment has a strange/irregular shape. This problem can be solved, but is a bit more cumbersome and I would only analyse it if the other things don't work.
>
> Please let me know if the explanation above is not clear or if you have any other question.
>
> Best regards,
>
> Oliviero
> --
> Senior Postdoctoral Researcher
> École Polytechnique Fédérale de Lausanne (EPFL) and
> Università della Svizzera Italiana (USI) of Lugano
> USI Campus, Via G. Buffi 17, 6904 Lugano, Switzerland
> Emails: oliviero.andreussi @ epfl.ch -or- usi.ch
> Tel: +41-(0)58-666-4810 / Skype: olivieroandreussi
> Web: https://sites.google.com/site/olivieroandreussi
>
>
> ________________________________________
> From: pw_forum-bounces at pwscf.org [pw_forum-bounces at pwscf.org] on behalf of Rolly Ng [rollyng at gmail.com]
> Sent: Sunday, September 25, 2016 7:42 AM
> To: PWSCF Forum
> Subject: [Pw_forum] Environ failed with graphene
>
> Dear Oliviero,
>
> I am trying to relax a gold-doped graphene supercell with 72 atoms in
> water using Environ.
>
> My input/output files are attached, but I observed that the solvation
> energy became positive (which may be true?) but the optimization failed
> with following message.
>
>    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>        Error in routine  cdiaghg (310):
>         problems computing cholesky
>    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>        stopping ...
>
> How can I solve the problem? Is the environ.in correct?
>
> Thanks,
> Rolly
>
> --
> PhD. Research Fellow,
> Dept. of Physics & Materials Science,
> City University of Hong Kong
> Tel: +852 3442 4000
> Fax: +852 3442 0538
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://pwscf.org/mailman/listinfo/pw_forum

--
PhD. Research Fellow,
Dept. of Physics & Materials Science,
City University of Hong Kong
Tel: +852 3442 4000
Fax: +852 3442 0538

_______________________________________________
Pw_forum mailing list
Pw_forum at pwscf.org
http://pwscf.org/mailman/listinfo/pw_forum