* Now talking on #gpaw
* Topic for #gpaw is: GPAW | https://wiki.fysik.dtu.dk/gpaw | https://wiki.fysik.dtu.dk/ase | https://trac.fysik.dtu.dk/projects/gpaw | Paste code on http://paste.pocoo.org/ | Paste math on http://mathbin.net/
* Topic for #gpaw set by askhl at Tue Aug 18 17:07:02 2009
* [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
-NickServ- This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>.
* junyan (3283e8ad@gateway/web/freenode/ip.50.131.232.173) has joined #gpaw
* marcin_dulak (~dulak@jordan.fysik.dtu.dk) has joined #gpaw
<junyan> hi
<jensj> Hello
<askhl_> hola
<Falco1> hi
<junyan> should we start ?
<jensj> Let's start ...
<junyan> is there anything on the agenda ?
<jensj> Anyboby has something they would like to discus?
<junyan> i have :)
<junyan> i would like to ask how is it going with the exx test ?
<askhl_> The ASE debian package has finally been submitted to the debian people, in case anyone is interested
<jensj> Maybe you have seen hybridg.py?
<junyan> yes,
<junyan> my tests show the exx atomization energies are quite ok, but the lattice constants are too large !
<jensj> This is a simplified version of hybridk.py that works for PW mode only
<junyan> does it give the same result as hybridk ?
* kelu (82e157ed@gateway/web/freenode/ip.130.225.87.237) has joined #gpaw
<jensj> That's what I'm about to test ...
<jensj> What systems do you get too large lattice constants for?
<junyan> MgO
<marcin_dulak> i would like to have a copy of the debian files, so i can based on them
<junyan> its the same paper you compared the atomization energies
<junyan> its 0.03 A larger ...
<jensj> 0.03 Å out of how much?
<junyan> 4.212
<junyan> maybe you won't think its much difference , but EXX+RPA+0.03 A make the lattice parameter worse than PBE ...
<jensj> Hmm, that's not a lot too large.  How about the PBE value?
<junyan> 4.269 (PBE)
<jensj> Is that also too large?
<junyan> yes, vasp is 4.259 ..
<jensj> I can try to see what I get with hybridg.py
<junyan> ok, thats great !
* kelu has quit (Quit: Page closed)
<junyan> now i have another question
<junyan> how is it the LDA+U in gpaw ?
<junyan> i saw an earlier version that there is hubbard_U parameter
<junyan> but it doesn't exist any more in the latest version
<junyan> it is replaced by calc.hamiltonian.setup[a].set_hubbard ...
<junyan> why is that ?
<jensj> Ask on the mailing list?
<junyan> this latest calc.hamiltonian.setup thing can't work unless you first run a self consistent calculation without U , otherwise hamiltonian is None ...
<junyan> ok, i will ask on the mailing list, but have you seen anybody reporting anything about this LDA+U on the mailing list ?
<jensj> Did you look at the Hubbard_U_Zn.py test?
<junyan> yes, it first do calc.get_potential_energy without U, then set U and do again ..
<jensj> I think you should ask the LDA+U guys to write some documentation
<junyan> who are LDA+U guys ?
<lopeza> Hi all, I would like to ask if there will be a similar irc meeting for ASE?
<marcin_dulak> i remember Jon Steinar reporting similar problems with LDA+U
<junyan> ok good to know
<jensj> I think it's Jess Stausholm - he reads the gpaw-users ML
<marcin_dulak> https://listserv.fysik.dtu.dk/pipermail/gpaw-users/2012-January/001234.html
<jensj> lopeza: No, but we can talk about ASE here also
<lopeza> OK, I would like to know if there is currently development on the lammps interface
<junyan> Marcin: thanks for the link. so there is a reason ...
<jensj> Good question.  I don't think ther are any lammps people here. Try asking on the ase.dev ML
<jensj> ase-devolopers ML
<lauri_lehtovaara> has someone done some excited state optimizations?
<lopeza> yes, ok. I also wanted to know a little bit about QM/MM implementation status?
<jensj> There was a question about that on the gpaw ML, but I didn't see an answer from Elvar.  If you ask again, I can try to make him answer ...
<lopeza> :) sounds good, I will try
<jensj> junyan: Do you know why the ralda_energy_H2.py test fails?
<junyan> yes...
<junyan> i will fix that after I discussed with thomas what he needs
<jensj> Great!
<jensj> askhl_: Could you tell us moere about the debian package?
<jensj> askhl_: hola!
<askhl_> hi
<askhl_> Well, so the debian package will be roughly like the one we already know from Ubuntu but with a few changes
<askhl_> A while ago I cleaned up the scripts a bit (removing the .py extensions and providing --help options)
<jensj> Will it go into some repository?
<askhl_> this allows one to run help2man on them, thus obtaining man pages.  And that should be enough, I think, that the debian people will accept the package
<askhl_> then it will get into either the debian science or python section
<askhl_> (it will be under the debian science project overall)
<jensj> Nice!
<askhl_> First it will go unto unstable.  Then, if it works correctly, it will go to testing
<askhl_> Then finally it should go into stable.  Note that the Ubuntu repositories, along with those of several other linux distributions, are based on the unstable branch
<askhl_> so it might not take all that long for them to appear in Ubuntu if all goes well
<askhl_> But they were submitted yesterday so I don't know how long it will take yet
<askhl_> (perhaps some things have to be changed)
<askhl_> Basically I would like to create a similar package for GPAW
<askhl_> But GPAW is more complicated due to gpaw-python
<askhl_> I.e. GPAW will always depend explicitly on a version of Python at compile-time, and thus the package cannot conceivably support more than one Python version.
<jensj> That would be nice.  How about a ase-dev package that contains extra stuff needed for building the sphinx documentation?
<askhl_> (...except for serial runs)
<askhl_> We can add ase-dev and ase-doc binary packackes within the same source package
<askhl_> right now there's a python-ase source package with a single binary package with the same name
<askhl_> Once the debian stuff is sorted out I will probably make the usual ubuntu packages for ASE 3.6.0
<askhl_> based on the more recently changes to the debian package
<askhl_> recent*
<askhl_> (I thought I would mention this because the 3.6.0 packages as well as the 12.04 packages are running quite late as of now)
<jensj> Let me know If you need someone to test your packages.
<askhl_> Thanks, maybe I should send test requests to the gpaw-developers list
<marcin_dulak> i would suggest that the tests are also run during the build - i do that to RPMS and debs
<askhl_> (or ase-developers, respectively)
<askhl_> I guess the ase tests can be run during build without taking too much time
<askhl_> But the GPAW tests will definitely be too expensive
<marcin_dulak> i do that for gpaw too
* hugstr has quit (Quit: Leaving.)
<marcin_dulak> some programs take hours to compile, so gpaw can run it's tests
<askhl_> However most of the errors that can be introduced during packaging is stuff like missing or broken dependencies.  That should be quite quick to test, having a minimal test of each piece of functionality
<marcin_dulak> we could maybe limit the GPAW tests to short ones
* lopeza has quit (Quit: Page closed)
<askhl_> marcin_dulak: I think the debian maintainers will decide whether or not gpaw can run its tests
<jensj> Anything else we need to talk about?
<marcin_dulak> yes, but i still to have to maintain our versions - the distribution ones will be always outdated
<askhl_> But also, since I'm usually the one submitting the GPAW packages to Launchpad, and since this involves a fair amount of waiting in any case, I would be disinclined to include more than ~30 seconds of testing
<askhl_> By the way: gpaw-setups is probably too large that the debian people like it.  (Yes, there are larger packages but the size usually isn't due to fixed binary data)
<askhl_> So we might need a semiautomatic download facility for the setups
<jensj> Sounds OK
<askhl_> Something like "gpaw-download-setups" which will then download and unpack the setups in a certain place, preferably without superuser privileges.
<marcin_dulak> i would press the debian people - setups are necessary for GPAW to run
<askhl_> Then it should be made such that it will work without any modifications of GPAW_SETUP_PATH in .bashrc
<askhl_> marcin_dulak: I agree in this case that it would be really nice to actually have the setups
<askhl_> So I'll see what I can do
<askhl_> By the way, if space is an issue, perhaps we should think of how compressible the setups are.  E.g. how fine grids do we actually need?
<marcin_dulak> i'm afraid the setups from the generator2.py are even larger
<jensj> Yes!
<askhl_> There's also the slippery slope that more setups are likely to be added as we go along
<askhl_> Perhaps we can make a "stripped" setup?
<junyan> i would think that its  better to keep the GPAW_SETUP_PATH
<Falco1> I gotta go, see you
<askhl_> Vi ses, Falco1
<junyan> otherwise, people won't be able to read old gpw files
* Falco1 (~falh@planck.fysik.dtu.dk) has left #gpaw
<askhl_> junyan: the files will easily become incompatible in the sense that a recalculation would yield a different energy.  But the idiotproof=True allows one to read a gpw file without having the original setups
<junyan> great to know that idiotproof can work in this way !
<askhl_> Anyway, if we have to write the semiautomatic download tool, where should the setups be stored?
<jensj> junyan: How about GLLBSC for VO instead of LDA+U?
<junyan> I haven't tried...
<jensj> How about ~/.gpaw/setups?
<askhl_> ~/gpaw-setups messes with the user's directory structure.  ~/usr/share/gpaw-setups might be a bit less messy.  ~/.gpaw/setups is very "clean" but hides large files which is itself not so nice
<junyan> i need actually only reliable structure, then EXX+RPA
<junyan> so GLLBSC won't be a candidate for structure relaxation
<junyan> jensj, I have another question
<junyan> I found that pw total energy is around 0.2 eV larger than the fd mode, given the same system
<askhl_> Of course we could run "gpaw-install-setups --destination ~/mysetups" and it would make a little change in ~/.gpawrc
<askhl_> according to the user's preference
<junyan> it results in EXX also around 0.2 eV larger in the pw mode
<askhl_> But that's a bit "black box"'y
* hugstr (~Adium@dhcp2-pc113031.fy.chalmers.se) has joined #gpaw
<askhl_> I guess we can choose ~/.gpaw/setups
<askhl_> if it becomes necessary
<jensj> junyan: that's bad!  Can you show me this?
<junyan> 6 fd -59.3456378866 6 pw -58.8632364725 10 fd -59.3582144574 10 pw -58.8757997971
<junyan> for Li4O8
<junyan> 6 means kpt 6,6,6
<jensj> Is it magnetic?
<junyan> yes
<junyan> no, this is not
<junyan> i have with spin results , wait
<jensj> askhl_: could the .deb installer download the setups?
<jensj> or is that not allowed?
<junyan> no, i don't have both pw and fd results for with spin ..
<junyan> this is MgO result : 8 fd 6.85501985432 8 pw 6.98805849085 12 fd 6.63715518813 12 pw 6.77922715361
<jensj> Are these calculations converged?
<junyan> yes ..
<jensj> with respect to ecut and h for pw and fd?
<junyan> pw 600, h 0.18
<jensj> Try eigensolver='cg'
<junyan> ... ? change eigensolver will change total energy ???
<jensj> 600 eV and 0.18 Å is not converged for oxygen - is it?
<junyan> for energy difference its ok
<marcin_dulak> if it's the total energy then maybe 0.18 is not enough
<askhl_> jensj: hmmmm
<askhl_> jensj: I guess we can make an install trigger or something
<askhl_> jensj: I don't know what is allowed and what isn't, but it seems quite reasonable
<jensj> The rmm-diis solver can get lost if the initial guess is not good enough
<jensj> So basis='dzp' might help too
<marcin_dulak> ask: i will first try to puterabytsh setups into their usual /usr/share/gpaw-setups. we have terabyte disks now!
<junyan> i use basis=dzp always
<marcin_dulak> or maybe split setups into gpaw-setups-pbe, etc
<junyan> but i think , my point is, if fd and pw mode gives similar gpts, why their energies should differ so much ?
<marcin_dulak> sometimes tricky systems converge to different electronic states
<junyan> maybe 0.18 A and 600 eV is not converged, but they usually give very similar number of grid points
<marcin_dulak> is your system spin-polarised, tricky?
<junyan> no, i tested MgO, Li8O8
<junyan> they are not spin-polarized
<junyan> this is Li8O8 : 8 fd -78.3948124455 8 pw -77.9625103446
<junyan> and it looks a systematic difference with increasing kpts
<jensj> Got to run.  See you!
<junyan> i leave as well then
* fabiolima (c881ca82@gateway/web/freenode/ip.200.129.202.130) has joined #gpaw
<marcin_dulak> bye
* marcin_dulak (~dulak@jordan.fysik.dtu.dk) has left #gpaw
* lauri_lehtovaara has quit (Quit: lauri_lehtovaara)