<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" dir="ltr">
<p>Hi Lorenzo,</p>
<p><br>
</p>
<p> I have got it to work using both automatic and manual k-points, the mistake was to specify both 'berry=.true' and 'lelfield=.true.' at the same time and using 'nscf' calculation. The process I was going by was the description in the header of bp_c_phase.f90,
when as you alluded to the electric field code is very similar but separate so the latter was the correct way to go with 'scf' calculation.</p>
<p><br>
</p>
<p>For 'berry=.true.', one needs to run a normal 'scf' with 'lelfield=.false.' to get the ground state first, then the polarisation can be calculated (P=0 which is a good sign for my system) as described in bp_c_phase.f90. I will now test other gdir than 3.<br>
</p>
<p><br>
</p>
<p>For 'lelfield=.true.', one can just specify a value of the field, both auto and manual work (again with gdir=3 so far). Afterwards one can apparently do a 'nscf' run with 'berry=.true.' (and 'lelfield=.false.') which reports the polarisation in the same
format as the 0 field calculation above which is now non-zero as expected. <br>
</p>
<p><br>
</p>
<p>Example 10 was helpful too, if anyone reads this that should be a good point of reference.</p>
<p><br>
</p>
<p>Finally when you were talking about the bottleneck, I suppose you were talking about the efield code, my impression so far is this is not a problem using 4 processors, I will also test using 8 and compare the time taken. I have no idea how fast it 'should'
be with proper parallisation, assuming it is possible to parallelise.</p>
<p><br>
</p>
<p>Kindest regards,</p>
<p>Louis<br>
</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> pw_forum-bounces@pwscf.org <pw_forum-bounces@pwscf.org> on behalf of Louis Fry-Bouriaux <ellf@leeds.ac.uk><br>
<b>Sent:</b> 09 February 2017 11:38:01<br>
<b>To:</b> PWSCF Forum<br>
<b>Subject:</b> Re: [Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell</font>
<div> </div>
</div>
<div>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi Lorenzo,</p>
<p><br>
</p>
<p> Thanks for clarifying!</p>
<p><br>
</p>
<p> Yes that was quite silly of me to have nosym=.false., but yes it has no effect I still get the 'wrong g' error.</p>
<p><br>
</p>
<p> I will now manually specify the k-points and relay what happens later..</p>
<p><br>
</p>
<p> I am very interested in solving the bottleneck issue as I wish to perform a much more intensive calculation using a large amorphous cell, and later move on to using ESM, so I am debugging as best as I can to first understand the code and what exactly
causes the bottleneck. Are you able to share any additional technical information on this issue?</p>
<p><br>
</p>
<p>Thank you so much for you help and assistance,</p>
<p>Louis<br>
</p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> pw_forum-bounces@pwscf.org <pw_forum-bounces@pwscf.org> on behalf of Lorenzo Paulatto <lorenzo.paulatto@impmc.upmc.fr><br>
<b>Sent:</b> 08 February 2017 19:57:19<br>
<b>To:</b> PWSCF Forum<br>
<b>Subject:</b> Re: [Pw_forum] PW.x homogeneous electric field berry phase calculation in trigonal cell</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Wednesday, February 8, 2017 5:46:25 PM CET Louis Fry-Bouriaux wrote:<br>
> In your last email you mentioned the field 'pdir', I have not been able<br>
> to find this in the documentation, is this what you meant? <br>
<br>
It is the internal name of a variable in the subroutine that computes the <br>
macroscopic polarisation, but I think it is always gdir in the end.<br>
<br>
> as this is where the error is when I use other than gdir=3 (I added ln 364<br>
> to identify what fails exactly)<br>
<br>
I never did this myself, but from the code expects strings of k-points, one <br>
after each other. Each string is formed by nppstr k-points, aligned in the <br>
direction gdir; there can be as many string as you want, in principle to form <br>
a grid in the two directions orthogonal to gdir.<br>
<br>
Maybe in the case gdir=3 these string are formed "spontaneously" when using k-<br>
points automatic, but it does not work in the other cases. The polarisation <br>
(berry=.true.) and the electric field (lefield=.true.) codes are very similar, <br>
but not identical, in theory the second is more general, I'm not too familiar <br>
with either.<br>
<br>
I've noticed that you set nosym=.false., I'm quite sure that that swith is <br>
overridden with lefield, but to be sure, could you try to sisable it?<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Pw_forum mailing list<br>
Pw_forum@pwscf.org<br>
<a href="http://pwscf.org/mailman/listinfo/pw_forum">http://pwscf.org/mailman/listinfo/pw_forum</a><br>
</div>
</span></font></div>
</body>
</html>