<div>Hello everyone, I was just hoping to post an update. <br /></div><div><br /></div><div>After trying all of the following and more and seeing minor/no improvements:<br /><br />- lowering MIXING ALPHA (sped up convergence times)</div><div>- changing electronic temperature</div><div>- switching from CP2K v. 6.1.0 to the newest container available<br /></div><div>- testing out ASPC, PS, previous wave function extrapolators</div><div>- 2 vs 3 extrapolation order</div><div>- GAPW method</div><div>- changing CSVR TIMECON value</div><div><br /></div><div>My issue was actually my particle density! I was operating with a system 6x less dense than liquid aluminum, essentially a metal gas (just calling it for the laughs!). I decreased my unit cell dimensions and adjusted the number density - my MD job has been running for over 4 h (~5 h at the moment now) and has computed many more MD steps than usual (currently at #40, while it would normally crash after 4 h at step #10).</div><div><br /></div><div>Thank you everyone for all the help! I learned a lot of useful literature in the process, and I feel like my understanding of CP2K got better.</div><div><br /></div><div>Michela<br /></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Wednesday, May 29, 2024 at 9:27:25 AM UTC-4 Michela Benazzi 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;">Hello Marcella, thank you so much for your thorough response!!<br><br>I do not get any error message when my calculations stop without PRINT_LEVEL HIGH - there is just a line at the end of the output saying that the job timed out. At first, I thought that the issue might be on the computing side, but it's not. I was able to run other jobs (Al + methanol, instead of Al + CO2) for the runtime that I allocated, and I was using the same bash file settings, same basis sets for the same elements, same smearing temperature, etc. The only thing that changed were the coordinates and the # ADDED_MOs. <br><div><br></div><div>Could you explain what you mean by 'previous wavefunction' (regarding diagonalization)?<br></div><div><br></div>I might respond to this thread again once I try changing other parameters - grazie!<br><br>Michela<br><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Wednesday, May 29, 2024 at 3:52:37 AM UTC-4 Marcella Iannuzzi 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 Michela,<div><br></div><div>The dipole moment error is triggered by the PRINT_LEVEL HIGH </div><div>The calculation of the dipole moment is not explicitly requested in the input, but it is activated by the PRINT_LEVEL HIGH </div><div>Though, it is correct that the Berry phase approach cannot be applied to MOS with different occupation numbers.</div><div><br></div><div>This does not explain what happens when the calculation stops without PRINT_LEVEL HIGH . </div><div>Do you have an error message in that case too. </div><div><br></div><div>Just a few more comments concerning the computational settings. </div><div>The convergence of the SCF is very slow. Probably it could be improved adjusting some parameters, first of all reducing the mixing parameter ALPHA (e.g. 0.005), but also considering smearing temperature, EPS_DEFAULT, number of added mos and maybe cutoff.</div><div>You should also consider to use more accurate basis sets and VdW corrections. </div><div>When running MD with diagonalization, the ASPC extrapolator is a bad choice, better use the previous wave function , </div><div><br></div><div>Regards </div><div>Marcella</div><div><br><br></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Wednesday, May 29, 2024 at 12:06:05 AM UTC+2 <a rel="nofollow">bnzmi...@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"><div>Hello everyone,</div><div><br></div><div>I am using CP2K 6.1.0 (the cluster I have access to is not updated). My MD jobs have been timing out after 4 hours despite the CPU time allocation I specify (24 h). Other files run normally, so I am pretty sure that the issue is due to my input file. <br></div><div><br></div><div>I tried adding PRINT_LEVEL HIGH to get more information on the issue, and this is what comes up: Berry phase moments for non uniform MOs' occupation numbers not implemented. SCF converged successfully, and I am not sure if the issue is ADDED_MOs (I went by 20% of all available MOs), or if it intrinsic to SMEAR, which I need because I have a metallic system.<br></div><div><br></div><div>Please kindly refer to my attached input and output for more information. I would genuinely appreciate the help - this has been a roadblock for some time! Thank you very much and have a nice day,</div><div><br></div><div>Michela<br></div></blockquote></div></blockquote></div></blockquote></div> <p></p> -- <br /> You received this message because you are subscribed to the Google Groups "cp2k" group.<br /> To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:cp2k+unsubscribe@googlegroups.com">cp2k+unsubscribe@googlegroups.com</a>.<br /> To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/cp2k/4086b78d-b0e9-4c2c-ac29-3c418569446fn%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/cp2k/4086b78d-b0e9-4c2c-ac29-3c418569446fn%40googlegroups.com</a>.<br />