Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to fill all species when computing PowerSpectrum #214

Merged
merged 1 commit into from
Aug 17, 2023

Conversation

PicoCentauri
Copy link
Collaborator

@PicoCentauri PicoCentauri commented Aug 7, 2023

Possible fix for #213.

This adds the option fill_species_neighbor to the compute method of PowerSpectrum. Setting this to True changes keys_to_move when performing keys_to_properties in such a way that it contains all species of the provided systems.

I am not super happy with the name of the parameter but I think the it should be part of the the compute method.


📚 Documentation preview 📚: https://rascaline--214.org.readthedocs.build/en/214/

@github-actions
Copy link

github-actions bot commented Aug 7, 2023

Here is a pre-built version of the code in this pull request: wheels.zip, you can install it locally by unzipping wheels.zip and using pip to install the file matching your system

@ceriottm
Copy link
Collaborator

ceriottm commented Aug 7, 2023

I think the ideal implementation would be something that has an option neighbor_species that defaults to None (and then automatically fetches them from the inputs) or a list of labels or numbers (and then makes sure that all the missing ones are padded with zeros.

Comment on lines 195 to 200
keys_to_move = Labels(
names="species_neighbor",
values=np.unique(
spherical_expansion_1.keys["species_neighbor"]
).reshape(-1, 1),
)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd be fine with this being the only behavior: we are not introducing too much zeros since we are moving the two spherical expansions separately, so we could just always do this and not have an extra option.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, even better if we do not overload the parameters with more and more options.

@Luthaf
Copy link
Owner

Luthaf commented Aug 15, 2023

I think the ideal implementation would be something that has an option neighbor_species that defaults to None (and then automatically fetches them from the inputs) or a list of labels or numbers (and then makes sure that all the missing ones are padded with zeros.

That could work as well, but I don't love that we are introducing a new set of parameters just for this. This feels very similar to the job done by selected_properties. Implementing full support for selected_properties in Python would be relatively hard, but we should also consider it!

I am not super happy with the name of the parameter but I think the it should be part of the the compute method.

The issue with making it part of the compute method is that we now have different set of options for Rust calculators and this Python calculator, which I don't love. I agree it feels much more natural to have it here though!

@PicoCentauri PicoCentauri merged commit 4b72b17 into master Aug 17, 2023
18 checks passed
@PicoCentauri PicoCentauri deleted the ps_ns branch August 17, 2023 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants