Graphene nano stripe (GNS) optimisation

[Giuseppe Zollo]

Dear All, 

I've been working for long time with QE.

Now I'm trying to get some results with CP2K (I'm new of this nice code).

A problem seems to arise for an edge patterned GNS I'm interested in. I hope to get some results with hybrid functionals that is very hard to obtain with plane waves as the unit cell is large. 

I get easy convergence only by using kpoints (no other attempt has been successful) and full periodic system (partial periodicity does not converge and system without kpoints and two unit cells along the stripe does not converge as well).

But the point Is that the structure, that I know is stable from plane waves QE calculations, is completely destroyed after few optimisation steps.

Maybe I'm missing something. 

Here I attach input, output and optimisation coordinates 

Any help will be appreciated, 

Regards 

[Jürg Hutter]

Hi
I don't have time to look closer into your problem but a quick inspection of the input file shows a major problem in your definition for the k-points.
The Wavefunction REAL option should not be used in you case, as the correct
WFN for a MP Grid of 1 1 8 will have complex wavefunctions.
regards
JH

________________________________________
From: cp...@googlegroups.com <cp...@googlegroups.com> on behalf of Giuseppe Zollo <1saq...@gmail.com>
Sent: Tuesday, February 11, 2025 12:15 PM
To: cp2k
Subject: [CP2K:21135] Graphene nano stripe (GNS) optimisation

--
You received this message because you are subscribed to the Google Groups "cp2k" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cp2k+uns...@googlegroups.com<mailto:cp2k+uns...@googlegroups.com>.
To view this discussion visit https://groups.google.com/d/msgid/cp2k/b438d7f7-fb8c-4ad3-a726-d58efc7b27f7n%40googlegroups.com<https://groups.google.com/d/msgid/cp2k/b438d7f7-fb8c-4ad3-a726-d58efc7b27f7n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Giuseppe Zollo]

Hello,

thank you so much for your time.

Unfortunately setting the wavefunctions to REAL  was the only way to make the simulation proceed. Indeed if a do not include this flag (so as to assume complex wavefunctions) the simulation hangs, as reported here, at the initials of the first SCF loop and the run crashes.

I'm using quite a lot memory so I assume that should not be a memory problem, should it be?

*******************************************************************************

                  Iteration          Convergence                     Energy [au]

 *******************************************************************************

                          1        0.240530                      -6.658276883875

                          2        0.153299                      -6.681113186074

                          3        0.339530E-02                  -6.698173661406

                          4        0.134821E-03                  -6.698181647940

                          5        0.672005E-06                  -6.698181660696

 Energy components [Hartree]           Total Energy ::           -6.698181660696

                                        Band Energy ::           -1.311151959578

                                     Kinetic Energy ::            3.482441966707

                                   Potential Energy ::          -10.180623627403

                                      Virial (-V/T) ::            2.923415156586

                                        Core Energy ::           -8.233425335600

                                          XC Energy ::           -2.899318720305

                                     Coulomb Energy ::            4.434562395209

                       Total Pseudopotential Energy ::          -11.749206534330

                       Local Pseudopotential Energy ::          -12.352996294377

                    Nonlocal Pseudopotential Energy ::            0.603789760047

                                        Confinement ::            0.333392320232

 Orbital energies  State     L     Occupation   Energy[a.u.]          Energy[eV]

                       1     0          2.000      -0.483136          -13.146798

                       1     1          2.000      -0.172440           -4.692332

 Total Electron Density at R=0:                                         4.671964

 Re-scaling the density matrix to get the right number of electrons

                  # Electrons              Trace(P)               Scaling factor

                          252               252.000                        1.000

 SCF WAVEFUNCTION OPTIMIZATION

  Step     Update method      Time    Convergence         Total energy    Change

  ------------------------------------------------------------------------------

[Frederick Stein]

Dear Giuseppe,

Have you already tried to run a series of test calculations with a smaller k-point grid, especially 1x1x1 with complex wave functions? CP2K prints some memory info at each MD step (Estimated peak process memory) and at the very end of a successful run. Do you have more output files such as from your batch system pointing to OOM-events?

