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

Another FastSystem constructor #63

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

rkurchin
Copy link
Collaborator

I found myself wanting to be able to construct a FastSystem without needing to explicitly build the lists of atomic data when they could be inferred, so I added a constructor that will infer atomic numbers and masses if you only supply the symbols. We could also merge this into the original one by providing default values for the latter two arguments. I am completely fine changing this to that instead, i.e. removing the new one I added and instead modifying lines 15-20 to be something like:

# constructor to fetch the types where numbers/masses are explicitly provided
function FastSystem(box, boundary_conditions, positions, atomic_symbols, atomic_numbers=getproperty.(element.(atomic_symbols), :number), atomic_masses=getproperty.(element.(atomic_symbols), :atomic_mass))
    FastSystem{length(box),eltype(eltype(positions)),eltype(atomic_masses)}(
        box, boundary_conditions, positions, atomic_symbols, atomic_numbers, atomic_masses
    )
end

...but that's also a little clunky to read. 🤷‍♀️

@mfherbst
Copy link
Member

...but that's also a little clunky to read.

Not if you add line breaks?

Also why are atomic symbols special. What if I want to supply the atomic numbers instead? What I'm getting at is that we have a different but similar mechanism in the Atom and I think for consistency they both should support the same sort of stuff.

Also a test would be good ;).

@rkurchin
Copy link
Collaborator Author

Not if you add line breaks?

Also why are atomic symbols special. What if I want to supply the atomic numbers instead? What I'm getting at is that we have a different but similar mechanism in the Atom and I think for consistency they both should support the same sort of stuff.

All fair points. Do you think basically duplicating the version we have for Atom (i.e. anything that can index into PeriodicTable.elements) would suffice here? While I could see someone wanting to pass either symbols or atomic numbers and have the others inferred, I kind of doubt they'd ever want to pass only atomic masses...

Also a test would be good ;).

Absolutely, wanted to just stick in a quick implementation to start this discussion, would for sure add this before merging. 😉

@mfherbst
Copy link
Member

mfherbst commented Feb 1, 2023

@rkurchin Super sorry. I completely forgot about this PR. I'll take another look later today.

@mfherbst
Copy link
Member

mfherbst commented Feb 1, 2023

Yes I would essentially duplicate the version from Atom, i.e. just pass in a list of Identifiers (type AbstractVector{<:AtomId}) and then just use those to extract symbol, number and mass automatically to fill the kwargs).

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.

2 participants