Importing interface.py requires ASE anyway

[pierre-24]

Describe the bug
I'm trying to achieve an interface between gaussian and xtb in order to perform xtb:QM onium calculations. Until recently (since it wasn't possible for me to compile xtb in the past), I was using a custom interface inspired by the previous python file (which does not work with the current version, for this reason), but I would prefer to rely on your implementation of the interface.py file.

I don't really want to have ASE as a dependence for that, since I only need to perform a bridge between the two codes. Not that ASE is a heavy dependence, but it would be weird to require it.

To Reproduce
Steps to reproduce the behaviour:

1. I add the python directory to PYTHONPATH
2. In the python code, I use from xtb import interface

The result is, obviously,

Traceback (most recent call last):
  File "/home/pbeaujea/g2xtb_interface/interface.py", line 11, in <module>
    from xtb import interface as xtb_interface
  File "/home/pbeaujea/.install_stda/xtb/python/xtb/__init__.py", line 20, in <module>
    from xtb.calculators import GFN1, GFN2, GFN0
  File "/home/pbeaujea/.install_stda/xtb/python/xtb/calculators.py", line 24, in <module>
    from ase.calculators.calculator import Calculator, all_changes
ImportError: No module named 'ase'

... Since __init__.py is always imported.

Expected behaviour

I get why you included calculators in __init__.py , but in my case, it is problematic: I could always copy/paste interface.py from your repo to mine, but that would not be very elegant (and its probably not the best way due to licencing stuffs).

[awvwgk]

Probably the best way would be to separate the Python API from the ASE calculator for this, maybe even in separate repositories. We should discuss this.

[pierre-24]

It depends on what you are trying to achieve with it. For me (and in my case), having a interface.py file in a xtb package is ok, since it is easy to import it this way. The ASE calculator would be an example to show that you can then interface xtb with anything, and would be a little bit "higher level abstraction".

But that's my point of view :)

[awvwgk]

I thought including dependencies would ensure that they are present downstream:

xtb/python/setup.py

Line 36 in ad49de1

install_requires=['ase'],

Right now ASE ensures that structures are represented in a meaningful way, the Atoms class is by far the most easy and complete way to address this problem. An alternative could be something like QCSchema, which has other drawbacks, like it is missing PBCs (see MolSSI/QCSchema#66). A couple of ndarrays is the least preferable way, at least in my opinion.

BTW, ASE offers a QM:MM functionality and a Gaussian calculator.

[awvwgk]

So at this point it is unlikely that we will drop the ASE dependency, but we might guard the import in the __init__.py in case it is not present. Would that help?

[pierre-24]

That might probably work, indeed :)

…

On Fri, Jan 10, 2020, 20:21 Sebastian Ehlert ***@***.***> wrote: So at this point it is unlikely that we will drop the ASE dependency, but we might guard the import in the __init__.py in case it is not present. Would that help? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#95?email_source=notifications&email_token=AB4GGC2UMCD6K3SK4ABREL3Q5DDFHA5CNFSM4KFIOJ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIU6LOQ#issuecomment-573171130>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4GGCZO5AC3VUCIQMAHMITQ5DDFHANCNFSM4KFIOJ5Q> .

[awvwgk]

@pierre-24 wouldn't it be easier to implement the Gaussian input and output format directly in xtb? Looking at your project, you have almost more code dealing with the xtb interface than with the Gaussian interface.

Adding the reader for the input format would require the file extension to be detected correctly in file_figure_out_ftype and a specific reader for such format in xtb/molecule_reader.f90. Writing could occur like for the Turbomole gradient file at

xtb/xtb/program_main.f90

Lines 786 to 787 in ad49de1

	call generic_header(iprop,'Property Printout',49,10)
	if (lgrad) call tmgrad(mol%n,mol%at,mol%xyz,g,etot)

Anything else?

For maybe obvious reasons I can't implement nor test such interface, but it would still be an unique contributing opportunity, to put it that way ;).

[pierre-24]

Mmmh, I didn't know (or more probably, I forgot) that it was possible to interface the xtb program directly. That may be indeed an interesting idea :)

…

On Fri, Jan 10, 2020, 21:20 Sebastian Ehlert ***@***.***> wrote: @pierre-24 <https://github.com/pierre-24> wouldn't it be easier to implement the Gaussian input and output format directly in xtb? Looking at your project, you have almost more code dealing with the xtb interface than with the Gaussian interface. Adding the reader for the input format would require the file extension to be detected correctly in file_figure_out_ftype <https://github.com/grimme-lab/xtb/blob/master/xtb/tbmod_file_utils.f90> and a specific reader for such format in xtb/molecule_reader.f90 <https://github.com/grimme-lab/xtb/blob/master/xtb/tbmod_file_utils.f90>. Writing could occur like for the Turbomole gradient file at https://github.com/grimme-lab/xtb/blob/ad49de1a24edbb8645acb0811509a5c0a2dd2485/xtb/program_main.f90#L786-L787 Anything else? For maybe obvious reasons I can't implement nor test such interface, but it would still be an unique contribution opportunity, to put it that way ;). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#95?email_source=notifications&email_token=AB4GGCYHBNN3VO722MWFAYLQ5DKBXA5CNFSM4KFIOJ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIVDEBY#issuecomment-573190663>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4GGC4DRCJCKAROOQWHGTTQ5DKBXANCNFSM4KFIOJ5Q> .

[dgasmith]

+1 here. It would be great to have python basic ctypes interface without the ASE requirement. Happy to take on the extra formatting onus. If you could ensure the interface.py is at least somewhat stable we could copy that as well.

[awvwgk]

Since I am currently reworking the C-API in #102, I could also look over the Python-API again. There is certainly a way to add optional dependencies for Python modules and than separate the ASE calculator implementation from the basic Python-API.

[dgasmith]

A way to accomplish this would be something like the following:

In the setup.py:

    extras_require={
        "ase": ["ase"]
    }

The xtb/__init__.py would not have import ase so then access would be via:

import xtb.ase
xtb.ase.calculator()

or

from xtb.ase import ase_calculator
ase_calculator()

The ase.py could have something like

try:
    import ase
except ModuleNotFoundError:
    raise MolduleNotFoundError("This submodule requires ASE, please install via 'pip install ase'")

This kind of structure seems fairly standard.

[awvwgk]

Thanks, I'll give this a try after finishing #102.

[awvwgk]

Finally decided that the Python API is not going to a part off this repository anymore. We will keep the ctypes interface for testing purposes, but it shouldn't be used for production.

[pierre-24]

Just to be clear, you'll rely on a fully C API, then ?

[awvwgk]

Yes, this repository will only expose a C API. The ctypes API has a lot of shortcomings, in my opinion the easiest way to avoid those is to not have a ctypes API for Python.

There will still be a Python API to xtb, but this is another project for another repository, probably I will use CFFI or SWIG for this purpose.

[pierre-24]

As long as there is an API, it is fine by me :)

[awvwgk]

The basic Python API is now successfully migrated to https://github.com/grimme-lab/xtb-python.