Best,

Frederick

[Giuseppe Zollo]

Hello Frederick.

thanks for you reply.

I've just done what you suggest but I've got exactly the same issue.

And what is really strange is that no error or output from the scheduler si produced. 

This typically happens when you have memory problems but here I'm using 460 GB, that I think is more than enough 

[Frederick Stein]

That sounds pretty odd. It is also interesting that you can run a few MD steps. For debugging:-

- If you have compiled CP2K yourself, can you compile a pdbg? Or do you have pdbg available? Can you run your input file with this executable?

- If that is not available or the result not promissing enough: Can you add the TRACE and TRACE_MASTER keywords to your GLOBAL section and provide the last ca. 100 lines of the output (the actual output file will be pretty large). This would help to narrow down the error.

[Krack Matthias]

Hi

 

Did you already try to increase the OMP_STACKSIZE (e.g. export OMP_STACKSIZE=64MB)? Your original output shows that you are using the default size which might be too small.

 

HTH

 

Matthias

 

To unsubscribe from this group and stop receiving emails from it, send an email to cp2k+uns...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cp2k/659f0b75-58e3-4aa0-9107-1e74a0f044b4n%40googlegroups.com.

[Giuseppe Zollo]

Il giorno giovedì 13 febbraio 2025 alle 11:52:21 UTC+1 Frederick Stein ha scritto:

That sounds pretty odd. It is also interesting that you can run a few MD steps. For debugging:-

- If you have compiled CP2K yourself,

yes 

can you compile a pdbg?

yes 

Or do you have pdbg available?

yes 

Can you run your input file with this executable?

yes 

- If that is not available or the result not promissing enough: Can you add the TRACE and TRACE_MASTER keywords to your GLOBAL section and provide the last ca. 100 lines of the output (the actual output file will be pretty large). This would help to narrow down the error.

I've run the pdbg executable also adding TRACE and TRACE_MASTER  and I got this output where it crushes

000000:000128<<                            11      3 cp_fm_finish_copy_general       0.001 Hostmem: 871 MB GPUmem: 0 MB

 000000:000128>>                            11      3 cp_cfm_scale_and_add_fm       start Hostmem: 871 MB GPUmem: 0 MB

 000000:000128<<                            11      3 cp_cfm_scale_and_add_fm       0.000 Hostmem: 871 MB GPUmem: 0 MB

 000000:000128>>                            11      4 cp_fm_finish_copy_general       start Hostmem: 871 MB GPUmem: 0 MB

 000000:000128>>                               12    290 mp_waitall_1       start Hostmem: 871 MB GPUmem: 0 MB

 000000:000128<<                               12    290 mp_waitall_1       0.000 Hostmem: 871 MB GPUmem: 0 MB

 000000:000128<<                            11      4 cp_fm_finish_copy_general       0.001 Hostmem: 871 MB GPUmem: 0 MB

 000000:000128>>                            11      4 cp_cfm_scale_and_add_fm       start Hostmem: 871 MB GPUmem: 0 MB

 000000:000128<<                            11      4 cp_cfm_scale_and_add_fm       0.000 Hostmem: 871 MB GPUmem: 0 MB

 000000:000128>>                            11      1 cp_cfm_geeig       start Hostmem: 871 MB GPUmem: 0 MB

 000000:000128>>                               12      1 cp_cfm_cholesky_decompose       start Hostmem: 871 MB GPUmem: 0 MB

[Giuseppe Zollo]

Thanks. I've tried right now to export OMP_STACKSIZE up to 1GB and it continues to crush 

[Giuseppe Zollo]

Dear all of the staff. 

Thank you for your help. I've figured out the problem. It was caused by linking against MKL libraries (I really don't know why: they behave quite well and reliably for QE and SIESTA, f.i.). 

Now linking against AMD linear algebra libraries everything goes well: the usage of  complex wfc does not crash and a quick convergence is attained together with the correct stable structure that is extremely close to the one obtained with plane waves.

I write also to warn people about this problem that might possibly occur in AMD based HPCs.

Thanks again 
Giuseppe