[DFTB-Plus-User] Requesting additional accessor functions in the DFTB+ api (or libdftb+)

[Nitant Gupta]

Dear Bálint,

Thanks for the encouragement. I will make the required request. I  
think with the ability to obtain stress-tensor, box relaxation is also  
possible externally.

As for the usage of the internal relaxation by the API, I was just  
wondering that if the goal is to eventually also relax the supercell,  
it may be faster(?) to have DFTB+ do the ionic relaxation, while the  
external code (e.g. MM) can do the box relaxation. If however there  
shouldn't be any difference in the speed then perhaps it is not useful.

Best regards,
Nitant

Quoting Bálint Aradi <aradi at uni-bremen.de>:

> Dear Nitant,
>
>> I am grateful for the inclusion of the api in the new release of
>> dftb+ (19.1).
>
> Thanks a lot, I am happy to hear, that you find the API useful.
>
>> -> dftbp_get_stress_tensor(): to obtain stress tensor
>>
>> -> dftbp_get_coords_and_lattice_vecs(): to obtain the current
>> coordinates and lattice vectors.
>
> None of the should be major difficulty. Could you make a feature request
> (issue) on GitHub listing this two items? Then it's easier to keep track
> of it.
>
>> -> I noticed that during the use of the api, if I specify
>> WriteResultsTag = Yes in the Options block, I still see no output
>> written to results.tag. Is this intended? -> As I noted above,
>> exclusively specifying the Driver block has no effect on the
>> calculation which is always static. I was wondering if there are any
>> plans to upgrade this functionality, to also allow access to
>> coordinates after geometry optimization?
>
> Yes, results.tag is not written as the current API basically accesses
> the processGeometry() subroutine
>
> https://github.com/dftbplus/dftbplus/blob/d47fa91e38c1528eb4aec11c60cc062aeda24265/prog/dftb%2B/lib_dftbplus/main.F90#L328
>
> but results.tag is written outside of it. For the same reason, the
> Driver {} block is completely ignored, as the idea is that the
> simulationion is driven from outside (e.g. by an MM-code).
>
> Could you eventually tell us more about the use case, where you think an
> internal geometry optimization triggered via the API could be useful?
> One may implement this, but that would require some code reorganization,
> so may not be entirely trivial.
>
> Best regards,
>
> Bálint
>
>
> --
> Dr. Bálint Aradi
> Bremen Center for Computational Materials Science, University of Bremen
> http://www.bccms.uni-bremen.de/cms/people/b-aradi/


-- 
Nitant Gupta

Doctoral Candidate (Master's Graduate)
Materials Science and NanoEngineering
Rice University, TX USA