[TCOD] What structures do we accept to TCOD?

Björkman Torbjörn torbjorn.bjorkman at aalto.fi
Thu Jul 31 10:06:37 UTC 2014


Hi Saulius,

>> that would simultaneously store all the relevant data and be the
>> simplest for the uploader. But then that is probably some time
>> away... (although I have some work in progress for VASP)
>
>Very valuable! If you could share your code with the TCOD, this would be
>a great contribution.

It is a program called vasp2cif originally by Peter Larsson (now at NSC in Linköping, Sweden) and then extended by me. One version is available at https://github.com/egplar/vasp2cif although I know that I have done things to it later that have not yet ended up there (mostly due to lack of time on my part to learn to use git). So far it only extracts the geometry, not the "clever" stuff, like convergence parameters, because the last time I had time to do something with this the DFT dictionary was still in a fairly volatile state... but it is simple for me to do. I can quickly (="a day of work or so") make a version that takes an OUTCAR (main output file of VASP) and produces a CIF file with all that we are interested in. This can be expected to be ready rather soon (="when I have managed to clear some time for this" \approx "within a month"). 

Cheers,
Torbjörn

---
Torbjörn Björkman, PhD
COMP, Aalto University School of Science
Espoo, Finland


________________________________________
Från: tcod-bounces at lists.crystallography.net [tcod-bounces at lists.crystallography.net] för Saulius Gražulis [grazulis at ibt.lt]
Skickat: den 31 juli 2014 12:31
Till: tcod at lists.crystallography.net
Ämne: Re: [TCOD] What structures do we accept to TCOD?

Hi, Torbjörn,

On 2014-07-31 11:33, Björkman Torbjörn wrote:
>> The entire instruction file is something which in Saulius' scheme
>> is at
>>> level 2. It is definitely the ideal situation if every entry
>>> would have all information up to level 2. But while for some
>>> codes that will be straightforward (one input file and go), for
>>> others it would require many input files and a sequence of
>>> commands (with varying options) to go from the initial structure
>>> to the optimized one in a reproducible way (and as codes evolve,
>>> the input might quickly get incompatible). Strictly requiring
>>> that all this information is present, would scare away many
>>> entries that would nevertheless have been useful.

> I think I need a clarification here. The question of levels is
> completely apart from the CIF dictionary, right?

Yes, indeed. The levels are TCOD specific agreements. They are not
encoded in CID dictionaries but will rather be encoded in deposition
software.

E.g. if we agree that for published structures level 0 is OK, then the
checker will accept structures without the _dft_total_energy data item,
but will insist on _journal_... or _journal_paper_doi being present.

On the other hand, for personal communications, or for large-scale
computation projects that might wish to contribute, we may not have DOI
but will then insist to have residual forces and total energy (level 1
description). And so on.

> Inclusion of the full input file is definitely a good idea, if
> possible, but I don't think that this should be enforced at the
> submission stage.

Sure. This would be a level 2 (full description) and is nice to have,
but I am realistic that many people may not want or will not care to
provide this information.

> Actually, the best solution is of course to code up an interface that
> just sucks all the data straight from uploaded input/output files

I'm right now working on this.

> that would simultaneously store all the relevant data and be the
> simplest for the uploader. But then that is probably some time
> away... (although I have some work in progress for VASP)

Very valuable! If you could share your code with the TCOD, this would be
a great contribution.

>>> Items that have been suggested so far for level 0 are:
>>>> *cif of the final structure
>>>> *publication reference
>>>> *level of theory (XC within DFT, or name of method if not DFT)
>>>> *full optimization or only positions

> I think this is a pretty good list.

Me to. Thanks for the list. This is a very valuable input and permits me
to start formalising the TCOD requirements at the dictionary and cif
checker software levels.

Sincerely,
Saulius

--
Dr. Saulius Gražulis
Vilnius University Institute of Biotechnology, Graiciuno 8
LT-02241 Vilnius, Lietuva (Lithuania)
fax: (+370-5)-2602116 / phone (office): (+370-5)-2602556
mobile: (+370-684)-49802, (+370-614)-36366

_______________________________________________
Tcod mailing list
Tcod at lists.crystallography.net
http://lists.crystallography.net/cgi-bin/mailman/listinfo/tcod



More information about the Tcod mailing list