-
Notifications
You must be signed in to change notification settings - Fork 74
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
Comments
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. |
The reason we didn't use this structured input in the past was too be able
to set parameters from command line, but I am not sure that we still use
the command line at all
…On Tue, Feb 6, 2024, 00:39 Peter Eastman ***@***.***> wrote:
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.
—
Reply to this email directly, view it on GitHub
<#271 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3KUOXUZOKWKTLEZHQ3FQLYSFURXAVCNFSM6AAAAABC2RKZ5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRYGUYTCMJWGY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
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. |
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:
So that it is clear that:
However, this change would break old parameter files. Perhaps there could be a notion of versions in the parameter files?
The text was updated successfully, but these errors were encountered: