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

Print warnings when incompatible parameters are used #271

Open
RaulPPelaez opened this issue Feb 5, 2024 · 4 comments
Open

Print warnings when incompatible parameters are used #271

RaulPPelaez opened this issue Feb 5, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@RaulPPelaez
Copy link
Collaborator

The OP in this issue openmm/openmm-torch#133 was led to believe the Graph Network is equivariant because TorchMD-Net provides the "equivariant_group" parameter (which is only used by TensorNet).
This happens a lot in the current parameter handling, where "irrelevant" parameters are silently ignored in, sometimes subtle, ways.

For instance, if a user sets y_weight=1 but the dataset does not provide energies, the code just ignores y_weight.

I am opening this issue to discuss some mechanism for these things to result in, at least, a warning.

Arguably, the better way to handle these architecture-specific parameters would be to treat them similarly as the dataset_args parameter, so that one would have to write:

model: "graph-network"
model_args: 
    hidden_channels:128
    ...

So that it is clear that:

  1. The params are for the model.
  2. Some parameters work for some models but not for others.

However, this change would break old parameter files. Perhaps there could be a notion of versions in the parameter files?

@AntonioMirarchi
Copy link
Contributor

AntonioMirarchi commented Feb 5, 2024

I think the problem is more about when the input.yaml is written. Perhaps, it's enough to modify this function excluding all the hparms that are not used by the model or in general avoiding to save the entire argparse.NameSpace().

@peastman
Copy link
Collaborator

peastman commented Feb 5, 2024

How about this syntax:

model: graph-network
  hidden_channels: 128

It's even simpler, and it matches the syntax for priors. We can maintain backward compatibility by continuing to support the old syntax for a while. If it doesn't find a parameter it's looking for under the model, it will look for it at the top level but print a warning telling the user that syntax is deprecated.

@giadefa
Copy link
Contributor

giadefa commented Feb 6, 2024 via email

@RaulPPelaez
Copy link
Collaborator Author

Peter's is the way to go IMO. In principle this functionality would be compatible with the changes introduced by #239 (if/when), since implementing this one means writing a more sane parameter handling.
Thanks guys.

@RaulPPelaez RaulPPelaez added the enhancement New feature or request label Feb 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants