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
182 stars 58 forks source link

sgeom: read relaxed geometry from fdf #422

Open tfrederiksen opened 2 years ago

tfrederiksen commented 2 years ago

Describe the feature

I am wondering if there could be a way to enable sisl.io.siesta.fdfSileSiesta.read_geometry(output=True) in the sgeom command line script?

This could be useful when converting a siesta relaxed geometry to fdf format without loosing the ChemicalSpeciesLabel (which is lost in a conversion directly from XV).

zerothi commented 2 years ago

By default sgeom *.fdf will try and read the *.XV using read_geometry(True) but only if it exists.

What errors did you encounter?

tfrederiksen commented 2 years ago

Well, it doesn't seem to read my XV files. Here is a minimal example of a RUN.fdf:

LatticeConstant 1.0 Ang
%block LatticeVectors
 10.00000000 0.00000000 0.00000000
 0.00000000 10.00000000 0.00000000
 0.00000000 0.00000000 10.00000000
%endblock LatticeVectors

NumberOfAtoms 2
AtomicCoordinatesFormat Ang
%block AtomicCoordinatesAndAtomicSpecies
 0.00000000 0.00000000 0.00000000 1 # 1: C
 3.00000000 0.00000000 0.00000000 2 # 2: H
%endblock AtomicCoordinatesAndAtomicSpecies

NumberOfSpecies 2
%block ChemicalSpeciesLabel
 1 6 C
 2 1 H
%endblock ChemicalSpeciesLabel

Then running siesta RUN.fdf I get the usual output files, among them siesta.XV. But if I modify the XV file, sgeom does not seem to read it:

$ sgeom RUN.fdf output.fdf

The output.fdf is identical to the initial geometry in RUN.fdf.

I also tried to add the fdf-keyword MD.UseSaveXV true in RUN.fdf but it has no effect for sgeom (only siesta now reads the XV).

zerothi commented 2 years ago

Ah, yes. Now I know...

Could you try with sdata? That should do it correctly... :crossed_fingers:

tfrederiksen commented 2 years ago

This works!

$ sdata RUN.fdf geom --out output.fdf

Now output.fdf corresponds to the XV file.

zerothi commented 2 years ago

Ok, good point. I'll try and fix this in sgeom, lets see what I can do...

tfrederiksen commented 2 years ago

Would it also make sense to enable the printout of which file being read? I see that one can do sgeom RUN.fdf --info but it doesn't tell me where exactly the geometry was found.

zerothi commented 2 years ago

I agree this would be ideal.

Possibly we should provide flags to make s* commands write to stderr with logging information, such as which files are touched.

this is a somewhat major task as it requires lots of manual inputs... But well-worth it I think!