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

Fix silent error when running NotImplemented functions #6

Merged
merged 3 commits into from
Sep 3, 2024

Conversation

orionarcher
Copy link

@orionarcher orionarcher commented Aug 28, 2024

@esoteric-ephemera couple small fixes here.

I changed return NotImplemented -> raise NotImplementedError in three locations. The former fails silently.

I also added a little more flexibility around force field names. Now users can specify force_field_name="MACE" instead of force_field_name="MLFF.MACE" or force_field_name=str(MLFF.MACE).

@esoteric-ephemera
Copy link
Owner

Hey @orionarcher, the NotImplementedError change is fine, the change to how calculators are called kinda defeats the purpose of an enum no?

@orionarcher
Copy link
Author

orionarcher commented Sep 3, 2024

Good point, I rolled back that change but am still raising an error if no calculator is found.

To leverage the Enum, maybe it'd make sense to have the type of force_field_name be MLFF rather than str? Though I imagine it's the latter to support backward compatibility.

e.g.

@dataclass
class ForceFieldRelaxMaker(AseRelaxMaker):
    """
    ...

    Parameters
    ----------
    name : str
        The job name.
    force_field_name : MLFF
        The name of the force field.
    ...

    name: str = "Force field relax"
    force_field_name: str = f"{MLFF.Forcefield}"

@esoteric-ephemera
Copy link
Owner

To leverage the Enum, maybe it'd make sense to have the type of force_field_name be MLFF rather than str? Though I imagine it's the latter to support backward compatibility.

Yeah exactly for backwards compatibility. You've raised a lot of good points about where things are inefficient / badly-schema'd in the forcefields stuff. Since this PR is intended (no guarantees) to be non-breaking and just make it easier to support general ASE stuff, why don't we open a separate atomate2 PR with a the breaking changes for ASE / forcefields? Makes it easier for everyone to discuss, and it's a good time to make breaking changes while these are still new features

@orionarcher
Copy link
Author

Sounds good to me! I definitely don't mean to overload this PR or create more work for you.

@esoteric-ephemera esoteric-ephemera merged commit 808de7d into esoteric-ephemera:ase Sep 3, 2024
6 of 9 checks passed
@esoteric-ephemera
Copy link
Owner

Awesome thanks @orionarcher! As soon as this PR is merged on the atomate2 side, I'll open a new one for the breaking changes

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