Hi Matt and Nick,<div><br></div><div>Thanks for your help! These information are very useful.</div><div><br></div><div>Regards,</div><div>Hongyang<br><br></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">在2021年4月10日星期六 UTC+10 上午4:16:05<Matt W> 写道：<br/></div><blockquote class="gmail_quote" style="margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Yeah. This is correct. You need the interaction to basically decay by half the cell length or weirdness might occur.<div><br></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Friday, April 9, 2021 at 6:32:53 PM UTC+1 <a href data-email-masked rel="nofollow">n...@berkeley.edu</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Another thing I suspect is tripping up this small system is the HFX implementation in CP2K. The way CP2K calculates HFX means that periodicity isn't handled nicely (maybe Matt can comment on why this is?) and so the HF interaction potential needs to decay before it reaches periodic images, this is why most people who are doing CP2K will use a truncated PBE0 with the truncation radius of 1/2 the minimum cell dimension. For HSE06, the the effective interaction distance is 1 / screening = 1 / .2 = 5 Angstroms. So for a primitive cell like you have, you're actually probably unphysically including HF effects across the periodic boundary, which could be what's making the calculation take so long. Just further reason to use cp2k for larger cells.<br><br><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Friday, April 9, 2021 at 6:09:07 AM UTC-7 Matt W wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I hadn't seen the earlier messages in another thread. At a quick glance your input looks fine. I'd decrease EPS_DEFAULT to 10^-14 or something to be sure things were set up accurately. Make sure you restart from a GGA converged solution.<div><br></div><div>It will, of course, get more expensive for bigger cells but in the limit of really big cells only linearly with sytem size. </div><div><br></div><div>CELL_OPT can be quite expensive with hybrids. You could just do a volume sweep with static calcs as you have a cubic cell.<br><div><br></div><div>Matt</div></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Friday, April 9, 2021 at 1:31:02 PM UTC+1 <a rel="nofollow">ma...@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Matt,<div><br></div><div>Yes, I know GAMMA point for such a small system doesn't make sense. I did this calculation just for exercise because I thought small system will save time. I thought a small system already took such a long time, the larger system would take much longer. But based on your description, it seems what I though is totally wrong. I would run some large supercell systems later. Thanks!</div><div>By the way, regarding the attached input file that I used, could you please have a look when you are free and provide some suggestions that may improve the performance (e.g., speed and stability) based on your expertise?</div><div><br></div><div>Thanks & Regards,</div><div>Hongyang<br><br></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">在2021年4月9日星期五 UTC+10 下午10:12:47<Matt W> 写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You can't run an 8 atom system without k-points, it doesn't make sense and you can't run hybrid functionals with k-points at the moment.<div><br></div><div>Absolute minimum is a 64 atom system (still nowhere near converged). For the HSE screened exchange, I'd suggest you wil need box dimensions of _at least_ 1 nm on each side otherwise strange things will happen. </div><div><br></div><div>If ADMM is working well the extra cost of going to bigger systems will not be too big. Plane wave code will be more efficient for the smallest cells, but CP2K should win out for bigger defect cells.</div><div><br></div><div>Matt<br><br></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Friday, April 9, 2021 at 9:47:52 AM UTC+1 <a rel="nofollow">ma...@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<div><br></div><div>I'm a beginner of using cp2k7.1. My aim is to use HSE06 to calculate the Si (8 atoms) system. However the calculating speed is extremly slow. I used OT and ADMM approaches and GAMMA point with 48 cores, but this CELL_OPT calculation took around 30 mins to finish. As a comparison, I used VASP to run the same geometry with HSE06 and with only 1 core, the calculation finished in 50 seconds... So clearly, I must did something wrong in the input file resulting in a significant limitation in the calculating speed but I couldn't figure out which part is wrong. Could somebody please provide some help? Thanks.</div><div><br></div><div>Regards,</div><div>Hongyang</div></blockquote></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div>