Wien2k detection issues

This is a bug report, I would send patches, but I think this does not concern the parser, which is the only part I’m somewhat familiar with and ATM I don’t feel like digging deeper.

So looking at the 1614 Wien2k calculations in database, there are some duplicates and a lot of misdetected cases.

This is an example case misdetected as Wien2k:

Just quick explanation about the Wien2k data structure:
In general the most informative output of Wien2k is the .scf file, however Wien2k is a collection of subprograms glued together by some C shell scripts, and every program produces its own output .scfx (.scf0, .scf1, .scf2, .scfc, scfm) which are than compiled together to provide the .scf file. The individual .scfx files from the run of subprograms from the last scf iteration still stay in the directory though, so in theory the identical info as from the .scf file (at least for the last scf iteration) can be obtained there. In general there could be multiple Wien2k calculation in the same directory, but they must have different names (CASE1.scf, CASE2.scf, etc…, so in general all files CASE1.xxx belong to same calculation)

I’m not sure how the checking works ATM, but it probably looks for something like .scf files?
Therefore the first issue is that currently when one uploads case which has .scf and .scf0 files, it is detected as two calculations. So the easy fix would be to really just match *.scf files. This should fix also the misdetections of the .scfoutlog files as Wien2k (in the link above). In general it should still be possible to use the info from the .scfx files when the .scf file is missing (use them as a “backup” main file?). So maybe another improvement could be that when the CASE.scf file is not detected, there would be also a backup list of .scf0, scf1, scf2, etc, to use as a mainfile.

Thanks for the explanations about wien2k. You are absolutely right, we have to adapt the matching of wien2k files and restrict to *.scf files. We could also match and parser .scfx files as a backup. We do something similar with VASP. Here we usually consume the vasp.run.xml and only if this is missing, we look for the OUTCAR file.

We use this issue to track the progress.