From yvan at ms.ifoc.kyushu-u.ac.jp Tue Mar 1 12:43:55 2005 From: yvan at ms.ifoc.kyushu-u.ac.jp (Yvan Girard) Date: Tue, 1 Mar 2005 20:43:55 +0900 Subject: [CPMD-list] Re: CPMD-list Digest, Vol 11, Issue 1 In-Reply-To: <200503011100.MAA32662@cpmd.org> References: <200503011100.MAA32662@cpmd.org> Message-ID: <200503012043.56131.yvan@ms.ifoc.kyushu-u.ac.jp> Le mardi 1 Mars 2005 20:00, cpmd-list-request at cpmd.org a ?crit?: > your gaussian job computes the total energy > for all electrons and CPMD only for the valence electrons. > > btw.: your plane wave cutoff if far too large for > the vanderbilt pseudopotentials that you are using. > 25ry should be sufficient. c'est dingue ce qu'il est sympa cet axel ! -- Yvan Girard Institute for Materials Chemistry and Engineering Kyushu University Fukuoka 812-8581, Japan http://trout.scc.kyushu-u.ac.jp/yoshizawaJ/Yoshizawa-lab-Eng/index-eng.htm From eunggun.kim at chemistry.gatech.edu Tue Mar 1 17:57:35 2005 From: eunggun.kim at chemistry.gatech.edu (Eung-Gun Kim) Date: Tue, 1 Mar 2005 11:57:35 -0500 Subject: [CPMD-list] ADJMU| BISECTION COULD NOT In-Reply-To: References: Message-ID: <1109696255.42249eff9f836@webmail.mail.gatech.edu> Dear Axel, Thanks very much for your kind reply. I tried KOHN-SHAM ENERGIES as you suggested, and unfortunately this workaround didn't work for me. Now I am trying to adjust the box size a little bit to see if I can get around with the error. Regards, EG Quoting Axel Kohlmeyer : > > On Thu, 24 Feb 2005, Eung-Gun Kim wrote: > > EK> Dear List Subscribers, > > dear eung-gun, > > [...] > EK> lately I found myself in the following situation when certain values of > KPOINTS > EK> are used: > EK> > EK> 1) All calculations go smoothly with ODIIS, independent of KPOINTS. > EK> 2) Restarting with the LANCZOS diago goes fine all the way through the > very > EK> last k point, and then crashes with > EK> "...SUBROUTINE ADJMU| BISECTION COULD NOT CONVERGE...". > EK> 3) This error sometimes goes away when k point grid ratios are > adjusted, say, > EK> from 2 8 14 to either 2 8 16 or 1 4 8. > EK> 4) Similar errors were also encountered in a system with different > contents > EK> and supercell size. > EK> 5) The error message complains about a small number of STATES. I feed > here > EK> with the total number of filled states, and a larger number is not > allowed > EK> by the code when switching from ODIIS to LANCZOS. And I don't see > a > EK> reason why I need a larger STATES for my organic crystals with > sizable > EK> band gaps. > > > i cannot tell you why you see this problem. i've seen it myself and > worked around it by simply running a KOHN-SHAM ENERGIES run after > the initial wavefunction optimization. IIRC, for lanczos you should add > about 10-20% virtual states to just provide the corresponding number on > the line after KOHN-SHAM ENERGIES. > > for all subsequent calculations you can then use the resulting restart > with the desired larger number of STATES given in the &SYSTEM section. > but since you seem only interested in the eigenvalues, the KS-energies > run should provide you with everthing you want. > > > regards, > axel. > EK> > EK> I am attaching portions of the input and output files of a representative > diago > EK> run below for your reference. Thanks very much for reading. > EK> > EK> Regards, > EK> > EK> EG Kim > EK> > EK> > ############################################################################### > EK> input file > -------------------------------------------------------------------- > EK> > EK> &CPMD > EK> RESTART COORDINATES WAVEFUNCTION > EK> OPTIMIZE WAVEFUNCTION > EK> LANCZOS DIAGONALISATION > EK> LANCZOS PARAMETER > EK> 200 8 0 1.D-8 > EK> STORE WAVEFUNCTIONS OFF > EK> MAXSTEP > EK> 1 > EK> &END > EK> > EK> &DFT > EK> FUNCTIONAL BLYP > EK> &END > EK> > EK> &SYSTEM > EK> ANGSTROM > EK> SYMMETRY > EK> ORTHORHOMBIC > EK> CELL ABSOLUTE DEGREE > EK> 7.92534743 10.6994 6.8 90.0 90.0 90.0 > EK> CUTOFF > EK> 70 > EK> CHARGE > EK> 0 > EK> STATES > EK> 92 > EK> KPOINTS MONKHORST-PACK > EK> 6 4 6 > EK> ...... > EK> ........ > EK> > EK> output file > ------------------------------------------------------------------- > EK> > EK> ........ > EK> ...... > EK> > EK> <<36:36<<<<<<<<<<<< LANCZOS DIAGONALIZATION <<<<<<<<<<<<<<<<<<<< > EK> >> TIME FOR INITIAL SUBSPACE DIAGONALIZATION: .70 > EK> >> CYCLE NCONV B2MAX B2MIN #HPSI TIME > EK> 1 92 2.248E-13 1.633E-15 1.00 .11 > EK> ADJMU| EIGENVALUES: > EK> 1 1 -0.744303257893736525 > EK> 1 2 -0.744207855529486761 > EK> 1 3 -0.744131382450865297 > EK> 1 4 -0.744046961929959005 > EK> 1 5 -0.713127925040847876 > EK> 1 6 -0.713072937556081698 > EK> 1 7 -0.712971653074167544 > EK> 1 8 -0.712869568517556229 > EK> > EK> .... > EK> .... > EK> .... > EK> > EK> 36 92 0.123545374312123368 > EK> AMU1= -0.745159946143003404 RHINT1= -183.944444444444457 > EK> AMU2= 0.133314578748302381 RHINT2= > -0.960653778747655451E-11 > EK> DAMU= 0.878474524891305730 RHINT = -183.944444444444457 > EK> RHINT-NEL= -183.944444444444457 > EK> ADJMU! THE NUMBER OF STATES [ 92 ] IS TOO SMALL > EK> > EK> > EK> PROGRAM STOPS IN SUBROUTINE ADJMU| BISECTION COULD NOT CONVERGE [PROC= > 0] > EK> > EK> > EK> _______________________________________________ > EK> CPMD-list mailing list > EK> CPMD-list at cpmd.org > EK> http://cpmd.org/mailman/listinfo/cpmd-list > EK> > EK> > > -- > > ======================================================================= > Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de > Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 > Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 > D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ > ======================================================================= > If you make something idiot-proof, the universe creates a better idiot. > > -- + - | Eung-Gun Kim, Ph.D. | Postdoctoral Fellow | School of Chemistry and Biochemistry | Georgia Institute of Technology | Atlanta, GA 30332-0400 | U.S.A. + - | Phone: +1.404.894.6456 | Email: eunggun.kim at chemistry.gatech.edu + - From yvan at ms.ifoc.kyushu-u.ac.jp Wed Mar 2 13:15:51 2005 From: yvan at ms.ifoc.kyushu-u.ac.jp (Yvan Girard) Date: Wed, 2 Mar 2005 21:15:51 +0900 Subject: [CPMD-list] Re: CPMD-list Digest, Vol 11, Issue 2 In-Reply-To: <200503021101.MAA29856@cpmd.org> References: <200503021101.MAA29856@cpmd.org> Message-ID: <200503022115.51747.yvan@ms.ifoc.kyushu-u.ac.jp> Ref : << c'est dingue ce qu'il est sympa cet axel >> Wooops! Sorry, I had a small email mishap ! ^_^;;; This comment was supposed to reach a friend of mine, not everyone in the list!! But it means that "Axel is a very nice guy", so I hope he will forgive me! Yvan From fritsch at hmi.de Wed Mar 2 14:25:44 2005 From: fritsch at hmi.de (Wolfgang Fritsch) Date: Wed, 02 Mar 2005 14:25:44 +0100 Subject: [CPMD-list] cpmd2cube does not compile Message-ID: <4225BED8.8040709@hmi.de> Hi, I cannot compile cpmd2cube on a Dec-Alpha machine. I find many entries about this in the list, which, however, are a few months old and do not seem to help. On running make I am getting Fortran messages that seem to indicate that the Fortran source is all garbled: f90 -c -C -D__alpha -DFFT_DEFAULT -DLAPACK -DPOINTER8 kinds.F f90: Error: Illegal character in statement label field [M] f90: Error: Illegal character in statement label field [O] f90: Error: Illegal character in statement label field [D] f90: Error: Illegal character in statement label field [U] f90: Error: Illegal character in statement label field [L] f90: Error: First statement in file must not be continued f90: Error: kinds.F, line 20: Illegal character in statement label field [I] IMPLICIT NONE f90: Error: kinds.F, line 20: Illegal character in statement label field [M] f90: Error: kinds.F, line 20: Illegal character in statement label field [P] IMPLICIT NONE ----^ .... f90: Error: kinds.F, line 29: Illegal character in statement label field [I] INTEGER, PARAMETER :: qpr = selected_real_kind(24,60) --^ f90: Error: kinds.F, line 29: Illegal character in statement label field [N] INTEGER, PARAMETER :: qpr = selected_real_kind(24,60) ---^ f90: Error: kinds.F, line 29: Illegal character in statement label field [T] INTEGER, PARAMETER :: qpr = selected_real_kind(24,60) ----^ f90: Severe: Too many errors, exiting Now, I can read Fortran 77 and I am ready to learn Fortran 90 if this is what it takes to fix the problem. But surely something more basic has struck me here? I am attaching file kinds.F as it arrived here, just in case. Thanks for any hints, Wolfgang -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: kinds.F Url: http://cpmd.org/pipermail/cpmd-list/attachments/20050302/c24e24be/attachment.cc From ara_1357_2416 at yahoo.com Wed Mar 2 14:57:12 2005 From: ara_1357_2416 at yahoo.com (Younes Ansari) Date: Wed, 2 Mar 2005 05:57:12 -0800 (PST) Subject: [CPMD-list] no changes in trajectory Message-ID: <20050302135712.76822.qmail@web50901.mail.yahoo.com> Dear CPMD-list : I trying to study the interactions of Cs slab which is contain 22 (BCC) atoms of Cs. Cs atoms at 301.15 K make a liquid phase and must behave like a liquid, but when I do a CP calculation and visualize it with VMD atoms just shake in there symmetry position and dose not move. So I tried to use the term TEMPERATURE ELECTRON at the same degree with TEMPERATURE but after 9:00 hours I just got same results. I want to know how I can move atoms in a box of 22 Cs in bcc net. &CPMD MOLECULAR DYNAMICS CP NOGEOCHECK TRAJECTORY XYZ TEMPERATURE 301.5 TEMPERATURE ELECTRON 301.5 ALEXANDER MIXING 0.9 MAXSTEP 1000 &END &SYSTEM SYMMTRY 1 CELL 10.000 1.0 1.0 0.0 0.0 0.0 CUTOFF 70 ANGSTROM &END . . . . --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cpmd.org/pipermail/cpmd-list/attachments/20050302/3d3be000/attachment.html From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Wed Mar 2 15:12:09 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Wed, 2 Mar 2005 15:12:09 +0100 (CET) Subject: [CPMD-list] cpmd2cube does not compile In-Reply-To: <4225BED8.8040709@hmi.de> Message-ID: On Wed, 2 Mar 2005, Wolfgang Fritsch wrote: WF> Hi, WF> WF> I cannot compile cpmd2cube on a Dec-Alpha machine. I find many entries WF> about this in the list, which, however, are a few months old and do not WF> seem to help. WF> WF> On running make I am getting Fortran messages that seem to indicate that WF> the Fortran source is all garbled: WF> WF> f90 -c -C -D__alpha -DFFT_DEFAULT -DLAPACK -DPOINTER8 kinds.F WF> f90: Error: Illegal character in statement label field [M] WF> f90: Error: Illegal character in statement label field [O] WF> f90: Error: Illegal character in statement label field [D] WF> f90: Error: Illegal character in statement label field [U] WF> f90: Error: Illegal character in statement label field [L] WF> f90: Error: First statement in file must not be continued no, it is just that the compiler assumes fixed format because of the .F in the file name. please try adding -free to FFLAGS. axel. -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Wed Mar 2 16:02:08 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Wed, 02 Mar 2005 16:02:08 +0100 Subject: [CPMD-list] no changes in trajectory In-Reply-To: Your message of "Wed, 02 Mar 2005 05:57:12 PST." <20050302135712.76822.qmail@web50901.mail.yahoo.com> Message-ID: <200503021502.j22F28k09523@yello.theochem.ruhr-uni-bochum.de> >>> "YA" == Younes Ansari writes: YA> Dear CPMD-list : YA> I trying to study the interactions of Cs slab which is contain 22 (BCC) atoms of Cs. YA> Cs atoms at 301.15 K make a liquid phase and must behave like a liquid, but when I do a CP calculation and visualize it with VMD atoms just shake in there symmetry position and dose not move. YA> So I tried to use the term TEMPERATURE ELECTRON at the same degree with TEMPERATURE but after 9:00 hours I just got same results. I want to know how I can move atoms in a box of 22 Cs in bcc net. dear younes ansari, please check the documentation more closely and have a look at the output of your simulation (or the ENERGIES files). as pointed out earlier TEMPERATURE ELECTRON is only useful for FREE ENERGY FUNCTIONAL calculations and sets the degree of 'smearing' of the bands. in fact, for a meaningful car-parrinello MD you want to have the _fictitious_ kinetic energy of the electrons to be almost zero. now, if you use the keyword TEMPERATURE, this will only set the _initial_ temperature of your system. since your atoms will move out of the equilibrium position, kinetic energy will be converted to potential energy and your instantaneous temperature will be significantly lower after a while. check your output. to get the desired temperature you'll have to use some thermostatting scheme. during equilibration, this is most easily done by using TEMPCONTROL IONS, during production runs (i.e. once your md has reached equilibrium), you either turn it off or use NOSE IONS. this is demonstrated with some examples at: ttp://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/cpmd-tutor/part6.html also you should be aware of the fact, that with most liquids you have librational modes in addition to the changes of position and that due to the small system size you may need a much higher temperature to 'melt' a crystal. please be also aware, that you are working under constant volume conditions. this problem also arises for classical MD and there is a ton of literature available. please also note (as has been pointed out to you previously, too), that you _must_ start a regular car-parrinello MD from a previously calculated (i.e. optimized) wavefunction using RESTART. final question: why do you have to use NOGEOCHECK ? if the geometry check prints an error, it is almost always for a very good reason. best regards, axel YA> &CPMD YA> MOLECULAR DYNAMICS CP YA> NOGEOCHECK YA> TRAJECTORY XYZ YA> TEMPERATURE YA> 301.5 YA> TEMPERATURE ELECTRON YA> 301.5 YA> ALEXANDER MIXING YA> 0.9 YA> MAXSTEP YA> 1000 YA> &END YA> &SYSTEM YA> SYMMTRY YA> 1 YA> CELL YA> 10.000 1.0 1.0 0.0 0.0 0.0 YA> CUTOFF YA> 70 YA> ANGSTROM YA> &END YA> . YA> . YA> . YA> . YA> --------------------------------- YA> Celebrate Yahoo!'s 10th Birthday! YA> Yahoo! Netrospective: 100 Moments of the Web YA> --0-1557460432-1109771832=:73921 YA> Content-Type: text/html; charset=us-ascii -- ======================================================================= Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From Nico.Zobel at TU-Berlin.DE Thu Mar 3 10:44:36 2005 From: Nico.Zobel at TU-Berlin.DE (Nico.Zobel at TU-Berlin.DE) Date: Thu, 3 Mar 2005 10:44:36 +0100 (CET) Subject: [CPMD-list] md-run: crystal seems to explode Message-ID: <52770.130.149.74.45.1109843076.squirrel@mailbox.TU-Berlin.DE> Dear Axel, your hints were extremely helpful. Thank you very much! I did two test-runs: 3000 timesteps of 2.0 a.u. at 300 K and 5000 timesteps at 800 K. In both cases the crystal seems to be stable. As you suggested I changed CONVERGENCE ORBITALS from 2.d-5 to 1.d-6, CUTOFF from 60 to 30 Ry, TESR from 4 to 1 and I added GC-CUTOFF 5.d-6 DUAL 5.0 CHARGE -1. The patches you provided have not been tested yet. That is going to happen within the next few days (as soon as they are implemented at the HLRN). But I have some further questions regarding your remarks: AK> NZ> 84 Mg .000000 11.692680 15.590239 3 AK> NZ> 85 Mg 7.795120 11.692680 15.590239 3 AK> NZ> **************************************************************** AK> NZ> AK> NZ> NUMBER OF STATES: 164 AK> NZ> NUMBER OF ELECTRONS: 327.00000 AK> NZ> CHARGE: .00000 AK> AK> oooops. you have an odd number of electrons. i.e. you'll either need to AK> adjust the charge of your system or run an 'open-shell' calculation by AK> using the LSD keyword in the &CPMD section. note, that with LSD and PBE AK> you'll need an update to your CPMD code. i'll attach a patch with AK> the changes that will be in cpmd-v3.9.2, but it may not apply cleanly AK> to the pristine cpmd-v3.9.1 sources (there were some overlapping AK> other changes), YMMV. As mentioned above, I could not test the patch so far. That is why I added one electron by setting CHARGE to -1. Do you think adding that electron leads to a significant change in the chemical behaviour of my system? (I want to estimate activation energy by blue-moon-ensemble method) In other words: If the patch does not apply cleanly (as you mentioned), can I still get reasonable results by adding that electron? AK> NZ> ============================================================ AK> NZ> | pseudopotential report: version 7.3.5 date 10-15-2004 | AK> NZ> ------------------------------------------------------------ AK> NZ> | mg (Vol05) PBE - GGA exchange-corr | AK> NZ> | z = 12.00 zv = 2.00 exfact = 5.00000 | AK> NZ> | etot = -1.65416 | AK> NZ> | index orbital occupation energy | AK> NZ> | 1 300 2.00 -.35 | AK> NZ> | keyps = 3 ifpcor = 0 | AK> NZ> | rinner = 1.43 for L= 1 | AK> NZ> | rinner = 1.43 for L= 2 | AK> NZ> | rinner = 1.43 for L= 3 | AK> NZ> | new generation scheme: | AK> NZ> | nbeta = 4 kkbeta = 583 rcloc = 3.1000 | AK> NZ> | ibeta l epsilon rcut iptype | AK> NZ> | 1 0 .00 3.00 0 | AK> NZ> | 2 0 -.35 3.00 0 | AK> NZ> | 3 1 .00 3.00 2 | AK> NZ> | 4 1 -.35 3.00 2 | AK> NZ> | npf = 6 ptryc = 8.000 | AK> NZ> | lloc = 2 eloc = .000 | AK> NZ> | ifqopt = 3 nqf = 6 qtryc = 8.000 | AK> NZ> | all electron calculation used koelling-harmon equation | AK> NZ> | ************logarithmic mesh************ | AK> NZ> ============================================================ AK> AK> i am not 100% certain, that your mg-pseudo is compatible with cpmd. AK> could you pleas apply the second attached patch to make the uspp AK> reader reject incompatible potential files. this patch should also AK> work for people still using v3.7.2, btw. Again: This patch has not been tested, either. My question is: Which parameter(s) of the pseudopotential make you think that it might be incompatible? Maybe I can easily adjust the PP (i.e. the parameters in Vanderbilt's code) to make it compatible ... Thank you very much in advance - Nico. -- Dipl.Ing.?Nico?Zobel Technische?Universit?t?Berlin?? Institut?f?r?Energietechnik?? Fachgebiet?Energieverfahrenstechnik?und?? Umwandlungstechniken?regenerativer?Energien (EVUR) Fon:???+49?30?314?24381 Fax:???+49?30?314?22157?????????????? Sekretariat?RDH?9?? Fasanenstr.?89?? D-10623?Berlin From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Thu Mar 3 12:45:03 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Thu, 3 Mar 2005 12:45:03 +0100 (CET) Subject: [CPMD-list] md-run: crystal seems to explode In-Reply-To: <52770.130.149.74.45.1109843076.squirrel@mailbox.TU-Berlin.DE> Message-ID: On Thu, 3 Mar 2005 Nico.Zobel at TU-Berlin.DE wrote: NZ> AK> NZ> NUMBER OF STATES: 164 NZ> AK> NZ> NUMBER OF ELECTRONS: 327.00000 NZ> AK> NZ> CHARGE: .00000 NZ> AK> NZ> AK> oooops. you have an odd number of electrons. i.e. you'll either need to NZ> AK> adjust the charge of your system or run an 'open-shell' calculation by NZ> AK> using the LSD keyword in the &CPMD section. note, that with LSD and PBE NZ> AK> you'll need an update to your CPMD code. i'll attach a patch with NZ> AK> the changes that will be in cpmd-v3.9.2, but it may not apply cleanly NZ> AK> to the pristine cpmd-v3.9.1 sources (there were some overlapping NZ> AK> other changes), YMMV. NZ> NZ> As mentioned above, I could not test the patch so far. That is why I added NZ> one electron by setting CHARGE to -1. NZ> Do you think adding that electron leads to a significant change in the NZ> chemical behaviour of my system? (I want to estimate activation energy by NZ> blue-moon-ensemble method) NZ> In other words: NZ> If the patch does not apply cleanly (as you mentioned), can I still get NZ> reasonable results by adding that electron? adding or removing an electron does change the chemistry of your system significantly. shuffling electrons around, is what chemistry is mostly about. there is a huge difference in the chemistry of, say, a mg+ and an mg++ ion. you need to know the the total charge of your system first. if that results in an odd number of electrons, you _have_ to use LSD (or use a different compound). [...] NZ> AK> NZ> ============================================================ NZ> AK> NZ> | pseudopotential report: version 7.3.5 date 10-15-2004 | NZ> AK> NZ> ------------------------------------------------------------ NZ> AK> NZ> | mg (Vol05) PBE - GGA exchange-corr | NZ> AK> NZ> | z = 12.00 zv = 2.00 exfact = 5.00000 | NZ> AK> NZ> | etot = -1.65416 | NZ> AK> NZ> | index orbital occupation energy | NZ> AK> NZ> | 1 300 2.00 -.35 | NZ> AK> NZ> | keyps = 3 ifpcor = 0 | NZ> AK> NZ> | rinner = 1.43 for L= 1 | NZ> AK> NZ> | rinner = 1.43 for L= 2 | NZ> AK> NZ> | rinner = 1.43 for L= 3 | NZ> AK> NZ> | new generation scheme: | NZ> AK> NZ> | nbeta = 4 kkbeta = 583 rcloc = 3.1000 | NZ> AK> NZ> | ibeta l epsilon rcut iptype | NZ> AK> NZ> | 1 0 .00 3.00 0 | NZ> AK> NZ> | 2 0 -.35 3.00 0 | NZ> AK> NZ> | 3 1 .00 3.00 2 | NZ> AK> NZ> | 4 1 -.35 3.00 2 | NZ> AK> NZ> | npf = 6 ptryc = 8.000 | NZ> AK> NZ> | lloc = 2 eloc = .000 | NZ> AK> NZ> | ifqopt = 3 nqf = 6 qtryc = 8.000 | NZ> AK> NZ> | all electron calculation used koelling-harmon equation | NZ> AK> NZ> | ************logarithmic mesh************ | NZ> AK> NZ> ============================================================ NZ> AK> NZ> AK> i am not 100% certain, that your mg-pseudo is compatible with cpmd. NZ> AK> could you pleas apply the second attached patch to make the uspp NZ> AK> reader reject incompatible potential files. this patch should also NZ> AK> work for people still using v3.7.2, btw. NZ> Again: This patch has not been tested, either. in contrast to the other, it should apply cleanly. NZ> My question is: NZ> Which parameter(s) of the pseudopotential make you think that it might be NZ> incompatible? the fact that the s-projectors do not have the same iptype as the p-projectors. all uspps that i know to be working have them all set to the same value (iptype 2). this is just a wild guess, though. regards, axel. NZ> Maybe I can easily adjust the PP (i.e. the parameters in Vanderbilt's NZ> code) to make it compatible ... NZ> NZ> Thank you very much in advance - NZ> Nico. NZ> NZ> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From ketajone at yahoo.com Thu Mar 3 20:10:11 2005 From: ketajone at yahoo.com (Keta Jones) Date: Thu, 3 Mar 2005 11:10:11 -0800 (PST) Subject: [CPMD-list] Equilibration of organic molecules in water Message-ID: <20050303191011.18589.qmail@web52704.mail.yahoo.com> Dear All, I have a pre-equilibrated structure of 107 water molecules and one cl- ion. Now I want to study one organic molecule( cycloxexanone ) in 107 water. I somehow feel that cl- can be replaced by cyclohexanone. It will be great if someone can guide me to do this in details. Are there any easy other fast(in terms of eulibration period) programmes so that I can equlibrate these systems there and after that I can study in CPMD ? From Aexl's webpage I came across moldy.But can it handle the molecule like cyclohexanone in water ? or will it be easy to extract the input for CPMD for such system from moldy. I had problems getting xyz format from moldy. Please help.Help will be greatly appreciated. Thanks in advance ===== Keta ************************************************************************************** __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Thu Mar 3 21:07:17 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Thu, 03 Mar 2005 21:07:17 +0100 Subject: [CPMD-list] Equilibration of organic molecules in water In-Reply-To: Your message of "Thu, 03 Mar 2005 11:10:11 PST." <20050303191011.18589.qmail@web52704.mail.yahoo.com> Message-ID: <200503032007.j23K7HY03263@yello.theochem.ruhr-uni-bochum.de> >>> "KJ" == Keta Jones writes: KJ> Dear All, dear keta, KJ> I have a pre-equilibrated structure of 107 water KJ> molecules and one cl- ion. Now I want to study KJ> one organic molecule( cycloxexanone ) in 107 water. KJ> I somehow feel that cl- can be replaced by KJ> cyclohexanone. It will be great if someone can guide KJ> me to do this in details. sorry to disagree, but the cyclohexanone (i assume you mean that, since i am not aware of a compound named cycloxexanone) molecule is too large. if you would find a way to squeeze it in there, you would get a _massive_ soundwave running through your system (and it won't stop at the borders due to the PBC). KJ> Are there any easy other fast(in terms of eulibration KJ> period) programmes so that I can KJ> equlibrate these systems there and after that I can KJ> study in CPMD ? From Aexl's webpage I came across for a molecule like this solvated in water most classical MD codes would do. you simply need a reasonable set of force field parameters. KJ> moldy.But can it handle the molecule like KJ> cyclohexanone in water ? or will it be easy to extract KJ> the input for CPMD for such system from moldy. I had KJ> problems getting xyz format from moldy. why? running mdshak -c -f xyz on a moldy text mode restart used to work nicely for me. ;-) moldy only works for rigid molecules, and defining the parameters for a larger molecule can be tedious. you may want to have a look at the gromacs code instead (http://www.gromacs.org/). if you are lucky, you can find a contributed topology file for your molecule (they have a sizable collection). you only have to be careful with the coordinates. .gro files are in nanometers, so you have to multiply accordingly or convert them to .pdb or .xyz. regards, axel. KJ> Please help.Help will be greatly appreciated. KJ> Thanks in advance KJ> ===== KJ> Keta KJ> ************************************************************************************** KJ> __________________________________________________ KJ> Do You Yahoo!? KJ> Tired of spam? Yahoo! Mail has the best spam protection around KJ> http://mail.yahoo.com KJ> _______________________________________________ KJ> CPMD-list mailing list KJ> CPMD-list at cpmd.org KJ> http://cpmd.org/mailman/listinfo/cpmd-list -- ======================================================================= Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From ketajone at yahoo.com Thu Mar 3 21:54:12 2005 From: ketajone at yahoo.com (Keta Jones) Date: Thu, 3 Mar 2005 12:54:12 -0800 (PST) Subject: [CPMD-list] Equilibration of organic molecules in water In-Reply-To: <200503032007.j23K7HY03263@yello.theochem.ruhr-uni-bochum.de> Message-ID: <20050303205412.56275.qmail@web52704.mail.yahoo.com> Dear Dr Axel, I am very very sorry for the word cyclohexexanone. It is actually cyclohexanone. My aim is to solvate either benzene or cyclohexanone in water. If cyclohexanone will be large enough what about benzene ? After going thhrough the following reference i.e J. Am. Chem. Soc.2004; 126(20); 6280-6286. Boero, M.; Ikeshoji, T.; Liew, C. C.; Terakura, K.; Parrinello, M. I feel that this can be done. In this article they cleaved the required space, corresponding to four water monomers, to allocate the cyclohexanone oxime and reequili-brated for about 5 ps. Here the pre equilibrated co-ordinates of 64 water molecules have taken for the cyclohexanone study. So I want to know how this can be done, means some hints. For I was confused regarding that DUMP files in moldy input file. I will see it again. Many many thanks to Dr Axel for this superb job. regards, keta --- Axel Kohlmeyer wrote: > > >>> "KJ" == Keta Jones writes: > > KJ> Dear All, > > > dear keta, > > > KJ> I have a pre-equilibrated structure of 107 water > KJ> molecules and one cl- ion. Now I want to study > KJ> one organic molecule( cycloxexanone ) in 107 > water. > KJ> I somehow feel that cl- can be replaced by > KJ> cyclohexanone. It will be great if someone can > guide > KJ> me to do this in details. > > sorry to disagree, but the cyclohexanone (i assume > you > mean that, since i am not aware of a compound named > cycloxexanone) molecule is too large. if you would > find > a way to squeeze it in there, you would get a > _massive_ > soundwave running through your system (and it won't > stop > at the borders due to the PBC). > > KJ> Are there any easy other fast(in terms of > eulibration > KJ> period) programmes so that I can > KJ> equlibrate these systems there and after that I > can > KJ> study in CPMD ? From Aexl's webpage I came > across > > for a molecule like this solvated in water most > classical MD > codes would do. you simply need a reasonable set of > force > field parameters. > > KJ> moldy.But can it handle the molecule like > KJ> cyclohexanone in water ? or will it be easy to > extract > KJ> the input for CPMD for such system from moldy. I > had > KJ> problems getting xyz format from moldy. > > why? running mdshak -c -f xyz on a moldy text mode > restart > used to work nicely for me. ;-) > > moldy only works for rigid molecules, and defining > the parameters > for a larger molecule can be tedious. you may want > to have > a look at the gromacs code instead > (http://www.gromacs.org/). > if you are lucky, you can find a contributed > topology file > for your molecule (they have a sizable collection). > you only have to be careful with the coordinates. > .gro files > are in nanometers, so you have to multiply > accordingly or > convert them to .pdb or .xyz. > > > regards, > axel. > > KJ> Please help.Help will be greatly appreciated. > > > > > > KJ> Thanks in advance > > > KJ> ===== > KJ> Keta > KJ> > ************************************************************************************** > > KJ> > __________________________________________________ > KJ> Do You Yahoo!? > KJ> Tired of spam? Yahoo! Mail has the best spam > protection around > KJ> http://mail.yahoo.com > KJ> _______________________________________________ > KJ> CPMD-list mailing list > KJ> CPMD-list at cpmd.org > KJ> http://cpmd.org/mailman/listinfo/cpmd-list > > > > -- > > ======================================================================= > Axel Kohlmeyer e-mail: > axel.kohlmeyer at theochem.ruhr-uni-bochum.de > Lehrstuhl fuer Theoretische Chemie Phone: > ++49 (0)234/32-26673 > Ruhr-Universitaet Bochum - NC 03/53 Fax: > ++49 (0)234/32-14045 > D-44780 Bochum > http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ > ======================================================================= > If you make something idiot-proof, the universe > creates a better idiot. > ===== Keta ************************************************************************************** __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Thu Mar 3 22:38:27 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Thu, 3 Mar 2005 22:38:27 +0100 (CET) Subject: [CPMD-list] Equilibration of organic molecules in water In-Reply-To: <20050303205412.56275.qmail@web52704.mail.yahoo.com> Message-ID: On Thu, 3 Mar 2005, Keta Jones wrote: KJ> Dear Dr Axel, KJ> KJ> I am very very sorry for the word cyclohexexanone. It KJ> is actually cyclohexanone. My aim is to solvate either KJ> benzene or cyclohexanone in water. If cyclohexanone KJ> will be large enough what about benzene ? KJ> KJ> After going thhrough the following reference i.e KJ> J. Am. Chem. Soc.2004; 126(20); 6280-6286. KJ> Boero, M.; Ikeshoji, T.; Liew, C. C.; Terakura, K.; KJ> Parrinello, M. I feel that this can be done. dear keta, in your original mail, you did not mention, that you would remove water molecules, so i had to assume the worst case. of course the procedure proposed in the paper you mentioned can be done. in my personal opinon it would be simpler to set up a classical pre-equilibration, but this may be simply due to the fact, that i have quite a bit of practice with that. the classical equilibration will become problematic, if you don't have a reasonable force-field parameters. for benzene they _do_ exist. in fact there is a large number of classical MD studies of benzene solutions and benzene/water mixtures. cyclohexanone can probably be done, too. remember that for classical pre-equilibration you don't need perfect force-field parameters, but only reasonable ones. i don't know the details of the paper above, but i would want to do something similar, i'd freeze the coordinates of all distant water molecules, 'dig' a large enough hole, add the new molecule, and then optimize the coordinates for a limited number of steps. in the following i would unfreeze more and more and more coordinates and then do either short MD runs or geometry optimizations, depending on how much pointential energy you have to remove. as mentioned in my previous mail, you want to avoid sending a shockwave through your system as it will ruin the dynamics. regards, axel. -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From bob at bob.usuhs.mil Fri Mar 4 19:33:15 2005 From: bob at bob.usuhs.mil (Robert Williams) Date: Fri, 04 Mar 2005 13:33:15 -0500 Subject: [CPMD-list] "MEMORY| ALLOCATION FAILED" error message In-Reply-To: References: Message-ID: <4228A9EB.8080001@bob.usuhs.mil> Dear Leonardo, I'm not quite sure I know what the memory limitations might be for a 32 bit kernel running on an opteron. Are you sure this is a Fedora distributed kernel for opteron that is configured for only 32 bits? Assuming that your test job is a very small one and that memory is not an issue, the kernel may be the problem. I have not tested this particular patched version of 2.6.9. I'm surprized and pleased to hear that it works for you in serial non-smp mode. All I can say about 2.6.9 is that a pristine 2.6.9, and early Fedora 2 2.6.8 and 2.6.9 kernels, (non-smp) yielded the allocation error even with stacksize unlimited. I never identified the specific problem with the kernels that did not work. I just tested about ten variations on three kernel versions and stopped when I found one that worked. The 2.6.5 kernel that I am presently using with CPMD is not SMP, although I vaguely recall that the SMP version did work...on a single multithreaded P4 cpu. However, you can compile and run a pristine unpatched kernel on Fedora 3, so you would not have to change distributions. You can test 2.6.5, and perhaps some other kernels depending on how much experience you have in configuring and building linux kernels. If you do this, it would be useful to know what you learn. I should warn you that I have not run the 2.6.5 kernel on Fedora 3 yet. I've built one...and I'm a weekend away from trying it. This is a job only for someone who has a day or two to waste, and some experience with kernel builds: Briefly, fetch 2.6.5 from kernel.org, unpack it in /usr/src, symlink it to "linux", cp my .config file to that directory (The name must be ".config"), edit .config and set the following: CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_SMP=y Note that there may be other options related to running on an opteron that may require some testing. You indicate that you are running a 32 bit kernel...why?...for example. Run "make oldconfig". At this point you may want to run "make xconfig" to change anything else that seems appropriate. Edit "Makefile" and make the change "EXTRAVERSION = -lg1" to make this version unique. Run "make bzImage; make modules; make modules_install; cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.6.5-lg1; cp /usr/src/linux/System.map /boot/System.map-2.6.5-lg1; cp /usr/src/linux/.config /boot/config-2.6.5-lg1; /sbin/new-kernel-pkg --mkinitrd --depmod --install 2.6.5-lg1", and edit /boot/grub/grub.conf and change your 2.6.5 entry to point at your specific device. My grub.conf entry for this kernel is thus: title Fedora Core (2.6.5-bob1) root (hd0,0) kernel /vmlinuz-2.6.5-bob1 ro root=/dev/hda2 rhgb quiet initrd /initrd-2.6.5-bob1.img And...edit /etc/fstab to change your entries there in a similar fashion: /dev/hda2 / ext3 defaults 1 1 /dev/hda1 /boot ext3 defaults 1 2 #LABEL=/ / ext3 defaults 1 1 #LABEL=/boot /boot ext3 defaults 1 2 Use comments "#" so you can find your way back. and, assuming I've not left something out, you should be ready to boot your new 2.6.5 kernel. You might want to edit /boot/grub/grub.conf to change the default boot kernel, and if you find that it works you may want to run "make xconfig" on the kernel to fix it up for your own system, but there it is. I must admit that I'm a bit irritated that this problem with the linux kernel has cropped up and continues to bite us. One path toward a real solution would be to provide a willing kernel developer with a binary of cpmd and a little makefile to run test jobs. I don't have the authority to be handing out cpmd codes. Bob Leonardo Guidoni wrote: > Dear Bob, dear Bayu and dear all, > I am working on a Fedora 3 with a 2.6.9-1.667smp kernel > (opteron double proc. with 32 bit kernel). > and I have the same problem of MEMORY ALLOCATION FAILED. > On one processor I found that setting > limit stacksize unlimited > solves the problem. > Anyway as son as I run in parallel one of the processor other > than parent has the same fatal error. > I put the limit instruction on > /etc/profile and /etc/csh.cshrc but with no results. > Do you think I can solve the problem without changing > distribution? > Thanks in advance > > Leonardo > > Dear Bayu, > > There is a "bug" in at least some kernel versions greater than > 2.6.5 that appear to be related to this problem. > I ran quite a few tests and found that a pristine > (non-fedora) 2.6.5 kernel will solve this memory allocation > error. > I'm not sure about the latest kernels. I haven't tested 2.6.10 > yet. > I've attached my .config file. > > Bob Williams > > s101bayu at mail.chem.itb.ac.id wrote: > >>Dear All, >> >>I am having some issues in running the test programs that is > > provided at the > >>cpmd.org site. When I ran the code using the test inputs I > > get, "MEMORY| > >>ALLOCATION FAILED" error message. >> >>My machine is an Intel Pentium 4 based running Fedora Core 3, > > Clustering > >>with OSCAR and I >>compiled the code using intel fortran compiler. Here is my > > make file: > >>#QMMM_FLAGS = -D__QMECHCOUPL >>#QMMM_LIBS = -L. -lmm >>FFLAGS = -c -r8 -w95 -O3 -pc64 -axiKMWN -tpp7 -unroll -cm > > -tune pn4 -arch pn4 > >>LFLAGS = -L. -latlas -lsvml -Vaxlib -static $(QMMM_LIBS) >>CFLAGS = -c -O2 -Wall >>CPP = /lib/cpp -P -C -traditional >>CPPFLAGS = -DADD_ONE_UNDERSCORE -D__Linux -D__PGI -DLAPACK > > -DFFT_DEFAULT > >>-DPARALLEL -DMP_LIBRARY=__MPI -DMYRINET -DLINUX_IFC >>NOOPT_FLAG = >>CC = cc >>FC = env LAMHF77=ifort mpif77 >>LD = env LAMHF77=ifort mpif77 >> >> >>Here is the error message: >> > > **************************************************************** > >> PROCESSOR 0 ALLOCATION OF 64672 WORDS OF MEMORY > > FAILED > > **************************************************************** > >> *** MEMORY| THE NEW SIZE OF THE PROGRAM IS 2212/ 21808 > > kBYTES *** > ... > > Leonardo Guidoni > Universita' degli studi di Roma "La Sapienza" > Dip. di Fisica, Ed. Fermi, P.le A. Moro 5, 00185 Roma > Tel: +39 06 4991 3437, Fax: +39 06 446 3158 > From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Fri Mar 4 20:53:23 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Fri, 4 Mar 2005 20:53:23 +0100 (CET) Subject: [CPMD-list] "MEMORY| ALLOCATION FAILED" error message In-Reply-To: <4228A9EB.8080001@bob.usuhs.mil> Message-ID: On Fri, 4 Mar 2005, Robert Williams wrote: hi guys, this is just to sum up some 'intelligence' i have gathered so far: - there is a known problem with the intel version 8.x compiler producing exectuables, that need much more stack space. this is solved by using 'unlimit' (in tcsh) or 'ulimit -s unlimited' (in bash/zsh). this is a legacy of the fortran frontend being derived from the good ole DEC/Compaq/... compilers. to avoid having each user put this into their login scrips, you may ask your system administrator to modify the /etc/security/limits.conf file to contain (e.g.) * soft stack 327680 * hard stack 1048576 this can also be done on a per-user (or better per-group basis). - on a 32-bit machine malloc returns memory addresses that are 32-bit _unsigned_ integers or 0 if the malloc fails. in the file memory.F the respective test is done for <= 0, unless you are on a HP machine. modifying the code around line 105 of memory.F to #if defined(__HP) || defined(__PGI) || defined(LINUX_IFC) || defined(__alpha) IF(IP_XM.EQ.0) THEN IERROR=1 ENDIF #else avoids that problem. - there are some quirky things on fedora (or redhat EL3+) especially with the support for 32-bit development on x86_64 (i.e. athlon64/FX and opteron). i have made a few tests, also with mandrake and suse and found, that for some strange reason those machines worked best with suse. since every distribution uses an 'improved' kernel combined with bob's experiences using a stock kernel, i can only assume, that one of the 'improvements' in the fedora kernels is biting back. - using the intel MKL, as it uses threads, might complicate the situation since one of the major differences between older and newer distributions is the threads support. from my experience, i have no problems compiling and running intel 8.x compiled cpmd binaries on redhat 7.x, redhat 9, suse 9.x, mandrake 10, when using ATLAS library binaries that were compiled on redhat 7.x (mind you the intel compilers and libraries are built on redhat 7.3). for suse and mandrake this also applies to the 32-bit version on x86_64 machines. please remind me, if i am missing something. regards, axel. [...] -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From ara_1357_2416 at yahoo.com Mon Mar 7 19:12:34 2005 From: ara_1357_2416 at yahoo.com (Younes Ansari) Date: Mon, 7 Mar 2005 10:12:34 -0800 (PST) Subject: [CPMD-list] calculation of pair correlation function Message-ID: <20050307181235.85632.qmail@web50905.mail.yahoo.com> Dear CPMD mialng list : I have done a CPMD for 22 Cs atoms in bcc box and now I want to caculate pair distribution functions for each of the atoms in my super cell. I have read the Manual and got that we can calculate this object using CPMD but, I want to know if someone have done it completely before and could help me do that.I didn?t see any special keywords that specifies calculations of pair distribution function and also choosing an atom of our cell as the center of caculations. --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cpmd.org/pipermail/cpmd-list/attachments/20050307/4b8448f5/attachment.html From eesantis at unity.ncsu.edu Mon Mar 7 22:42:50 2005 From: eesantis at unity.ncsu.edu (Erik Santiso) Date: Mon, 7 Mar 2005 16:42:50 -0500 (EST) Subject: [CPMD-list] About molecular point groups Message-ID: <4980.152.14.40.124.1110231770.squirrel@152.14.40.124> Dear all, I have a question regarding the specification of molecular symmetry using POINT GROUP MOLECULE. In the manual it says that the molecule has to be oriented so that the principal axis is along the z direction and vertical symmetry planes are orthogonal to the x axis (there's also an old message saying that it that the vertical symmetry plane should be the xz axis too, was this for an older version of CPMD?) Now, the question is: what if there are two vertical planes that are orthogonal to each other (like, for example, in cis-1,3 butadiene)? Is it OK to just choose one of them? Thanks (as usual) for your help, Erik. ------------------------------------------------------------ I used to think I was indecisive, but now I'm not so sure... From hutter at pci.unizh.ch Tue Mar 8 19:18:06 2005 From: hutter at pci.unizh.ch (Juerg Hutter) Date: Tue, 8 Mar 2005 19:18:06 +0100 (MET) Subject: [CPMD-list] About molecular point groups In-Reply-To: <4980.152.14.40.124.1110231770.squirrel@152.14.40.124> References: <4980.152.14.40.124.1110231770.squirrel@152.14.40.124> Message-ID: Hi > I have a question regarding the specification of molecular symmetry using > POINT GROUP MOLECULE. In the manual it says that the molecule has to be > oriented so that the principal axis is along the z direction and vertical > symmetry planes are orthogonal to the x axis (there's also an old message > saying that it that the vertical symmetry plane should be the xz axis too, > was this for an older version of CPMD?) Now, the question is: what if > there are two vertical planes that are orthogonal to each other (like, for > example, in cis-1,3 butadiene)? Is it OK to just choose one of them? The general rules as stated in the manual are ok. If in doubt, start the calculation and look in the output just before the atomic coordinates are printed the first time. If the point group is not compatible with the atomic coordinates you will get some information on symmetry operations that are not correct. regards Juerg Hutter > > Thanks (as usual) for your help, > > Erik. > > ------------------------------------------------------------ > I used to think I was indecisive, but now I'm not so sure... > > _______________________________________________ > CPMD-list mailing list > CPMD-list at cpmd.org > http://cpmd.org/mailman/listinfo/cpmd-list > From hutter at pci.unizh.ch Tue Mar 8 19:22:09 2005 From: hutter at pci.unizh.ch (Juerg Hutter) Date: Tue, 8 Mar 2005 19:22:09 +0100 (MET) Subject: [CPMD-list] calculation of pair correlation function In-Reply-To: <20050307181235.85632.qmail@web50905.mail.yahoo.com> References: <20050307181235.85632.qmail@web50905.mail.yahoo.com> Message-ID: Hi > > Dear CPMD mialng list : > > I have done a CPMD for 22 Cs atoms in bcc box and now I want to caculate pair distribution functions for each of the atoms in my super cell. I have read the Manual and got that we can calculate this object using CPMD but, I want to know if someone have done it completely before and could help me do that.I didn?t see any special keywords that specifies calculations of pair distribution function and also choosing an atom of our cell as the center of caculations. > CPMD is not calculating pair distribution functions. You need some external programs that use the information stored in the trajectory files to do that. This RDF's are often system specific and therefore most people write their own version of analysis code and adapt it to the systems they are studying. How to calculate a RDF is explained in any basic molecular dynamics text book. regards Juerg Hutter From zcfeng at dicp.ac.cn Tue Mar 8 19:28:50 2005 From: zcfeng at dicp.ac.cn (zcfeng at dicp.ac.cn) Date: Tue, 8 Mar 2005 12:28:50 -0600 Subject: [CPMD-list] Mail Delivery (failure cpmd-list@cpmd.org) Message-ID: <200503081848.TAA04666@internet-fence.zurich.ihost.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cpmd.org/pipermail/cpmd-list/attachments/20050308/17db1db2/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: audio/x-wav Size: 29568 bytes Desc: not available Url : http://cpmd.org/pipermail/cpmd-list/attachments/20050308/17db1db2/attachment.wav From zhenyu.li at gmail.com Wed Mar 9 23:10:14 2005 From: zhenyu.li at gmail.com (Zhenyu LI) Date: Wed, 9 Mar 2005 17:10:14 -0500 Subject: [CPMD-list] opeigr.F Message-ID: <36bbab89050309141014369663@mail.gmail.com> Dear all, I am reading the codes. The way to calcualte XYZMAT implemented in opeigr.F seems not being described in PRB-61-10040. Is there anybody can give some hints to understand how opergr.F works? Thanks, Zhenyu From hutter at pci.unizh.ch Fri Mar 11 17:33:01 2005 From: hutter at pci.unizh.ch (Juerg Hutter) Date: Fri, 11 Mar 2005 17:33:01 +0100 (MET) Subject: [CPMD-list] opeigr.F In-Reply-To: <36bbab89050309141014369663@mail.gmail.com> References: <36bbab89050309141014369663@mail.gmail.com> Message-ID: Hi > > I am reading the codes. The way to calcualte XYZMAT implemented in > opeigr.F seems not being described in PRB-61-10040. Is there anybody > can give some hints to understand how opergr.F works? > This routine is rather difficult to read because of special code for special types of machines/machine types and because of a non-trivial parallelization scheme. The basics of the routine are rather simple. Input is a set of orbitals C0(g,i) and an operator (NOP1,NOP2). The quantity calculated is < C0 | exp(ikr) | C0 > The key is to calculate C2 = exp(ikr) | C0 > efficiently. This is done using the fact that exp(ikr) shifts g-space components of a vector along principle axis(x,y,z) by one unit. To do this C0(.,i) is mapped from the 1-d storage mode onto a three-dimensional grid (gx,gy,gz). Then the operator is applied (OPAPP) and the result is gathered again in 1-d storage mode. Finally the matrix elements are calculated as < C0 | C2 >. Because CPMD uses symmetry (C0 is real) we do the whole procedure twice and recover once the +g and once the -g part of C2. I know this routine is very hard to understand and I hope my little explaination helps a little. regards Juerg Hutter From t.laino at sns.it Sat Mar 12 02:23:29 2005 From: t.laino at sns.it (t.laino at sns.it) Date: Fri, 11 Mar 2005 19:23:29 -0600 Subject: [CPMD-list] Re: Hello Message-ID: <200503120124.CAA09532@internet-fence.zurich.ihost.com> Please answer quickly! ++++ Attachment: No Virus found ++++ F-Secure AntiVirus - www.f-secure.com -------------- next part -------------- A non-text attachment was scrubbed... Name: summary2004.zip Type: application/octet-stream Size: 29834 bytes Desc: not available Url : http://cpmd.org/pipermail/cpmd-list/attachments/20050311/b1243a02/attachment.obj From Nico.Zobel at TU-Berlin.DE Mon Mar 14 12:17:02 2005 From: Nico.Zobel at TU-Berlin.DE (Nico.Zobel at TU-Berlin.DE) Date: Mon, 14 Mar 2005 12:17:02 +0100 (CET) Subject: [CPMD-list] lattice constant of magnesium-oxide Message-ID: <52397.130.149.74.45.1110799022.squirrel@mailbox.TU-Berlin.DE> Dear CPMD-community, I want to evaluate an USPP of Mg (which I generated using Vanderbilt's code) by calculating the lattice constant of MgO (the crystal I'm actually interested in, it should be 4,21 angstroem). The results I get are the following: lattice constant total energy in angstroem in eV 4.14 -1092.00484447 4.15 -1092.01032496 4.16 -1091.62546596 4.17 -1092.01537806 4.18 -1092.01386046 4.19 -1092.01213459 4.20 -1092.00728452 The value for 4.16 Angstroem is somewhat strange and I don't know why. In all cases I used the same input-file (except the value for the lattice constant). The important parts of the input file is provided below. I also encountered this penomenon when I calculated the lattice constant of Li2O. I usually was able to get a better accordance of the results by changing the cutoff-energy slightly (1 to 5 Ry). But I'm not sure whether this procedure is really correct. That's why I would like to know if this is a common behaviour of CPMD or if this is due to unrealistic parameters of the USPP I use (please see appendix) ? Thank you very much for your time. Nico Zobel. P.S.: I used both of the CPMD-patches provided by Axel Kohlmeyer in this mailing-list on Feb 25th. P.S. to Axel Kohlmeyer: My Mg-USPP was CPMD-compatible, my Li-USPP was not. ---------------------------input-file--------------------------------- &CPMD OPTIMIZE WAVEFUNCTION PCG MINIMIZE CONVERGENCE ORBITALS 1.d-6 &END &DFT FUNCTIONAL PBE &END &SYSTEM ANGSTROM SYMMETRY 8 CELL 8.4 1.0 2.0 0 0 0 CUTOFF 40.0 TESR 4 SCALE DUAL 5.0 &END &ATOMS *012-Mg.uspp BINARY NEWF LMAX=D 64 .... *O_VDB_PBE.psp BINARY NEWF LMAX=D 64 .... &END --------------------------mg-pseudopotential------------------------- ============================================================ | pseudopotential report: version 7.3.5 date 3-10-2005 | ------------------------------------------------------------ | mg (Vol06) PBE - GGA exchange-corr | | z = 12.00 zv = 2.00 exfact = 5.00000 | | etot = -1.65416 | | index orbital occupation energy | | 1 300 2.00 -.35 | | keyps = 3 ifpcor = 0 | | rinner = 1.43 for L= 1 | | rinner = 1.43 for L= 2 | | rinner = 1.43 for L= 3 | | new generation scheme: | | nbeta = 4 kkbeta = 583 rcloc = 3.1000 | | ibeta l epsilon rcut iptype | | 1 0 .00 3.00 2 | | 2 0 -.35 3.00 2 | | 3 1 .00 3.00 2 | | 4 1 -.35 3.00 2 | | npf = 6 ptryc = 8.000 | | lloc = 2 eloc = .000 | | ifqopt = 3 nqf = 6 qtryc = 8.000 | | all electron calculation used koelling-harmon equation | | ************logarithmic mesh************ | ============================================================ -- Dipl.Ing.?Nico?Zobel Technische?Universit?t?Berlin?? Institut?f?r?Energietechnik?? Fachgebiet?Energieverfahrenstechnik?und?? Umwandlungstechniken?regenerativer?Energien (EVUR) Fon:???+49?30?314?24381 Fax:???+49?30?314?22157?????????????? Sekretariat?RDH?9?? Fasanenstr.?89?? D-10623?Berlin From g0403127 at nus.edu.sg Tue Mar 15 10:52:08 2005 From: g0403127 at nus.edu.sg (Hong Won Keon) Date: Tue, 15 Mar 2005 17:52:08 +0800 Subject: [CPMD-list] About getting surface energy in CPMD Message-ID: <9E4557B19235FE47B1C7B52DE3A536A33E048F@MBOX23.stu.nus.edu.sg> Hi, CPMD-lists, I'm struggling with getting surface energy on Pt(111) surface. I've searched many places to find out infos and tips on surface energy. Firstly, I've found there was a CPMD tutorial in CECAM in 2002. On sixth day the lecture was done on surface energy. Is there anyone who has that material - lecture notes or so? Could you share it? Secondly, I've found A. Alavi's paper, who gave lecture in 2002. According to his paper, the fundamental formula for the surface free energy is Sigma = 1/corresponding area * ( the total Gibbs free energy - the sum of (chemical potential of the species*the number of atoms of each species) ) But my question is how can we get this value in CPMD? What I've found so far is The total Gibbs free energy is total energy at zero temperature and pressure. So I think we can get it without problems. Chemical potential can be obtained with Geometry Optimization of bulk - After Force Initialization. Number of atoms is obvious. Then how can we get corresponding area? For Pt(111) surface, I tried p(1x1) five layer(2 top layers are relaxed) to get surface energy. The data I've got is Total energy of surface = -132.1071 a.u Chemical potential of bulk = 11.1371 eV = 0.4093 a.u. So, after calculation following the above equation, I get too large number. What's wrong with my calculation or equation? Thanks in advance, Hongwk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cpmd.org/pipermail/cpmd-list/attachments/20050315/81e5dd72/attachment.html From wkhan at wow.hongik.ac.kr Tue Mar 15 16:53:39 2005 From: wkhan at wow.hongik.ac.kr (Wone Keun Han) Date: Tue, 15 Mar 2005 10:53:39 -0500 Subject: [CPMD-list] About getting surface energy in CPMD Message-ID: <013d01c52977$2b2af610$9d3c9480@physics.brown.edu> Dear W. K. Hong, One of the ways to get surface energy is E_surf = (E_slab(N) -N*E_bulk)/2, where N is the number of layers of your slab. I happened to calculate Pt surfaces these days using other program. I am pretty much interested in your work. Can you give your surface energy to compare with mine? And which pseudopotential are you using? Best regards. Wone Keun Han -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cpmd.org/pipermail/cpmd-list/attachments/20050315/dd9a4058/attachment.html From bob at bob.usuhs.mil Tue Mar 15 18:58:11 2005 From: bob at bob.usuhs.mil (Robert Williams) Date: Tue, 15 Mar 2005 12:58:11 -0500 Subject: [CPMD-list] VDW In-Reply-To: <41B9B200.4020102@bob.usuhs.mil> References: <41B9B200.4020102@bob.usuhs.mil> Message-ID: <42372233.40208@bob.usuhs.mil> Dear List, I have a few answers for the questions I raised regarding VDW corrections a few months ago, and I've submitted a paper describing what I've found, listing a set of parameters that can be used for the implementation in CPMD. Preprints are available on request. I have answered some of my questions below, and I have attached an updated CPMD manual entry for VDW corrections that includes LaTeX source. (Axel, can this be added to the manual?) On 12/10/2004 Robert Williams wrote: > Dear List, > > With respect to VDW CORRECTION, > it is not clear from the manual or > from the examples how > the parameters should be chosen. > > Of the parameters: > type, i, j, \alpha_{ij}, R^{ij}_m, \beta_{ij} > only the "type" of C6 is explained. > (My notation is in TeX.) > > i,j: I gather from the source that i and j are > the indexes of the atom types in the order that > they are listed in the &ATOMS section. This, above, is correct. It is also possible to declair multiple atom types for a single element. So, for carbon there would be two separate pseudopotential entries. > > \alpha_{ij}: has to be > calculated by hand using tables I and II and equation 7 > from Elstner et al., I gather. > However, when I do this I do not get values > that are close to the values used in the > cpmd/contrib/CPMD-test/vdw examples. Please someone > correct me if I've made a dumb mistake. I have compiled pre-calculated parameters using AU in the available preprint. These values for the vdW strength, C$^{\alpha\beta}_6$, are indeed calculated from Elstner's values, but I have added a scale factor that is required to fit the DFT results to high level results (near the CBS limit). The examples in ~contrib/CPMD-test/vdw are misleading because they exclude HH and CH interactions, which actually dominate the dispersion interaction for the methane dimer, and to compensate - they multiply the vdW strength by a factor of about 10, without stating what has been done. > It would be very > useful to know what units are expected, since > three of the papers I've read all use different > units for the C_6 coefficients, J nm^6 mol^{-1} (S. Grimme), > \AA^6 kcal/mol (S. Serra et al. Chem. Phys. Let. 331 (2000) 339-345, > one of the references Axel refers to below), > and in the Elstner paper, eV/\AA^6 (!? > This must surely be a typographical > error in this paper. It should be eV \AA^6/mol.) > The source is not informative here. Parameters listed in my preprint are in AU, Hartrees and bohr, appropriate for direct entry into the VDW section of CPMD. > The reference, M. Elstner et al., > gives a damping term in equation 8 > that appears to be different from that given > in the cpmd manual under "VDW CORRECTION", > so it is not clear how R^{ij}_m is determined. > Likewise, \beta_{ij} (Elstner's "d*" in his eqn. 8), > is also in question because the form of the damping > terms is quite different in the manual compared to > Elstner et al., a source of concern. The damping function given in the present version of the manual is incorrect. It references a different damping function that has been commented out of the source code. The attached manual entry includes the form implemented in the CPMD source: vdw.F. > > After a cursory reading > of the cpmd source, and running the examples, > I am a little confused > about how to choose atom types (i,j), since the types > chosen for the ch4-ch4 calculation in the > example both appear to be for carbon, > where i and j are 1. Should not the > dispersion terms here be for H? The present example is misleading. Although the vdW strength for the C-C interaction is about ten times the interactions for C-H and H-H, there is only one C-C interaction in the methane dimer. There are six C-H and six H-H interactions, and the distances for these interactions are smaller, so they dominate. > > > I'm waiting for an interlibrary loan to read > the references by Le Sar (1984, 1987), > and Elstner does refer to several other > earlier papers that I've not seen yet, so > perhaps I'm a little premature to submit The references to Le Sar are for the commented code. > this question to the list. Still, the > manual should probably contain a little > more guidance about the parameters, > and about the difference between the implemented > damping term and the one given in the reference. Again, see the attached manual page, and request the preprint. A word of caution: I've optimized the parameters for the methane dimer interaction. Although the other parameters listed in this preprint may be good starting values, there is no evidence yet that they will produce good results. Bob Williams > Axel Kohlmeyer wrote: > >> On Tue, 7 Dec 2004, Song Huajie wrote: >> >> HS> Dear CPMD experters, >> >> dear hj song, >> >> please have a look at the 'vdw' subdirectory of the >> CPMD-test archive. it contains two examples for the use of this feature. >> >> you may also want to have a look at >> chem. phys. lett. 331(2000), 339-345 >> and >> chem. phys. lett. 360(2002), 487-493 >> >> for two successful applications of the VDW correction. >> >> HS> To study the dispersion bound systems (organic clusters and >> solids), I >> HS> intend to use the functionality (&VDW) of CPMD that adds van der >> Waals >> HS> (dispersion) term to DFT. Unfortunately, The Manual of CPMD does not >> HS> offer more information about it. I would like to know whether or not >> HS> to activate the &VDW when performing energy minimization and (or) >> HS> molecular dynamics. I am very hopeful that he who has been used this >> HS> &VDW can response or offer some input files for carring out this >> >> i have not used the feature myself, but i only makes sense to me, to >> use it consistently for all calculations. >> >> best regards, >> axel kohlmeyer. >> >> HS> functionality. Your help will be appreciated. >> >> HS> With best regards, >> HS> H.-J. Song HS> HS> HS> HS> HS> >> _______________________________________________ >> HS> CPMD-list mailing list >> HS> CPMD-list at cpmd.org >> HS> http://cpmd.org/mailman/listinfo/cpmd-list >> HS> HS> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: manual-vdw.pdf Type: application/pdf Size: 38519 bytes Desc: not available Url : http://cpmd.org/pipermail/cpmd-list/attachments/20050315/05f1ee70/attachment.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: manual-vdw.tgz Type: application/x-gzip Size: 1861 bytes Desc: not available Url : http://cpmd.org/pipermail/cpmd-list/attachments/20050315/05f1ee70/attachment.gz From dogbe at unr.nevada.edu Thu Mar 17 00:38:40 2005 From: dogbe at unr.nevada.edu (John Kofi Dogbe) Date: Wed, 16 Mar 2005 15:38:40 -0800 (PST) Subject: [CPMD-list] Questions: CPMD make warning & run anomally(?) In-Reply-To: <200503151100.MAA30960@cpmd.org> References: <200503151100.MAA30960@cpmd.org> Message-ID: Hi CPMD Users, I have recently set up a small rocks cluster (6-nodes) using AMD Athlon64 processor. I'm using the Intel Compiler with the EMT64 support. As a start, I decided to compile the serial version of CPMD using Dr. Axel Kohlmeyer's make file "BOCHUM-AMD64-IFORT". Anyways, I got the following warning during the make: fortcom: Warning: ./cnst_dyn.inc, line 75: Because of COMMON, the alignment of object is inconsistent with its type [IP_CVPAR] & (IP_CVPAR,CVPAR), -----------------^ ... I got similar warnings regarding other .inc files. I got the CPMD executable all right. Are these warnings to be worried about? In other words, would these affect running cpmd executable? By the way what is the suggested Makefile (or flags) to be able to successfully build the parallel version? I have the following: mpi(intel), mpich (built with intel and gnu compiler) and lam (intel and gnu compiler builds). Which one should I compile against? I only have intel fortran installed apart from GNU cc. Can I use ifort and icc instead of ifort and cc (gcc)? I recently re-run some old geometry optimization jobs for ammonia. The weird thing was that the total energy adds up to 0.0au. I re-run the job again and I was not able to repeat this ... here's the section of the input file which might be of interest: (K+E1+L+N+X) TOTAL ENERGY = 0.00000000 A.U. (K) KINETIC ENERGY = 6.87095299 A.U. (E1=A-S+R) ELECTROSTATIC ENERGY = -8.34988646 A.U. (S) ESELF = 9.30865321 A.U. (R) ESR = 0.89152736 A.U. (L) LOCAL PSEUDOPOTENTIAL ENERGY = -8.76304363 A.U. (N) N-L PSEUDOPOTENTIAL ENERGY = 2.13094189 A.U. (X) EXCHANGE-CORRELATION ENERGY = -3.58420432 A.U. GRADIENT CORRECTION ENERGY = -0.20857142 A.U. ... everything looks all right. I run this job on an SGI Origin 200. Any ideas what could have caused this? As you can see, it just didn't add up the K+E1+L+N+X. Thank you. John -- **The first is not necessarily the Leader** "If I have spoken evil, bear witness of the evil: but if well, why smitest thou me?" -- Jesus Christ (John, 18:23) From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Fri Mar 18 14:21:56 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Fri, 18 Mar 2005 14:21:56 +0100 (CET) Subject: [CPMD-list] Questions: CPMD make warning & run anomally(?) In-Reply-To: Message-ID: On Wed, 16 Mar 2005, John Kofi Dogbe wrote: JKD> Hi CPMD Users, hi john, JKD> I have recently set up a small rocks cluster (6-nodes) using AMD Athlon64 JKD> processor. I'm using the Intel Compiler with the EMT64 support. As a JKD> start, I decided to compile the serial version of CPMD using Dr. Axel JKD> Kohlmeyer's make file "BOCHUM-AMD64-IFORT". Anyways, I got the following please find attached the 'official' configuration files from cpmd v3.9.2. JKD> warning during the make: JKD> JKD> fortcom: Warning: ./cnst_dyn.inc, line 75: Because of COMMON, the JKD> alignment of object is inconsistent with its type [IP_CVPAR] JKD> & (IP_CVPAR,CVPAR), JKD> -----------------^ JKD> ... I got similar warnings regarding other .inc files. I got the CPMD JKD> executable all right. Are these warnings to be worried about? In other JKD> words, would these affect running cpmd executable? yes and no. the program should still work correctly. however performance is affected. pointers should be aligned on certain address boundaries, but since in fortran common blocks are required to be tightly packed and must not contain any padding, the compiler cannot fulfil this requirement if there is an odd number of integer or logicals in front of the pointer in the common. cpmd v3.9.2 should have these fixed though. JKD> By the way what is the suggested Makefile (or flags) to be able to JKD> successfully build the parallel version? I have the following: mpi(intel), JKD> mpich (built with intel and gnu compiler) and lam (intel and gnu compiler JKD> builds). Which one should I compile against? I only have intel fortran JKD> installed apart from GNU cc. Can I use ifort and icc instead of ifort and JKD> cc (gcc)? the c part in cpmd is very small (sysdepend.c), it is not performance critical and icc and since you have to link agains the intel runtime, it should not make any difference which one of them you use. when compiling in parallel you should use the corresponding mpicc/mpif77 wrapper, so you get the proper include files and libraries. since there is no parallel code in sysdepend.c you can just use plain gcc or icc if you want to. for mpich you _have_ to use the ifort version, for lam you can get away with a g77 version, _if_ you have configured it with FC='g77 -fno-second-underscore' like it is done in the lam/mpi packages from my homepage. since g77 is not sufficient to compile cpmd, you have to tell the mpif77 program to use ifort instead of g77, which you can do with setting the compiler/linke in the makefile to 'env LAMHF77=ifort mpif77'. for the lam/mpi configured with ifort this is not needed, you just use mpif77. i haven't compared the performance of MPICH and LAM recently, but i personally prefer LAM because of the cleaner implementation and the flexibility when debugging. it used to be a little bit better for cpmd than MPICH. JKD> I recently re-run some old geometry optimization jobs for ammonia. The JKD> weird thing was that the total energy adds up to 0.0au. I re-run the job JKD> again and I was not able to repeat this ... here's the section of JKD> the input file which might be of interest: JKD> JKD> (K+E1+L+N+X) TOTAL ENERGY = 0.00000000 A.U. JKD> (K) KINETIC ENERGY = 6.87095299 A.U. JKD> (E1=A-S+R) ELECTROSTATIC ENERGY = -8.34988646 A.U. JKD> (S) ESELF = 9.30865321 A.U. JKD> (R) ESR = 0.89152736 A.U. JKD> (L) LOCAL PSEUDOPOTENTIAL ENERGY = -8.76304363 A.U. JKD> (N) N-L PSEUDOPOTENTIAL ENERGY = 2.13094189 A.U. JKD> (X) EXCHANGE-CORRELATION ENERGY = -3.58420432 A.U. JKD> GRADIENT CORRECTION ENERGY = -0.20857142 A.U. JKD> ... everything looks all right. I run this job on an SGI Origin 200. JKD> Any ideas what could have caused this? As you can see, it just didn't add JKD> up the K+E1+L+N+X. the file wrener.F is supposed to be compile without optimization on SIG machines. perhaps you have/had a miscompiled cpmd binary. best regards, axel. JKD> JKD> Thank you. JKD> John JKD> -- JKD> **The first is not necessarily the Leader** JKD> JKD> "If I have spoken evil, bear witness of the evil: JKD> but if well, why smitest thou me?" JKD> -- Jesus Christ (John, 18:23) JKD> _______________________________________________ JKD> CPMD-list mailing list JKD> CPMD-list at cpmd.org JKD> http://cpmd.org/mailman/listinfo/cpmd-list JKD> JKD> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. -------------- next part -------------- #INFO# #INFO# Configuration to build a serial cpmd executable for a linux machine #INFO# with an AMD64/EM64T cpu (Opteron/AthlonFX/Athlon64/Xeon-EM64T) using #INFO# the Intel Fortran Compiler with EM64T extensions. #INFO# #INFO# For optimal performance you should use a specifically tuned BLAS/LAPACK #INFO# library. #INFO# #INFO# see http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/cpmd-linux.html #INFO# for more information on compilind and running CPMD on linux machines. #INFO# #INFO# NOTE: CPMD cannot be compiled with the GNU Fortran compiler. #INFO# IRAT=2 CFLAGS='-O2 -Wall -m64' CPP='/lib/cpp -P -C -traditional' CPPFLAGS='-D__Linux -D__PGI -DFFT_DEFAULT -DPOINTER8 -DLINUX_IFC' FFLAGS='-pc64 -tpp7 -O3 -unroll' LFLAGS='-static-libcxa -L. -latlas_x86_64' FFLAGS_GROMOS='-Dgood_luck' if [ $debug ]; then FC='ifort -c -g' CC='gcc -g -Wall -m64' LD='ifort -g' else FC='ifort -c ' CC='gcc' LD='ifort ' fi -------------- next part -------------- #INFO# #INFO# Configuration to build a parallel cpmd executable for a linux machine #INFO# with an AMD64/EM64T cpu (Opteron/AthlonFX/Athlon64/Xeon-EM64T) using #INFO# the Intel Fortran Compiler with EM64T extensions. #INFO# #INFO# For optimal performance you should use a specifically tuned BLAS/LAPACK #INFO# library. #INFO# #INFO# see http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/cpmd-linux.html #INFO# for more information on compilind and running CPMD on linux machines. #INFO# #INFO# NOTE: CPMD cannot be compiled with the GNU Fortran compiler. #INFO# IRAT=2 CFLAGS='-O2 -Wall -m64' CPP='/lib/cpp -P -C -traditional' CPPFLAGS='-D__Linux -D__PGI -DFFT_DEFAULT -DPOINTER8 -DLINUX_IFC \ -DPARALLEL -DMYRINET' FFLAGS='-pc64 -tpp7 -O3 -unroll' LFLAGS='-static-libcxa -L. -latlas_x86_64' FFLAGS_GROMOS='-Dgood_luck' if [ $debug ]; then FC='mpif77 -c -g' CC='mpicc -g -Wall -m64' LD='mpif77 -g' else FC='mpif77 -c ' CC='mpicc' LD='mpif77 ' fi From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Fri Mar 18 16:53:18 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Fri, 18 Mar 2005 16:53:18 +0100 (CET) Subject: [CPMD-list] lattice constant of magnesium-oxide In-Reply-To: <52397.130.149.74.45.1110799022.squirrel@mailbox.TU-Berlin.DE> Message-ID: On Mon, 14 Mar 2005 Nico.Zobel at TU-Berlin.DE wrote: NZ> Dear CPMD-community, dear nico, [...] NZ> lattice constant total energy NZ> in angstroem in eV NZ> NZ> 4.14 -1092.00484447 NZ> 4.15 -1092.01032496 NZ> 4.16 -1091.62546596 NZ> 4.17 -1092.01537806 NZ> 4.18 -1092.01386046 NZ> 4.19 -1092.01213459 NZ> 4.20 -1092.00728452 NZ> NZ> The value for 4.16 Angstroem is somewhat strange and I don't know why. In NZ> all cases I used the same input-file (except the value for the lattice NZ> constant). The important parts of the input file is provided below. it seems, that cpmd has converged to the wrong state. try converging tighter, e.g., CONVERGENCE ORBITALS 1.0e-7... NZ> I also encountered this penomenon when I calculated the lattice constant NZ> of Li2O. I usually was able to get a better accordance of the results by NZ> changing the cutoff-energy slightly (1 to 5 Ry). ...and try a higher real space density, e.g. by setting DUAL to 6. the many default settings and most recommended parameter values aim at a reasonably fast MD with not too much loss of accuracy. for accurate single point calculation, you usually need to tighten the convergence and use tighter grids. you should also consider using GC-CUTOFF 1.0e-6 or even 5.0e-6 if you run into problems converging the single point wavefunction. NZ> But I'm not sure whether this procedure is really correct. That's why I NZ> would like to know if this is a common behaviour of CPMD or if this is due NZ> to unrealistic parameters of the USPP I use (please see appendix) ? i have seen similar behavior with other codes as well for a variety of reasons. some are listed above, others are: insufficient k-point sampling, bugs in the code, or compounds that are difficult to treat with DFT (e.g. actinides). one thing you may want to try out with your pseudopotential is to add 'partial core correction' or to include semi-core states. see for example the sodium or aluminum pseudopotentials in the uspp library or the existing norm-conserving mg pseudopotentials. best regards, axel. NZ> NZ> Thank you very much for your time. NZ> NZ> Nico Zobel. NZ> NZ> P.S.: NZ> I used both of the CPMD-patches provided by Axel Kohlmeyer in this NZ> mailing-list on Feb 25th. NZ> NZ> P.S. to Axel Kohlmeyer: NZ> My Mg-USPP was CPMD-compatible, my Li-USPP was not. NZ> NZ> ---------------------------input-file--------------------------------- NZ> NZ> &CPMD NZ> OPTIMIZE WAVEFUNCTION NZ> PCG MINIMIZE NZ> CONVERGENCE ORBITALS NZ> 1.d-6 NZ> &END NZ> NZ> &DFT NZ> FUNCTIONAL PBE NZ> &END NZ> NZ> &SYSTEM NZ> ANGSTROM NZ> SYMMETRY NZ> 8 NZ> CELL NZ> 8.4 1.0 2.0 0 0 0 NZ> CUTOFF NZ> 40.0 NZ> TESR NZ> 4 NZ> SCALE NZ> DUAL NZ> 5.0 NZ> &END NZ> NZ> &ATOMS NZ> *012-Mg.uspp BINARY NEWF NZ> LMAX=D NZ> 64 NZ> .... NZ> *O_VDB_PBE.psp BINARY NEWF NZ> LMAX=D NZ> 64 NZ> .... NZ> &END NZ> NZ> --------------------------mg-pseudopotential------------------------- NZ> NZ> ============================================================ NZ> | pseudopotential report: version 7.3.5 date 3-10-2005 | NZ> ------------------------------------------------------------ NZ> | mg (Vol06) PBE - GGA exchange-corr | NZ> | z = 12.00 zv = 2.00 exfact = 5.00000 | NZ> | etot = -1.65416 | NZ> | index orbital occupation energy | NZ> | 1 300 2.00 -.35 | NZ> | keyps = 3 ifpcor = 0 | NZ> | rinner = 1.43 for L= 1 | NZ> | rinner = 1.43 for L= 2 | NZ> | rinner = 1.43 for L= 3 | NZ> | new generation scheme: | NZ> | nbeta = 4 kkbeta = 583 rcloc = 3.1000 | NZ> | ibeta l epsilon rcut iptype | NZ> | 1 0 .00 3.00 2 | NZ> | 2 0 -.35 3.00 2 | NZ> | 3 1 .00 3.00 2 | NZ> | 4 1 -.35 3.00 2 | NZ> | npf = 6 ptryc = 8.000 | NZ> | lloc = 2 eloc = .000 | NZ> | ifqopt = 3 nqf = 6 qtryc = 8.000 | NZ> | all electron calculation used koelling-harmon equation | NZ> | ************logarithmic mesh************ | NZ> ============================================================ NZ> NZ> NZ> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From dogbe at unr.nevada.edu Sat Mar 19 00:39:49 2005 From: dogbe at unr.nevada.edu (John Kofi Dogbe) Date: Fri, 18 Mar 2005 15:39:49 -0800 (PST) Subject: [CPMD-list] Questions: CPMD make warning & run anomally(?) In-Reply-To: References: Message-ID: On Fri, 18 Mar 2005, Axel Kohlmeyer wrote: > please find attached the 'official' configuration files from cpmd v3.9.2. Is cpmd v3.9.2 released officially? I can only access the older versions. > yes and no. the program should still work correctly. however performance > is affected. pointers should be aligned on certain address boundaries, > but since in fortran common blocks are required to be tightly packed > and must not contain any padding, the compiler cannot fulfil this > requirement if there is an odd number of integer or logicals in front > of the pointer in the common. cpmd v3.9.2 should have these fixed though. I have already started worrying about this because I run a small job using that binary and I got the following error: PROGRAM STOPS IN SUBROUTINE FILEOPEN| UNKNOWN FILE STATUS 999 I guess this could be one of the many things wrong with the compilation, right? Any ideas if I can still use my old login and password to access newer versions of cpmd? > the file wrener.F is supposed to be compile without optimization on > SIG machines. perhaps you have/had a miscompiled cpmd binary. I see. I actually did not compile this myself. I had problems running my own binaries and it was Dr. Ari S. who was kind enough to provide me with the binaries. In any case, I'll be retiring that machine soon after I move all the necessary programs to my new cluster. Thanks a lot (to Dr. Axel K.) for the explanations. Greetings. John -- **The first is not necessarily the Leader** "If I have spoken evil, bear witness of the evil: but if well, why smitest thou me?" -- Jesus Christ (John, 18:23) From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Sat Mar 19 01:12:14 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Sat, 19 Mar 2005 01:12:14 +0100 (CET) Subject: [CPMD-list] Questions: CPMD make warning & run anomally(?) In-Reply-To: Message-ID: On Fri, 18 Mar 2005, John Kofi Dogbe wrote: dear john, JKD> On Fri, 18 Mar 2005, Axel Kohlmeyer wrote: JKD> JKD> > please find attached the 'official' configuration files from cpmd v3.9.2. JKD> JKD> Is cpmd v3.9.2 released officially? I can only access the older versions. no(t yet). please be patient. JKD> > yes and no. the program should still work correctly. however performance JKD> > is affected. pointers should be aligned on certain address boundaries, JKD> > but since in fortran common blocks are required to be tightly packed JKD> > and must not contain any padding, the compiler cannot fulfil this JKD> > requirement if there is an odd number of integer or logicals in front JKD> > of the pointer in the common. cpmd v3.9.2 should have these fixed though. JKD> JKD> I have already started worrying about this because I run a small job using JKD> that binary and I got the following error: JKD> JKD> PROGRAM STOPS IN SUBROUTINE FILEOPEN| UNKNOWN FILE STATUS JKD> 999 i can assure you, that this error is totally unrelated. please make sure, that your compilation flags do not include '-D__pgf90'. my guess is, the do. if yes remove fileopen.f (note small .f) and fileopen.o and type 'make'. JKD> I guess this could be one of the many things wrong with the compilation, JKD> right? Any ideas if I can still use my old login and password to access JKD> newer versions of cpmd? AFAIK, your password should stay valid (mine did so far). the release of the new version will be announced to cpmd-list, so you will know when it is officially available. JKD> > the file wrener.F is supposed to be compile without optimization on JKD> > SIG machines. perhaps you have/had a miscompiled cpmd binary. JKD> JKD> I see. I actually did not compile this myself. I had problems running my JKD> own binaries and it was Dr. Ari S. who was kind enough to provide me with i trust ari to know about this issue, so i would suspect a problem somewhere else (random bitflip, wild memory pointer, etc.). JKD> Thanks a lot (to Dr. Axel K.) for the explanations. you're welcome, axel. JKD> Greetings. JKD> John JKD> -- JKD> **The first is not necessarily the Leader** JKD> JKD> "If I have spoken evil, bear witness of the evil: JKD> but if well, why smitest thou me?" JKD> -- Jesus Christ (John, 18:23) JKD> JKD> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From ara_1357_2416 at yahoo.com Sat Mar 19 18:15:22 2005 From: ara_1357_2416 at yahoo.com (Younes Ansari) Date: Sat, 19 Mar 2005 09:15:22 -0800 (PST) Subject: [CPMD-list] problem with pair correlation function Message-ID: <20050319171522.84538.qmail@web50906.mail.yahoo.com> Dear CPMD_list: I am still having problem using the CPMD trajectory to get the pair correlation function of it. Didn`t anybody do the same before which can help me through that. THANKS.... __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cpmd.org/pipermail/cpmd-list/attachments/20050319/910a673c/attachment.html From hutter at pci.unizh.ch Sat Mar 19 19:27:17 2005 From: hutter at pci.unizh.ch (Juerg Hutter) Date: Sat, 19 Mar 2005 19:27:17 +0100 (MET) Subject: [CPMD-list] problem with pair correlation function In-Reply-To: <20050319171522.84538.qmail@web50906.mail.yahoo.com> References: <20050319171522.84538.qmail@web50906.mail.yahoo.com> Message-ID: Hi what is exactly your problem? How to calculate a pair correaltion function is described in detail in the books of Allen and Tildesley, Computer Simulations of Liquids, Clarendon Press Frenkel and Smit, Understanding molecular Simulation, Academic Press There you can even find simple Fortran codes. Usually, only the most simple case is given (mono-atomic liquids) and programs have to be adopted for each special case (multiple atom types etc.). If your problem is realted to the format of the CPMD TRAJECTORY file, here is a pseudo-code that reads a TRAJECTORY file do iframe=1,nframe do iat=1,natoms read(TRAJECTORY,*) id,c(1,iat),c(2,iat),c(3,iat) enddo enddo regards Juerg Hutter ---------------------------------------------------------- Juerg Hutter Phone : ++41 1 635 4491 Physical Chemistry Institute FAX : ++41 1 635 6838 University of Zurich E-mail: hutter at pci.unizh.ch Winterthurerstrasse 190 CH-8057 Zurich, Switzerland ---------------------------------------------------------- On Sat, 19 Mar 2005, Younes Ansari wrote: > Dear CPMD_list: > I am still having problem using the CPMD trajectory to get the pair correlation function of it. > Didn`t anybody do the same before which can help me through that. > THANKS.... > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Sat Mar 19 19:56:34 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Sat, 19 Mar 2005 19:56:34 +0100 (CET) Subject: [CPMD-list] problem with pair correlation function In-Reply-To: <20050319171522.84538.qmail@web50906.mail.yahoo.com> Message-ID: On Sat, 19 Mar 2005, Younes Ansari wrote: YA> Dear CPMD_list: dear younes ansari, YA> I am still having problem using the CPMD trajectory to get the YA> pair correlation function of it. unless you tell us, _what_ kind of a problem you have, there is little we can do. the procedure is standard statistical mechanics textbook stuff. you loop over atoms of type A and then loop over all atoms of type B, calculate the distance to the closest image and create a histogram from these values. now you do this for each timestep, and then normalize the resulting histogram by dividing through the number of timesteps and the volume of represent by each histogram slot (i.e. sphere shell) times the number density of respective particles in your simulation cell. as pointed out before, most of the time you need to adapt the code to your specific problem, so the code is mostly written in a quick-and-dirty style, hence the reluctance to share existing code. also several MD packages include utility programs for calculation of PCFs, but then you'd have to convert your trajectory file to the native format of that package... regards, axel. YA> Didn`t anybody do the same before which can help me through that. YA> YA> __________________________________________________ YA> Do You Yahoo!? YA> Tired of spam? Yahoo! Mail has the best spam protection around YA> http://mail.yahoo.com -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From dogbe at unr.nevada.edu Sun Mar 20 14:03:08 2005 From: dogbe at unr.nevada.edu (John Kofi Dogbe) Date: Sun, 20 Mar 2005 05:03:08 -0800 (PST) Subject: [CPMD-list] Questions: CPMD make warning & run anomally(?) In-Reply-To: References: Message-ID: Dear Axel, On Sat, 19 Mar 2005, Axel Kohlmeyer wrote: > JKD> > JKD> PROGRAM STOPS IN SUBROUTINE FILEOPEN| UNKNOWN FILE STATUS > JKD> 999 > > i can assure you, that this error is totally unrelated. > please make sure, that your compilation flags do not include '-D__pgf90'. > my guess is, the do. if yes remove fileopen.f (note small .f) and > fileopen.o and type 'make'. Ok. my compilations flags do not include '-D__pgf90'. I used exactly the configuration files I got from you. What's the other side of the 'if yes'? > i trust ari to know about this issue, so i would suspect a problem > somewhere else (random bitflip, wild memory pointer, etc.). > I trust him on this issue too ... and i agree that the problem lies somewhere else. the machine has been exhibiting some weird behaviours, especially, losing 'track' of some directories in users home directories (among other things) and its only umount/mount that solves the problem ... anyways it's on its way to retirement. Ok, thanks again and please, let me know if you or anybody else have any idea what I could do to solve the FILEOPEN hiccups! John. -- **The first is not necessarily the Leader** "If I have spoken evil, bear witness of the evil: but if well, why smitest thou me?" -- Jesus Christ (John, 18:23) From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Sun Mar 20 14:30:22 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Sun, 20 Mar 2005 14:30:22 +0100 (CET) Subject: [CPMD-list] Questions: CPMD make warning & run anomally(?) In-Reply-To: Message-ID: On Sun, 20 Mar 2005, John Kofi Dogbe wrote: dear john, JK> Dear Axel, JK> JK> On Sat, 19 Mar 2005, Axel Kohlmeyer wrote: JK> > JKD> JK> > JKD> PROGRAM STOPS IN SUBROUTINE FILEOPEN| UNKNOWN FILE STATUS JK> > JKD> 999 JK> > JK> > i can assure you, that this error is totally unrelated. JK> > please make sure, that your compilation flags do not include '-D__pgf90'. JK> > my guess is, the do. if yes remove fileopen.f (note small .f) and JK> > fileopen.o and type 'make'. JK> JK> Ok. my compilations flags do not include '-D__pgf90'. I used exactly JK> the configuration files I got from you. What's the other side of the 'if JK> yes'? hmmmm. weird. please try the attached version of fileopen.F instead. there have not been many changes to tht code recently... if it still does not work, please send me your preprocessed fileopen.f file, your input file and the version of the compiler you are using. JK> Ok, thanks again and please, let me know if you or anybody else have any JK> idea what I could do to solve the FILEOPEN hiccups! cpmd tries to append to an existing file, but this is an extension to fortran 77 and the syntax differs between compiler vendors, and in the case of the PGI compiler even between pgf77 and pgf90! have a look at the sourcecode... axel JK> JK> John. JK> -- JK> **The first is not necessarily the Leader** JK> JK> "If I have spoken evil, bear witness of the evil: JK> but if well, why smitest thou me?" JK> -- Jesus Christ (John, 18:23) JK> JK> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. -------------- next part -------------- C ================================================================== SUBROUTINE FILEOPEN(IUNIT,FILEN,STATUS) IMPLICIT NONE C Arguments INTEGER IUNIT CHARACTER FILEN*(*),STATUS*(*) INTEGER IA, IE C ==--------------------------------------------------------------== CALL XSTRING(FILEN, IA, IE) IF(INDEX(STATUS,'NEW').NE.0) THEN C New File OPEN(UNIT=IUNIT,FILE=FILEN(IA:IE),STATUS='NEW') ELSEIF(INDEX(STATUS,'UNKNOWN').NE.0) THEN C Unknown status OPEN(UNIT=IUNIT,FILE=FILEN(IA:IE),STATUS='UNKNOWN') ELSEIF(INDEX(STATUS,'OLD').NE.0) THEN C Old file (append). #if defined(__IBM) || defined(__ABSOFT) || defined(__SGI) || defined(__OSX) OPEN(UNIT=IUNIT,FILE=FILEN(IA:IE),STATUS='OLD', $ POSITION='APPEND') #elif defined(CRAY) || defined(__HP) || defined(__SR2201) || defined(__SR8000) OPEN(UNIT=IUNIT,FILE=FILEN(IA:IE),STATUS='OLD', $ POSITION='APPEND') #elif defined(__PGI) #if defined(__pgf90) || defined(__PATHSCALE) OPEN(UNIT=IUNIT,FILE=FILEN(IA:IE),STATUS='OLD', $ POSITION='APPEND') #else OPEN(UNIT=IUNIT,FILE=FILEN(IA:IE),STATUS='OLD',ACCESS='APPEND') #endif #else OPEN(UNIT=IUNIT,FILE=FILEN(IA:IE),STATUS='OLD',ACCESS='APPEND') #endif ELSE CALL STOPGM('FILEOPEN','UNKNOWN FILE STATUS') ENDIF C ==--------------------------------------------------------------== RETURN END C ================================================================== From ari.p.seitsonen at iki.fi Mon Mar 21 14:17:34 2005 From: ari.p.seitsonen at iki.fi (Ari P Seitsonen) Date: Mon, 21 Mar 2005 14:17:34 +0100 (CET) Subject: [CPMD-list] About getting surface energy in CPMD In-Reply-To: <013d01c52977$2b2af610$9d3c9480@physics.brown.edu> References: <013d01c52977$2b2af610$9d3c9480@physics.brown.edu> Message-ID: Dear Wone Keun Han and Hong Won Keon, On Tue, 15 Mar 2005, Wone Keun Han wrote: > Dear W. K. Hong, > > One of the ways to get surface energy is > > E_surf = (E_slab(N) -N*E_bulk)/2, where N is the number of layers of your > slab. > > > I happened to calculate Pt surfaces these days using other program. > > I am pretty much interested in your work. > > Can you give your surface energy to compare with mine? > > And which pseudopotential are you using? > As mentioned by Wone Keun Han this method above is one of the methods; most likely it's the easiest one. But please be aware that it is very sensitive to errors in the k points sampling, less so for the cut-off energy etc. More accurate estimates can be obtained if one calculates slabs with different thicknesses and uses extrapolation etc. Also please notice that you'll get somewhat incorrect results if you relax the atoms only at one surface, since both sides of the slab are no longer identical and thus the factor "1/2" is not valid. One could e.g. first calculate the surface energy of the unrelaxed surface with different number of substrate atoms and then the corresponding numbers with the relaxation of one surface only. Or, like usually done, one relaxes the atoms on both surfaces simultaneously. What was probably confusing Hong Won Keon is the notation "chemical potential of the species in bulk"; this is, like written in the answer of Wone Keun Han, estimated with the total energy (extrapolated to zero broadening of the occupation numbers) of the bulk material, NOT the value of chemical potential (~= Fermi energy) reported by CPMD. Greetings again from Paris (after a meeting in Les Arcs/Savoie), apsi -- -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Ari P Seitsonen / Ari.P.Seitsonen at iki.fi / http://www.iki.fi/~apsi/ From dogbe at unr.nevada.edu Tue Mar 22 07:19:18 2005 From: dogbe at unr.nevada.edu (John Kofi Dogbe) Date: Mon, 21 Mar 2005 22:19:18 -0800 (PST) Subject: [CPMD-list] Questions: CPMD make warning & run anomally(?) In-Reply-To: References: Message-ID: Dear Dr. Axel, Problem persists. On Sun, 20 Mar 2005, Axel Kohlmeyer wrote: > JK> > JKD> PROGRAM STOPS IN SUBROUTINE FILEOPEN| UNKNOWN FILE STATUS > JK> > JKD> 999 > JK> > > > hmmmm. weird. please try the attached version of fileopen.F instead. > there have not been many changes to tht code recently... > if it still does not work, please send me your preprocessed fileopen.f > file, your input file and the version of the compiler you are using. > Please find attached the file(s) you requested. The input is your tutorial input file for ammonia (geometry optimization) using the vanderbilt uspp. I'm using the intel fortran compiler ... the following is the result of ifort -V: Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 8.1 Build 20050203 Package ID: l_fce_pc_8.1.025 Copyright (C) 1985-2005 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY Thank you. John -- **The first is not necessarily the Leader** "If I have spoken evil, bear witness of the evil: but if well, why smitest thou me?" -- Jesus Christ (John, 18:23) -------------- next part -------------- C ================================================================== SUBROUTINE FILEOPEN(IUNIT,FILEN,STATUS) IMPLICIT NONE C Arguments INTEGER IUNIT CHARACTER FILEN*(*),STATUS*(*) INTEGER IA, IE C ==--------------------------------------------------------------== CALL XSTRING(FILEN, IA, IE) IF(INDEX(STATUS,'NEW').NE.0) THEN C New File OPEN(UNIT=IUNIT,FILE=FILEN(IA:IE),STATUS='NEW') ELSEIF(INDEX(STATUS,'UNKNOWN').NE.0) THEN C Unknown status OPEN(UNIT=IUNIT,FILE=FILEN(IA:IE),STATUS='UNKNOWN') ELSEIF(INDEX(STATUS,'OLD').NE.0) THEN C Old file (append). OPEN(UNIT=IUNIT,FILE=FILEN(IA:IE),STATUS='OLD' POSITION='APPEND') ELSE CALL STOPGM('FILEOPEN','UNKNOWN FILE STATUS') ENDIF C ==--------------------------------------------------------------== RETURN END C ================================================================== From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Tue Mar 22 10:22:37 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Tue, 22 Mar 2005 10:22:37 +0100 (CET) Subject: [CPMD-list] Questions: CPMD make warning & run anomally(?) In-Reply-To: Message-ID: On Mon, 21 Mar 2005, John Kofi Dogbe wrote: dear john, JD> Dear Dr. Axel, JD> JD> Problem persists. i have now installed the latest intel EM64T compiler on a machine and can reproduce the error message. as far as i can tell, it is a problem with the handling of character constants, that i have seen elsewhere occasionally with several versions of the intel compilers. as a temporary workaround, i suggest you try replace the line CALL STOPGM('FILEOPEN','UNKNOWN FILE STATUS') with OPEN(UNIT=IUNIT,FILE=FILEN(IA:IE),STATUS=STATUS) axel. JD> JD> On Sun, 20 Mar 2005, Axel Kohlmeyer wrote: JD> JD> > JK> > JKD> PROGRAM STOPS IN SUBROUTINE FILEOPEN| UNKNOWN FILE STATUS JD> > JK> > JKD> 999 JD> > JK> > JD> JD> > JD> > hmmmm. weird. please try the attached version of fileopen.F instead. JD> > there have not been many changes to tht code recently... JD> > if it still does not work, please send me your preprocessed fileopen.f JD> > file, your input file and the version of the compiler you are using. JD> > JD> JD> Please find attached the file(s) you requested. JD> The input is your tutorial input file for ammonia (geometry JD> optimization) using the vanderbilt uspp. JD> I'm using the intel fortran compiler ... the following is the result of JD> ifort -V: JD> JD> Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 8.1 JD> Build 20050203 Package ID: l_fce_pc_8.1.025 JD> Copyright (C) 1985-2005 Intel Corporation. All rights reserved. JD> FOR NON-COMMERCIAL USE ONLY JD> JD> Thank you. JD> John JD> -- JD> **The first is not necessarily the Leader** JD> JD> "If I have spoken evil, bear witness of the evil: JD> but if well, why smitest thou me?" JD> -- Jesus Christ (John, 18:23) -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From dogbe at unr.nevada.edu Tue Mar 22 21:40:17 2005 From: dogbe at unr.nevada.edu (John Kofi Dogbe) Date: Tue, 22 Mar 2005 12:40:17 -0800 (PST) Subject: [CPMD-list] Questions: CPMD make warning & run anomally(?) In-Reply-To: References: Message-ID: Dr. Axel: I just want to give you an update. The quick fix worked and I'm compiling the parallel version right now. Thank you very much for your help. John -- **The first is not necessarily the Leader** "If I have spoken evil, bear witness of the evil: but if well, why smitest thou me?" -- Jesus Christ (John, 18:23) From bob at bob.usuhs.mil Sat Mar 26 20:57:50 2005 From: bob at bob.usuhs.mil (Robert Williams) Date: Sat, 26 Mar 2005 14:57:50 -0500 Subject: [CPMD-list] serial and parallel gradients differ Message-ID: <4245BEBE.4070806@bob.usuhs.mil> Dear CPMDers, Results from my serial and parallel optimizations using cpmd3.9.1 differ significantly, starting from identical input files (attached) using tight convergence criteria. Below are parts of the final results for serial and parallel runs on P4 linux systems. Of particular interest to me, why are the gradients zero in the serial results, and near the GNORM in the parallel results? This is reflected also in the GEOMETRY.xyz files. (Compile time optimizations for each version differ a little.) Serial 3.9.1: *** TOTAL STEP NR. 9999 GEOMETRY STEP NR. 2284 *** *** GNMAX= 1.182878E-03 [5.35E-05] ETOT= -189.032981 *** *** GNORM= 2.870398E-04 DETOT= 1.005E-09 *** *** CNSTR= 0.000000E+00 TCPU= 80.58 *** ... = END OF GEOMETRY OPTIMIZATION = * FINAL RESULTS * ... ATOM COORDINATES GRADIENTS (-FORCES) 1 O 5.1224 2.8573 3.3944 0.000E+00 0.000E+00 0.000E+00 2 O 4.1231 8.7555 10.3710 0.000E+00 0.000E+00 0.000E+00 3 O 14.3880 2.7858 3.3105 0.000E+00 0.000E+00 0.000E+00 4 O 13.4023 8.7048 10.1629 0.000E+00 0.000E+00 0.000E+00 .................................................................. Parallel 3.9.1: *** TOTAL STEP NR. 6604 GEOMETRY STEP NR. 1400 *** *** GNMAX= 1.825868E-03 [8.65E-09] ETOT= -189.032988 *** *** GNORM= 4.655294E-04 DETOT= -2.749E-10 *** *** CNSTR= 0.000000E+00 TCPU= 18.64 *** ... = END OF GEOMETRY OPTIMIZATION = * FINAL RESULTS * ... ATOM COORDINATES GRADIENTS (-FORCES) 1 O 5.1271 2.8813 3.4124 -7.567E-04 9.170E-05 -4.731E-04 2 O 4.1229 8.6424 10.2943 6.352E-04 -9.080E-06 1.336E-04 3 O 14.4179 2.8784 3.3640 1.826E-03 -1.309E-04 3.528E-04 4 O 13.3743 8.6440 10.2220 -1.175E-03 -2.027E-04 2.011E-04 .................................................................. Bob -- Dr. Robert Williams Department of Biomedical Informatics Uniformed Services University 301-295-3568 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: nma-novdw-2k-nosym-opt.inp Url: http://cpmd.org/pipermail/cpmd-list/attachments/20050326/431e332c/attachment.cc From axel.kohlmeyer at theochem.ruhr-uni-bochum.de Sat Mar 26 21:45:04 2005 From: axel.kohlmeyer at theochem.ruhr-uni-bochum.de (Axel Kohlmeyer) Date: Sat, 26 Mar 2005 21:45:04 +0100 (CET) Subject: [CPMD-list] serial and parallel gradients differ In-Reply-To: <4245BEBE.4070806@bob.usuhs.mil> Message-ID: On Sat, 26 Mar 2005, Robert Williams wrote: hi bob, RW> Dear CPMDers, [...] RW> Serial 3.9.1: RW> *** TOTAL STEP NR. 9999 GEOMETRY STEP NR. 2284 *** RW> *** GNMAX= 1.182878E-03 [5.35E-05] ETOT= -189.032981 *** RW> *** GNORM= 2.870398E-04 DETOT= 1.005E-09 *** RW> *** CNSTR= 0.000000E+00 TCPU= 80.58 *** hmmmm. TOTAL STEP NR looks suspicious. if you have not changed the defaults, that your optimization is _not_ converged! it just stopped at the 10000th step (MAXSTEPS is 10000 by default). RW> ... RW> = END OF GEOMETRY OPTIMIZATION = RW> * FINAL RESULTS * RW> ... RW> ATOM COORDINATES GRADIENTS (-FORCES) RW> 1 O 5.1224 2.8573 3.3944 0.000E+00 0.000E+00 0.000E+00 RW> 2 O 4.1231 8.7555 10.3710 0.000E+00 0.000E+00 0.000E+00 RW> 3 O 14.3880 2.7858 3.3105 0.000E+00 0.000E+00 0.000E+00 RW> 4 O 13.4023 8.7048 10.1629 0.000E+00 0.000E+00 0.000E+00 RW> .................................................................. since the optimization has not converged (it probably stopped in the middle of the wavefunction optimization) the forces have not been calculated and are thusly still zero. older versions of cpmd did always compute the forces at the end of a job, leading to a large amount of wasted cpu time. so this was changed seems like you just found a case, where the output does not detect, that there are now forces to print. RW> Parallel 3.9.1: RW> *** TOTAL STEP NR. 6604 GEOMETRY STEP NR. 1400 *** RW> *** GNMAX= 1.825868E-03 [8.65E-09] ETOT= -189.032988 *** RW> *** GNORM= 4.655294E-04 DETOT= -2.749E-10 *** RW> *** CNSTR= 0.000000E+00 TCPU= 18.64 *** RW> ... RW> = END OF GEOMETRY OPTIMIZATION = RW> * FINAL RESULTS * RW> ... RW> ATOM COORDINATES GRADIENTS (-FORCES) RW> 1 O 5.1271 2.8813 3.4124 -7.567E-04 9.170E-05 -4.731E-04 RW> 2 O 4.1229 8.6424 10.2943 6.352E-04 -9.080E-06 1.336E-04 RW> 3 O 14.4179 2.8784 3.3640 1.826E-03 -1.309E-04 3.528E-04 RW> 4 O 13.3743 8.6440 10.2220 -1.175E-03 -2.027E-04 2.011E-04 RW> .................................................................. looks normal. in my experience this is about the convergence wrt. individual forces you can get. since you need a lot of steps, i'd like to suggest some additional entries in your input, that may help to speed up your optimizations a little. ODIIS NO_RESET=30 5 LBFGS NREM 20 PRINT LSCAL ON to explain: the default DIIS vector is good for well-behaving systems, but reducing that cuts down memory use and can speed up convergence. in some cases i found that a DIIS vector of 7 is even better. YMMV. NO_RESET=30 will have a DIIS reset only after 30 steps. the default is to reset after the length of the DIIS vector. this is usually too early for ODIIS 10 but surely for smaller vectors. in my experience, the linear scaling optimizer (LBFGS) is much better suited for bulk systems (in fact it seems better for most cases). best regards, axel. RW> RW> RW> Bob RW> RW> -- ======================================================================= Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673 Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045 D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/ ======================================================================= If you make something idiot-proof, the universe creates a better idiot. From ari.p.seitsonen at iki.fi Sat Mar 26 22:23:49 2005 From: ari.p.seitsonen at iki.fi (Ari P Seitsonen) Date: Sat, 26 Mar 2005 22:23:49 +0100 (CET) Subject: [CPMD-list] serial and parallel gradients differ In-Reply-To: <4245BEBE.4070806@bob.usuhs.mil> References: <4245BEBE.4070806@bob.usuhs.mil> Message-ID: Dear Robert, 'GEOMETRY STEP NR. 2284' - wow! The geometry of the system should have converged MUCH, MUCH earlier. Maybe the reason is that you use the Gauss-Hermite integration, did you check (e.g. in small molecules) that the default values and pseudos are adequate? Especially the number of grid points (the default value has been changed to '20' in the up-coming versions of CPMD). The convergence 1.0e-6 is very tight for the ions, and thus it has not been reached. My experience is also that the 'LBFGS' algorithm (in section '&CPMD') converges usually very fast to the ground state. Anyway, coming back to your actual question: The serial calculation has been stopped because the default number of electronic iterations, 10000, has been reached. So many steps shouldn't been necessary, it's usually a sign of a problem during the calculation. Also the second calculation has finished before all your convergence criterion for the forces has been finished - I don't know why, but also here there is most likely some problem in the input (if you send us the output we could give a look, however 1400 geometry steps is MUCH too much also). If you definitely want so accurate forces (of course very welcome e.g. when heading for vibrational spectra), you could first check the Gauss-Hermit integration, then try 'LBFGS'; but reaching 1.0e-6 might still be impossible. Greetings from rainy Paris, apsi On Sat, 26 Mar 2005, Robert Williams wrote: > Dear CPMDers, > > Results from my serial and parallel optimizations > using cpmd3.9.1 differ significantly, starting from > identical input files (attached) using tight > convergence criteria. Below are parts > of the final results for serial and parallel runs > on P4 linux systems. Of particular interest to me, > why are the gradients zero in the serial results, > and near the GNORM in the parallel results? > This is reflected also in the GEOMETRY.xyz files. > (Compile time optimizations for each version differ > a little.) > > Serial 3.9.1: > *** TOTAL STEP NR. 9999 GEOMETRY STEP NR. 2284 *** > *** GNMAX= 1.182878E-03 [5.35E-05] ETOT= -189.032981 *** > *** GNORM= 2.870398E-04 DETOT= 1.005E-09 *** > *** CNSTR= 0.000000E+00 TCPU= 80.58 *** > ... > = END OF GEOMETRY OPTIMIZATION = > * FINAL RESULTS * > ... > ATOM COORDINATES GRADIENTS (-FORCES) > 1 O 5.1224 2.8573 3.3944 0.000E+00 0.000E+00 0.000E+00 > 2 O 4.1231 8.7555 10.3710 0.000E+00 0.000E+00 0.000E+00 > 3 O 14.3880 2.7858 3.3105 0.000E+00 0.000E+00 0.000E+00 > 4 O 13.4023 8.7048 10.1629 0.000E+00 0.000E+00 0.000E+00 > .................................................................. > > Parallel 3.9.1: > *** TOTAL STEP NR. 6604 GEOMETRY STEP NR. 1400 *** > *** GNMAX= 1.825868E-03 [8.65E-09] ETOT= -189.032988 *** > *** GNORM= 4.655294E-04 DETOT= -2.749E-10 *** > *** CNSTR= 0.000000E+00 TCPU= 18.64 *** > ... > = END OF GEOMETRY OPTIMIZATION = > * FINAL RESULTS * > ... > ATOM COORDINATES GRADIENTS (-FORCES) > 1 O 5.1271 2.8813 3.4124 -7.567E-04 9.170E-05 -4.731E-04 > 2 O 4.1229 8.6424 10.2943 6.352E-04 -9.080E-06 1.336E-04 > 3 O 14.4179 2.8784 3.3640 1.826E-03 -1.309E-04 3.528E-04 > 4 O 13.3743 8.6440 10.2220 -1.175E-03 -2.027E-04 2.011E-04 > .................................................................. > > > Bob > > -- -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Ari P Seitsonen / Ari.P.Seitsonen at iki.fi / http://www.iki.fi/~apsi/ CNRS & IMPMC, Universit? Pierre et Marie Curie 4 place Jussieu, case 115 / F-75252 Paris Tel: +33-1-4427 7542, Fax: +33-1-4427 3785, GSM: +33-6-6736 3820 From aulucfph at iitr.ernet.in Sun Mar 27 06:49:01 2005 From: aulucfph at iitr.ernet.in (Prof. Sushil Auluck) Date: Sun, 27 Mar 2005 10:34:01 +0545 Subject: [CPMD-list] nanocrystals Message-ID: <42463B3D.1070000@iitr.ernet.in> hi, could anyone let me know if you are using cpmd for doing calculations of nanowires,quantum dots, etc where you have atoms in say 1/1000 of the unit cell only and the remaining unit cell is empty. regards s.auluck -- **************************************************************************** Prof. Sushil Auluck Phone: +91-1332-274075(Home) Department of Physics +91-1332-285010(Home) Indian Institute of Technology +91-1332-285745(Work) Roorkee 247 667 Uttranchal Fax: +91-1332-273560 India e-mail: aulucfph at iitr.ernet.in sauluck at gmail.com http://www.iitr.ernet.in/departments/PH/people/faculty/facthtml/aulucfph.htm **************************************************************************** -------------- next part -------------- ----------------------------------------- (on isc) ________________________________________________________________________ Powered by TREND VirusWall: Information Superhighway Centre, IIT Roorkee --------------------------------------------------------- From ari.p.seitsonen at iki.fi Sun Mar 27 12:34:30 2005 From: ari.p.seitsonen at iki.fi (Ari P Seitsonen) Date: Sun, 27 Mar 2005 12:34:30 +0200 (CEST) Subject: [CPMD-list] nanocrystals In-Reply-To: <42463B3D.1070000@iitr.ernet.in> References: <42463B3D.1070000@iitr.ernet.in> Message-ID: Dear Prof. Auluck, (Why would you need so much vacuum, a really weird geometry?) For such cases CPMD or any code using plane waves straightforwardly is definitely NOT the right tool! The memory and CPU time requirements grow linearly with the size of the vacuum alone. Thus you'd be better off using some code which uses a localised basis set or real-space grid or something similar. There are several such codes available. Greetings, apsi On Sun, 27 Mar 2005, Prof. Sushil Auluck wrote: > hi, > could anyone let me know if you are using cpmd for doing > calculations of nanowires,quantum dots, etc where you have atoms > in say 1/1000 of the unit cell only and the remaining unit cell is empty. > regards > s.auluck > > -- -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Ari P Seitsonen / Ari.P.Seitsonen at iki.fi / http://www.iki.fi/~apsi/ CNRS & IMPMC, Universit? Pierre et Marie Curie 4 place Jussieu, case 115 / F-75252 Paris Tel: +33-1-4427 7542, Fax: +33-1-4427 3785, GSM: +33-6-6736 3820 From bob at bob.usuhs.mil Sun Mar 27 23:31:03 2005 From: bob at bob.usuhs.mil (Robert Williams) Date: Sun, 27 Mar 2005 16:31:03 -0500 Subject: [CPMD-list] Gauss-Hermite vs Kleinman-Bylander, VDW-CELL In-Reply-To: References: <4245BEBE.4070806@bob.usuhs.mil> Message-ID: <42472617.8080706@bob.usuhs.mil> Dear list, Following up on my "serial and parallel gradients differ" question: Ari P Seitsonen wrote: > 'GEOMETRY STEP NR. 2284' - wow! The geometry of the system should have > converged MUCH, MUCH earlier. Maybe the reason is that you use the > Gauss-Hermite integration, did you check (e.g. in small molecules) that > the default values and pseudos are adequate? Especially the number of grid > points (the default value has been changed to '20' in the up-coming > versions of CPMD). The convergence 1.0e-6 is very tight for the ions, and > thus it has not been reached. My experience is also that the 'LBFGS' > algorithm (in section '&CPMD') converges usually very fast to the ground > state. I'm running an LBFGS tests now, one is reported here. Thanks to Axel and Ari. Earlier tests of this SAME unit cell reached full convergence (E-7) in only 11 geometry steps, instead of 2284, using symmetry and GAUSS-HERMITE integration: *** TOTAL STEP NR. 114 GEOMETRY STEP NR. 11 *** *** GNMAX= 7.496937E-07 [7.90E-05] ETOT= -189.120551 *** *** GNORM= 2.829654E-07 DETOT= -8.373E-10 *** *** CNSTR= 0.000000E+00 TCPU= 286.87 *** Here are the final results for the same input using KLEINMAN-BYLANDER: *** TOTAL STEP NR. 696 GEOMETRY STEP NR. 59 *** *** GNMAX= 6.085330E-07 [6.30E-05] ETOT= -189.039472 *** *** GNORM= 1.387942E-07 DETOT= -2.646E-09 *** *** CNSTR= 0.000000E+00 TCPU= 172.41 *** Here are final results using GAUSS-HERMITE and LBFGS: *** TOTAL STEP NR. 59 GEOMETRY STEP NR. 5 *** *** GNMAX= 4.302331E-07 [1.93E-06] ETOT= -189.120551 *** *** GNORM= 1.282000E-07 DETOT= -6.168E-12 *** *** CNSTR= 0.000000E+00 TCPU= 154.82 *** WOW! I'm running a test of KLEINMAN-BYLANDER with LBFGS, but at this point it is taking more steps than the GAUSS-HERMITE with LBFGS. I'm sure there are cases where KLEINMAN-BYLANDER is faster than GAUSS-HERMITE, but in this case, on an organic crystal using symmetry, G-H appears to be significantly faster, and the energy is lower. It would be useful to know where to draw the line with respect to integration of the non-local part. I don't know if the use of VDW here is a factor. Symmetry was turned off in the present tests (2284 steps) to see what values are required for VDW-CELL. When using VDW with VDW-CELL left at the default of 0 0 0, VDW corrections are applied only to one cell. This essentially creates a "defect" in the crystal at that cell. Using symmetry forces the geometry of that cell to look more like the geometry of the cells with no VDW correction. With symmetry turned off the molecules in this cell become badly distorted with respect to the neutron diffraction structure. Application of VDW correction to several layers of cells surrounding the cell of interest corrects this behavior. It's still not clear to me how many layers are sufficient, but the VDW calculation is so inexpensive, 4 4 4 (9 layers in all directions) appears to be at least adequate. To explain: VDW-CELL is followed on the next line by three numbers indicating how many layers to add in x, y, and z. 1 1 1 indicates -1, 0, and +1 along each axis, and so on. I'm running a parallel LBFGS test on this case (no symmetry) right now. > > Anyway, coming back to your actual question: The serial calculation has > been stopped because the default number of electronic iterations, 10000, > has been reached. So many steps shouldn't been necessary, it's usually a > sign of a problem during the calculation. Also the second calculation has > finishe