Samtale med #gpaw
(16:30:57) jjmo: Hello everyone!
(16:31:00) askhl: Hello
(16:31:09) marcin_dulak: Hello
(16:31:30) jjmo: Should we do a quick presentation of who is who and from where?
(16:31:34) alexander_held [~aheld@remote239-098.home.uni-freiburg.de] trådte ind i rummet.
(16:32:07) jussie [~chatzilla@a88-115-208-134.elisa-laajakaista.fi] trådte ind i rummet.
(16:32:37) jjmo: I'm Jens Jørgen Mortensen from CAMd, Denmark
(16:32:46) askhl: Ask Hjorth Larsen, CAMd, Denmark
(16:32:57) marcin_dulak: Marcin Dulak, also from CAMd
(16:33:01) jussie: Jussi Enkovaara, CSC, Finland
(16:33:11) chlg: Christian Glinsvad, also from CAMd
(16:33:12) alexander_held: Alexander Held, FMF Freiburg, Germany
(16:33:49) jjmo: Does anyone have something they would like to discuss?
(16:34:12) jjmo: I know askhl want's to talk about a new release of GPAW
(16:35:22) askhl: Would the beginning of January be a good time?
(16:35:48) jjmo: I'm not here before the end of January
(16:36:09) jussie: Are there some specific things in the code that should be fixed before the release
(16:36:20) lauri_lehtovaara [~lauri@17.156.97.84.rev.sfr.net] trådte ind i rummet.
(16:36:30) jjmo: I don't think so
(16:36:38) chlg: Is the PW code stable?
(16:36:50) askhl: I would like to improve the performance of force calculations before; but I have very little non-vacation left, so it's going slowly :)
(16:37:15) chlg: LCAO forces specifically, right?
(16:37:18) askhl: yes
(16:37:53) jjmo: We don't have to worry about the PW code - if we just keep it a secret :)
(16:38:17) jjmo: askhl: do you have a deadline?
(16:38:37) jjmo: I could work on a release tomorrow.
(16:38:37) askhl: I'll be at CAMD until the end of January
(16:38:47) askhl: That's a bit early for me :)
(16:39:18) askhl: But I guess I can attempt to finish it this week
(16:39:33) Falco1 [~falh@planck.fysik.dtu.dk] trådte ind i rummet.
(16:39:37) jjmo: Should we aim for end of January?
(16:39:48) askhl: That is okay by me
(16:40:08) jjmo: How about ASE. Anything to worry about there?
(16:40:19) chlg: Me too... greater chance of us being ready to merge the Ehrenfest branch back to trunk by then
(16:40:20) askhl: Which features have been added since last release?
(16:40:30) marcin_dulak: usually we release ASE first. David is finishing too, and there will be a CMR course sometime in January, so ASE could be released after that
(16:40:56) askhl: If there's a CMR course in January, would it not be better to release ASE before?
(16:40:57) chlg: askhl: I added a feature in the ASE GUI (ag)
(16:41:16) chlg: other than that, none that I have notice
(16:41:17) askhl: chlg: oh yeah, the velocity colouring
(16:41:24) jjmo: GPAW has a new "gpaw" command line tool
(16:41:31) marcin_dulak: the purpose of the course is to add some working CMR examples to ASE tests
(16:41:59) askhl: marcin_dulak: Okay, then it makes sense to release after
(16:42:46) jussie: I think HDF5 support has been stabilized since last release
(16:42:50) askhl: So everyone should finish as many features as possible by the end of January. :)
(16:43:02) jjmo: Good plan!
(16:43:47) jjmo: chlg: Did you write about your new ag feature on the ASE webpage?
(16:43:54) jjmo: https://wiki.fysik.dtu.dk/ase/development/releasenotes.html#releasenotes
(16:44:27) chlg: jjmo: No I was unaware that we had a trunk entry
(16:44:47) jjmo: I encourage everyone to add to our release notes whenever you do some work on ASE or GPAW - also small stuff
(16:46:48) askhl: In any case, I guess everyone has said what they wanted about release at the end of January
(16:47:17) askhl: It'll be a bit difficult to get stresses implemented by then, though
(16:47:26) jjmo: Did anyone read my email about prameters for a plane-wave calculation
(16:48:00) alexander_held: yes, but I did not think about it yet :-)
(16:48:17) jjmo: askhl: Yes - that will not happen
(16:49:00) jjmo: jussie: Have you had time to work on your branches?
(16:49:14) askhl: jjmo: oh right. I think the PW(ecut=250) is a good way to do things. That's the way things have been going recently. E.g. replacing stencils keyword with PoissonSolver(nn=..) and so on
(16:49:52) jjmo: But how do we set the parameters for interpolation of the density?
(16:50:02) chlg: jjmo: dictionaries! cutoffs={'density': 200, 'h2': 0.1} etc.
(16:50:34) jjmo: That's a possiblity
(16:52:15) chlg: maybe we need another layer of abstraction for the way we do poisson/laplace
(16:52:45) chlg: so it could either emcompass the 'stencils' keyword or the PW stuff
(16:53:30) jjmo: Yes, stencils=(3,3) is not nice
(16:54:36) alexander_held: I subclassed from PoissonSolver to implement the poisson equation with dielectrics. Is this common, or should one try to keep one class with lots of parameters to specify the behaviour?
(16:55:24) lauri_lehtovaara forlod rummet (quit: Quit: lauri_lehtovaara).
(16:55:27) chlg: I prefer subclassing personally
(16:55:51) lauri_lehtovaara [~lauri@17.156.97.84.rev.sfr.net] trådte ind i rummet.
(16:55:57) chlg: but I don't feel like in the majority with that opinion
(16:56:20) askhl: alexander_held: Subclassing sounds fine. The only issue is that sometimes if someone wants to use many things in combination, it can be nontrivial to do if there are some conflicts with different subclasses.
(16:56:33) alexander_held: true
(16:56:48) chlg: e.g. the dreaded diamond inheritance structure with new style classes in Python
(16:57:25) jjmo: Should one look at the DipoleCorrectionPoissonSolver for an example?
(16:57:48) askhl: The Dipole-... solver is a separate class precisely to avoid clashes if someone wants to subclass PoissonSolver
(16:58:31) jjmo: Yes, so that could be an alternative ...
(16:58:45) askhl: But it depends on how "intermingled" the subclass is with its superclass
(16:59:00) chlg: technically DipoleCorrectionPoissonSolver isn'tusing inheritance here, just aggregation
(16:59:04) chlg: https://trac.fysik.dtu.dk/projects/gpaw/browser/trunk/gpaw/dipole_correction.py
(16:59:26) askhl: Te dipole correction is an entirely independent step, so there is nothing to gain by making it a subclass (except less typing)
(16:59:32) askhl: s/Te/The/
(17:00:15) chlg: yeah I agree; just prefer inheritance when it means less copy/paste of code
(17:00:21) askhl: Yes, there's one "implementing class" (which contains the complicated stuff), and one "interface class" (which is the one users would care about)
(17:01:52) olopeza [50dfd4f0@gateway/web/freenode/ip.80.223.212.240] trådte ind i rummet.
(17:02:03) askhl: If there's a better way to specify the dipole correction, then we can always consider doing that. I wanted a "minimum-interference" way for the first implementation
(17:03:47) jjmo: That reminds me: There is still some work to be done for the dipole correction - see warning here: https://wiki.fysik.dtu.dk/gpaw/tutorials/dipole_correction/dipole.html
(17:04:35) jjmo: Anything else we should talk about?
(17:05:30) jjmo: Who wants to write a summary to the mailing lists?
(17:05:30) chlg: askhl: how much trouble do you think there is in extending the dipole correction to support non-orthorhombic unit cells?
(17:05:42) askhl: Yeah, also it uses more memory than necessary. :)
(17:05:58) askhl: chlg: not very much; just get cell_cv and h_cv right I think
(17:06:11) chlg: ok sounds good
(17:06:38) chlg: so it's basically just GUC and restarting that's keeping us from calling the dipole correction 'stable'?
(17:07:32) askhl: I think so. Perhaps we should allocate less data at a time or so; it's written to be somewhat logical right now, instead of efficient
(17:07:34) chlg: in the long term, it might be an idea to print/raise a warning if the dipole moment becomes large but you're not using the correction
(17:08:04) marcin_dulak: jussie: Jussie do you think calculating isolated atoms with fleur is possible?
(17:08:04) askhl: alexander_held: did you figure out about subclassing the Poisson solver?
(17:08:24) marcin_dulak: Jussi
(17:08:56) alexander_held: askhl: figure out, if it works, or if it is a good idea?
(17:08:58) jussie: In principle it is possible, but I do not think it is very efficient or easy
(17:09:13) askhl: alexander_held: figure out what you wanted, I mean :)
(17:09:23) marcin_dulak: i think i may need atoms, or at least small molecules
(17:11:32) marcin_dulak: do you have any working example or know anybody has one?
(17:11:58) jussie: I have not used FLEUR much for isolated systems, but in principle one needs only large enough unit cell. It is just that converging the calculation might be difficult
(17:13:03) jjmo: marcin_dulak: Can't you use NWChem?
(17:14:19) alexander_held: askhl: we are basically replacing the c operator _gpaw.Operator by a custom one (which could be merged back into _gpaw.Operator in the future), but use the rest of the PoissonSolver as is
(17:15:15) marcin_dulak: jjmo: one program is not enough. moreover i would like to try metals clusters despite problems with occupations and there are not basis sets for heavy elements (4d, 5d)
(17:16:18) jussie forlod rummet (quit: Ping timeout: 240 seconds).
(17:16:38) olopeza forlod rummet (quit: Quit: Page closed).
(17:16:46) jjmo: alexander_held: I would go with inheritance
(17:17:08) alexander_held: ok
(17:18:14) lauri_lehtovaara forlod rummet (quit: Quit: lauri_lehtovaara).
(17:21:38) askhl: I guess we don't have anymore to discuss at this time
(17:21:44) hugstr forlod rummet (quit: Quit: Leaving.).
(17:21:45) askhl: Should we declare that the meeting is over?
(17:21:59) alexander_held: I don't have anything to add
(17:22:09) askhl: jjmo says that's okay (and he is in my office right now)
(17:23:27) jun forlod rummet.
(17:24:13) jussie [~chatzilla@a88-115-208-134.elisa-laajakaista.fi] trådte ind i rummet.
(17:27:57) alexander_held: will the next meeting take place in four weeks?
(17:33:49) alexander_held forlod rummet.