search

zerothi / sisl

Electronic structure Python package for post analysis and large scale tight-binding DFT/NEGF calculations
https://zerothi.github.io/sisl
Mozilla Public License 2.0
180 stars 58 forks source link

High-level writing and parsing fdf configs for siesta/ts/tbtrans #170

Open jonaslb opened 4 years ago

jonaslb commented 4 years ago

I think it would be nice, if it was possible, to for example say fdf.electrodes["Left"].atoms or fdf.electrodes["Left"].chem_pot.contour to obtain the atom indices of the electrode and its chemical potential's associated contour (perhaps using #122), respectively. Similarly, fdf.siesta_kgrid (or fdf.ts_kgrid/fdf.tbt_kgrid) to obtain eg. a si.MonkhorstPack object, if specified that way in the fdf file, and otherwise another si.BrillouinZone object.

It would also be nice if similarly simple methods were possible for writing the fdf file. This would make it easy to read a previously used or partially-specified fdf file, add/override some details, and then output the new one more easily. Eg. take a previous calculation, but you've moved the electrodes, and you need more k-points, and you want to expand that basis set a bit, (etc), and then save. If you need to do several different configurations this could be favorable to manual copypasting+editing.

'Bothersome' details like writing a block that contains the names of other blocks should be handled behind the scenes. Another opportunity could be if eg. setting an electrode's atoms also automatically would add those atoms to %block Geometry.Constraints (necessary for some MD.TypeOfRuns and presumably no harm in the others).

I don't know if it all would fit in fdfSileSiesta, which has many methods already for reading data (and low, text-level access). Perhaps it should be a new class fdfConfigSiesta containing these things, which one might obtain on the fdfSileSiesta as a property (eg fdf.config.electrodes).

zerothi commented 4 years ago

This is definitely something on the wish list. However, I would probably start with defining classes which are decoupled from the fdf class. I.e. an OpenSystem class or NEGFSystem class which then contains the required information. In that way it isn't connected to Siesta/TranSiesta but could also be used for, e.g. WanT etc.

Also, the monkhorst-pack grid should be added as a write_brillouinzone or something similar.

zerothi commented 4 years ago

Actually this would go in-line with #196 (which would resolve #192 and others).

Once we have attributes associated with classes, this will become much easier!!! ;0)