jameskermode / f90wrap

F90 to Python interface generator with derived type support

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

excess constructors -- QUIPPY not wrapping correctly

stenczelt opened this issue · comments

quippy is not wrapping correctly with the master branch of f90wrap:

Python 3.9.1 (default, Dec 11 2020, 14:32:07) 
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from quippy.potential import Potential
>>> calc = Potential("", param_filename="GAP_iter_10.committee_0.xml")
/opt/womble/miniconda3/user_envs/tks32/quip-neb/lib/python3.9/site-packages/ase/calculators/calculator.py:507: FutureWarning: The keyword "ignore_bad_restart_file" is deprecated and will be removed in a future version of ASE.  Passing more than one positional argument to Calculator is also deprecated and will stop functioning in the future.  Please pass arguments by keyword (key=value) except optionally the "restart" keyword.
  warnings.warn(FutureWarning(
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/womble/miniconda3/user_envs/tks32/quip-neb/lib/python3.9/site-packages/quippy-git_github.com_libatoms_QUIP.git_27cfea33f_dirty-py3.9-linux-x86_64.egg/quippy/potential.py", line 81, in __init__
    self._quip_potential = quippy.potential_module.Potential.filename_initialise(args_str=args_str,
AttributeError: type object 'Potential' has no attribute 'filename_initialise'
>>> exit()

The issue is coming from a @classmethod missing for the Potential which is generated by the excess constructor in an interface. I think that this should be making it:

child.attributes.append('classmethod')
log.info('transform excess constructor to classmethod %s', child.name)

maybe from #136

Thanks for reporting. Reproduced, and will look at fixing ASAP. As mentioned, for QUIP please continue to use the pinned commit a580827 for now which does not have this issue.

I just encountered the same issue as @stenczelt above with the newest version of f90wrap. The error went away after checking out a580827 and making that one (I also recompiled QUIP and quippy). However, now I get the memory leak issue again ... Do you @jameskermode have any suggestions what I could try?

I'm afraid I haven't had a chance to look into this yet and won't be able to for a couple more weeks. a580827 should not have the memory leak, since that's the commit which fixed it. Are you sure that is the f90wrap that is being used to build quippy? Worth checking the value of F90WRAP in QUIP/quippy/Makefile

I agree that a580827 should not have the issue, and most likely this is an issue with my installation.
However, I checked the path for F90WRAP in QUIP/quippy/Makefile, and it leads to the version of f90wrap I just made. Also, that I can replicate the error from the first post indicates that I actually am using the f90wrap version I think I am using. In addition I am quite sure that there is no other version of f90wrap an my machine (i.e. pip show f90wrap cannot find any).
Am I overlooking something here?

No, I can't see anything you are missing - perhaps there is another memory leak. I will try to fix this current issue soon so that the master branch of f90wrap can be used with QUIP once more, but if there's another memory leak we should try to track that down. If you can open a new issue with a minimal script that shows the memory usage increasing then I can take another look at it with valgrind.

Will do. (Most likely on Friday.)

@stenczelt Thanks for pointing me to the right place for this. Better late than never - turned out to be a trivial fix with 'Potential_module' not matching 'potential_module'. Converting everything to lowercase solves the problem. I'll update the version used in QUIP, which gets us one step closer to a functioning pip install quippy-ase.