requirements interference with matminer about dscribe HOT 6 CLOSED

Hi @ardunn!

Thanks for your message. We would, of course, be very glad to help with this. Matminer is a great piece of software and we are very glad to hear that you're interested in DScribe.

Some of the old versions of DScribe had a bit superfluous dependencies but the newest version are much lighter on them. Is there any specific reason for why you want to go with DScribe 0.2.5 and not the newest version 0.2.9?

For one, it seems dscribe 0.2.5 is dependent on matminer, which makes them are circularly dependent.

There definitely shouldn't be any intentional dependency on matminer at any point in the version history. Can you elaborate on where this circular dependency is coming from? I could not see any obvious dependency route for matminer even on DScribe 0.2.5.

Secondarily, dscribe 0.2.5's install also installs sklearn 0.20.3 while we are upgrading matminer to 0.21.3, which will create a pip version conflict

Possibly this issue would go away by using the newest version 0.2.9, which does not require any specific version of sklearn, but would do just fine with whatever version of sklearn matminer uses? (unlike e.g. 0.2.5 which requires scikit-learn==0.20.3).

Tell me what you think or if you have better suggestion in mind.

from dscribe.

Hi @ardunn,

I would then strongly suggest going for 0.2.9 as in addition to solving the dependency problems there have been some major performance improvements starting from 0.2.8 for MBTR and ACSF.

Would anyone from dscribe be interested in auditing our SOAPFeaturizer and checking for places where matminer's implementation could be improved?

Sure thing. Can you open a new issue on this on matminer's side and give me the link to it? I can probably suggest something or open a pull request.

from dscribe.

Hey @lauri-codes

Seems the circular dependency may have just been an artifact of our CI. If it happens again I'll update this issue but consider that problem closed for now :)

Some of the old versions of DScribe had a bit superfluous dependencies but the newest version are much lighter on them. Is there any specific reason for why you want to go with DScribe 0.2.5 and not the newest version 0.2.9?

No 0.2.9 would be great, although (if I remember correctly) there might be some breaking changes to the current matminer interface (nothing major, just something one of our users picked up).

Possibly this issue would go away by using the newest version 0.2.9, which does not require any specific version of sklearn, but would do just fine with whatever version of sklearn matminer uses? (unlike e.g. 0.2.5 which requires scikit-learn==0.20.3).

This sounds like it would resolve the issue entirely!!

Both of your suggestions sound great. We already have a few dscribe SOAP related issues in the repo hackingmaterials/matminer#413 hackingmaterials/matminer#389 which I will get around to fixing shortly (hopefully)

On another note,

I am the one who implemented the SOAP featurizer in our repo, but I am certainly not an expert on using SOAP nor its implementation in dscribe. Would anyone from dscribe be interested in auditing our SOAPFeaturizer and checking for places where matminer's implementation could be improved?

For example, the current default SOAPFeaturizer returns a vector of SOAP features for each sample (to later be used in an arbitrary ML algo). While convenient for matminer, I'm not sure this is the best way to extract the maximum amount of information from the samples

from dscribe.

On yet another note,

We are planning on implementing some of the other dscribe classes in matminer, such as MBTR, so you might see me opening issues/PRs on here if things go awry on my end lol

from dscribe.

Hey @lauri-codes, I opened a corresponding issue here: hackingmaterials/matminer#420

We have updated to 0.2.9. I think the motivation for checking the SOAP implementation on our side is even stronger now since presumably there have been some changes in dscribe since 0.1.8!!

We have not implemented a MBTR or ACSF matminer featurizer interface to dscribe yet but it is certainly on our radar (see hackingmaterials/matminer#241). If you know the best way to do this, we'd certainly appreciate advice on that also.

from dscribe.

Hi @ardunn,

Building the MBTR featurizer should be a piece of cake since you already have some kind of integration for DScribe. The ACSF interface will still change in DScribe in the near future, so I would wait until that refactoring is done before building a featurizer for it.

I now replied in the matminer issues. We can carry on the conversation there. Closing this issue for now.

from dscribe.