[DFTB-Plus-User] On parallel version of DFTB+

[Ben Hourahine]

Hello ZhaoHui Hung,

in my case, single energy calculations for systems of up to 32,000
carbon atoms with ScaLAPACK. At this system size, the ELPA or PEXSI
solvers may be better suited to calculations (or if suitable, a linear
scaling method).

Regards

Ben 

On 13/09/16 21:37, ZHAOHUI HUANG wrote:
> OK. I will run a big loop to decide whether or not there are overlapped atoms. 
> btw, what is the largest structure have you tested with parallel version DFTB+?
> thanks.
>
> ZhaoHui Hung,
>
>
> ----- Original Message -----
> From: "Ben Hourahine" <benjamin.hourahine at strath.ac.uk>
> To: dftb-plus-user at mailman.zfn.uni-bremen.de
> Sent: Monday, September 12, 2016 3:26:34 AM
> Subject: Re: [DFTB-Plus-User] On parallel version of DFTB+
>
> Hello Huang,
>
> just to add to Bálint's comments, setting
>
> WriteHSDInput = No
>
> will prevent the code from trying to write the dftb_pin.hsd file which
> is where MAXRECL causes problems.
>
> As Bálint mentions, errors usually indicate atoms too close together,
> but the pdpotrf routine in some versions of ScaLAPACK can be a little
> temperamental. If you cannot find an obvious problem with the atom
> coordinates, is there an alternative version of the library installed
> that you can try?
>
> Regards
>
> Ben
>
> On 12/09/16 07:50, Bálint Aradi wrote:
>> Dear ZhaoHui Huang,
>>
>>> I have an issue from running parallel DFTB+. My unit cell contains
>>> 26,000 atoms and I just want to relax the structures a few steps. By
>>> running the code, I first get output overflow error message, then I
>>> increase MAXRECL parameter defined in HSDParser package. It runs
>>> indeed. but It failed by SCALAPACK error,
>> Yes, correct, this MAXRECL just comes from the fact, that we write out
>> the coordinates with one write statement, which at those system sizes
>> can be unfortunately problematic (depending on the compiler).
>>
>>> MAXNEIGHBORS: 8847 iSCC Total electronic   Diff electronic      SCC
>>> error Operation failed! ppotrf in scalafx_ppotrf_dreal Info: 23233
>>>
>>>
>>> Is there any code developer who is familiar with this part of code?
>>> thanks.
>> ppotrf is the wrapper around the pdpotrf routine in ScaLAPACK, which
>> does the Cholesky-decomposition. When it fails, it is often an
>> indication, that your overlap matrix is ill defined. Maybe some atoms
>> are unphysically close to each other (eventually due to periodic
>> boundary conditions)?. Can you somehow check, how close the atoms are to
>> each other. You may do it by analyzing the first few elements of the
>> iNeighbors(0:,1:nAtom) array. The first index goes over the neighbors of
>> a given atom (second index). It is never printed out anywhere, but it
>> should tell you when something is fishy.
>>
>>   Best regards,
>>
>>   Bálint
>>
>>
>>
>> _______________________________________________
>> DFTB-Plus-User mailing list
>> DFTB-Plus-User at mailman.zfn.uni-bremen.de
>> https://mailman.zfn.uni-bremen.de/cgi-bin/mailman/listinfo/dftb-plus-user
>>

-- 
      Dr. B. Hourahine, SUPA, Department of Physics,
    University of Strathclyde, John Anderson Building,
            107 Rottenrow, Glasgow G4 0NG, UK.
    +44 141 548 2325, benjamin.hourahine at strath.ac.uk

2013/14 THE Awards Entrepreneurial University of the Year
      2012/13 THE Awards UK University of the Year

   The University of Strathclyde is a charitable body,
        registered in Scotland, number SC015263