Skip to content

WIP: Allowing specific points in ol-stm

Pol Febrer requested to merge pfebrer/siesta:path_STS into rel-4.1

Linked to #113.

This addresses my main concern with ol-stm i.e. that I needed to compute the whole grid for each energy. With this merge request much finer spectra (more energy points) can be computed if you know what are the points that you are interested in. (good to draw paths, for example).

The implementation reuses the same logic that was there in case no projection was needed, since the only difference with having specific points lies in how you calculate the points where STS are computed (list of points vs npx, npy, npz). Therefore I moved the calculation to a new subroutine add_all_Es.

The way you ask for a specific list of points (for now) is with the block STM.Points. Like this:

%block STM.Points
        2.48622900  3.68000000  4.1
        2.48622900  3.68000000  4.2
        2.48622900  3.68000000  4.3
        2.48622900  3.68000000  4.4
%endblock STM.Points

If STM.Points is present, then the rest of inputs (npx, npy, npz, zmax, zmin) are ignored. This block can be added to the benzene example to check how the functionality works.

The output is stored in a matrix written in a plain text file where rows are the point indices and columns correspond to the different energies.

This is still a WIP because I need @garalb advice on some aspects:

  • Right now, the memory needed in the variable stm_points is hard coded because I don't know how to do it to allocate memory inside readstm.f, where I read the points.
  • Should I call the output file SystemLabel.ST?.txt?
  • For some reason that I don't understand, everything works well but when the program gets to the end it crashes with a segmentation fault (only in STS points mode, the output file is correctly written). Maybe you can understand why?

Also:

  • When (if) we agree in the implementation, I need to add the functionality to stm.f, if it makes sense.

Cheers!

Merge request reports