Tcod August 2014

tcod@lists.crystallography.net

3 participants
3 discussions

Re: [TCOD] Tcod Digest, Vol 7, Issue 3
by Daniel Chateigner 25 Aug '14

25 Aug '14

Yes OQMD looks interesting, and should absolutely be linked in TCOD for the benefit of both daniel Le 09/08/2014 14:00, tcod-request(a)lists.crystallography.net a écrit : > Send Tcod mailing list submissions to > tcod(a)lists.crystallography.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod > or, via email, send a message with subject or body 'help' to > tcod-request(a)lists.crystallography.net > > You can reach the person managing the list at > tcod-owner(a)lists.crystallography.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Tcod digest..." > > > Today's Topics: > > 1. The OQMD (Saulius Gra?ulis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 09 Aug 2014 07:30:47 -0400 > From: Saulius Gra?ulis <grazulis(a)ibt.lt> > To: tcod(a)lists.crystallography.net > Subject: [TCOD] The OQMD > Message-ID: <53E60667.7040301(a)ibt.lt> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi, folks, > > a day ago I have listened to the talk about the OQMD database: > > http://oqmd.org/ > > Well, actually, Stefaan mentioned it in his excellent review e-mail > (2013-09-06 12:02) on this list, but that time there was apparently no > public access to the DB. Now there is :). > > The DB is very mature and is completely open -- so good to look at and > tp collaborate with. I got in touch with Chris Wolverton, and we will > discuss over the e-mail how to get the TCOD and OQMD cooperating nicely > (unfortunately, Chris had to leave the conference early, so we could not > speak in person). > > The TCOD's role in this situation could be to present computations in a > standardized, CIF format from various groups. In this sense TCOD could > be a useful complement for the computation-first databases, and would > provide means to search and analyze computation results made by various > groups and researchers (which is the primary TCOD intent). In any case, > the OCMD data should be represented and referenced to in TCOD as well, > what do you think? > > Have a look, and stay tuned -- and your thoughts are welcome. > > Regards, > Saulius > -- ---------------------------------------------------------------------- Daniel Chateigner Professeur, Université de Caen Basse-Normandie http://www.ecole.ensicaen.fr/~chateign/danielc/ ---------------------------------------------------------------------- Editor: "Combined Analysis", Wiley-ISTE: http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1848211988.html Workshops on Combined Analysis: http://www.ecole.ensicaen.fr/~chateign/formation/ Advisory Board: Zeitschrift für Kristallographie ---------------------------------------------------------------------- Address: CRISMAT-ENSICAEN and IUT-Caen, Université de Caen Basse-Normandie, campus 2 6, Bd. M. Juin 14050 Caen, France tel: 33 (0)2 31 45 26 11 fax: 33 (0)2 31 95 16 00 daniel.chateigner(a)ensicaen.fr ---------------------------------------------------------------------- Open Databases: Full-Profile Search-Match: http://cod.iutcaen.unicaen.fr/ Material Properties Open Database (MPOD): http://www.materialproperties.org/ Crystallography Open Database (COD): http://sdpd.univ-lemans.fr/cod/ Theoretical (TCOD): http://sdpd.univ-lemans.fr/cod/tcod/ Predicted (PCOD): http://sdpd.univ-lemans.fr/cod/pcod/ ----------------------------------------------------------------------

1 0

The OQMD
by Saulius Gražulis 09 Aug '14

09 Aug '14

Hi, folks, a day ago I have listened to the talk about the OQMD database: http://oqmd.org/ Well, actually, Stefaan mentioned it in his excellent review e-mail (2013-09-06 12:02) on this list, but that time there was apparently no public access to the DB. Now there is :). The DB is very mature and is completely open -- so good to look at and tp collaborate with. I got in touch with Chris Wolverton, and we will discuss over the e-mail how to get the TCOD and OQMD cooperating nicely (unfortunately, Chris had to leave the conference early, so we could not speak in person). The TCOD's role in this situation could be to present computations in a standardized, CIF format from various groups. In this sense TCOD could be a useful complement for the computation-first databases, and would provide means to search and analyze computation results made by various groups and researchers (which is the primary TCOD intent). In any case, the OCMD data should be represented and referenced to in TCOD as well, what do you think? Have a look, and stay tuned -- and your thoughts are welcome. Regards, Saulius -- Saulius Gražulis Biotechnologijos institutas Graičiūno 8 02241 Vilnius-28 Lietuva Tel.: vidaus BTI: 226 Vilniaus BTI: (8-5)-260-25-56 mobilus TELE2: (8-684)-49-802 mobilus OMNIT: (8-614)-36-366

1 0

Re: [TCOD] TCOD dictionaries and data presentation -- 3 levels of description
by Björkman Torbjörn 05 Aug '14

05 Aug '14

Dear all, Running to keep up with the discussions here... Anyway, I have started to further develop vasp2cif to also extract all the relevant DFT parameters from VASP output and Saulius is going on something similar for abinit. This made some problems apparent. Stefaan Cottenier: > Specifying the XC-functional limits us to DFT only. Perhaps the keyword > should rather be 'level-of-theory'. If a LIBXC-identifier is given, then > this implies it is DFT with the quoted functional. If the value is not a > LIBXC-identifier, it refers to a non-DFT method (Hartree-Fock, GW, > QMC,...) It might be tricky to create a relevant list of non-DFT > methods, and right now it is perhaps of limited use, but the number of > predictions by these methods is likely going to surge in coming years. I think that one puts the _tcod_model to 'DFT' here to signal that it is DFT. I like the idea of using LibXC identifiers, that way we can help the only standard naming scheme slowly solidifying. The problem with LibXC is that they only name what they have implemented, and this covers only a small portion of all the possible methods (although a very large portion indeed of the methods actually used...) For example, one of my favourite classes of methods right now, non-local correlation van der Waals functionals, are not included in LibXC and thus has no naming scheme. For that reason, I would prefer to leave the functional as a "free" string, but try to primarily use the LibXC names whenever possible. I also realize that we may need tags for (semi-)empirical dispersion force parameters, particularly the Grimme scheme which is very popular. I guess that those would be introduced on a form similar to the U and J parameters now, something like: data_dft_atom_type_grimme_C6 data_dft_atom_type_grimme_radius Concerning the number of dimensions we allow.... as someone currently working with low-dimensional crystals (2D to be precise), I am reluctant to throw these out. They are perfectly fine crystallographic objects, I think, at least I seem to spend any amount of time looking at their electron diffraction patterns... From a technical standpoint they cause not real problems, you just give the size of the simulation box. I remember putting in tags to mark up whether periodic boundary conditions were used, since there are codes that can cut these along one direction, but these still typically use a finite size simulation box (as Stefaan says, there are exceptions, but not many). The CIF format of course also requires this box size to be expressed as a lattice vector, but this is not really a problematic point, this just reflects what people mostly do anyway. Cheers, Torbjörn --- Torbjörn Björkman, PhD COMP, Aalto University School of Science Espoo, Finland

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Tcod August 2014