profess-dev / profess

MIT License
2 stars 0 forks source link

Issue with "Unregistered type : deft::Array<double>" #15

Open cw-tan opened 1 year ago

cw-tan commented 1 year ago

When I was testing out the example on the PROFESS website where we optimize the density of fcc Al and plot its electron density, I faced some errors involving the deft array types.

Minimal code to reproduce the error:

import profess
import numpy as np

box_vectors = 4.05 * np.identity(3)
energy_cutoff = 1200
system = profess.System.create(box_vectors, energy_cutoff, ['a','ev'])
den = system.electron_density  # error here

Error message:

TypeError: Unregistered type : deft::Array<double>

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/cw/OFDFT/profess/example/example.py", line 7, in <module>
    den = system.electron_density  # error here
TypeError: Unable to convert function return value to a Python type! The signature was
        (self: profess.System) -> deft::Array<double>

Trying den = system.electron_density[...] still results in the same error. Not sure if this is a result of the updated pybind11, or something about my system.

Versions: python --version gives Python 3.10.8 cmake --version gives cmake version 3.22.1 gfortran --version gives GNU Fortran (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 ...

wcwitt commented 1 year ago

Thanks, I've reproduced this and will look into it.

wcwitt commented 1 year ago

Okay I understand now. To use the deft object explicitly (the electron density), one needs to import pydeft, and to do that you need profess/build/external/deft in your PYTHONPATH, in addition to profess/build. Does that fix things for you?

Even if so, I'm going to leave the issue open until I come up with a better solution.

cw-tan commented 1 year ago

That makes sense - it works now. From a user perspective, I think it might be cleaner if we don't have to interact with DEFT at all. Is there an easy way to make sure that anything that comes out of a system.get() type function is always a Numpy array? This may be more intuitive and simplify post-processing grid-based quantities. (related to #10). I'm happy to have a go if you have any ideas (maybe making edits at the pybind scripts?)

wcwitt commented 1 year ago

Agree completely, but if I remember correctly it's a bit subtle, unfortunately.