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

Light refactor to enhance development #302

Closed
wants to merge 0 commits into from

Conversation

JustinBakerMath
Copy link
Collaborator

I'm initializing a PR with the following initiatives:

(1) light refactoring as discussed this morning (args -> create.py)
(2) equivariance clean up (inv_feat + geom_feat tracking inside of the MPNN)

I will complete this PR and add full documentation if there is interest in these initiatives.

@JustinBakerMath JustinBakerMath added documentation Improvements or additions to documentation enhancement New feature or request labels Oct 29, 2024
@JustinBakerMath JustinBakerMath self-assigned this Oct 29, 2024
@JustinBakerMath JustinBakerMath changed the title inv vs equiv feat + refactor create and embedding Light refactor to enhance development Oct 29, 2024
@allaffa allaffa marked this pull request as draft October 29, 2024 19:21
@allaffa allaffa requested a review from ArCho48 October 29, 2024 19:21
super().__init__(input_args, conv_args, *args, **kwargs)

assert (
self.input_args == "inv_node_feat, equiv_node_feat, edge_index, edge_attr"
Copy link
Collaborator

Choose a reason for hiding this comment

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

@JustinBakerMath

Does EGCL always require edge_attributes?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It does in the current/previous implementation. There is a way around this, but it may take some unrolling to update it.

],
)

def forward(self, data):
Copy link
Collaborator

@RylieWeaver RylieWeaver Oct 30, 2024

Choose a reason for hiding this comment

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

@JustinBakerMath

This is the largest advantage of the approach you're taking here, right? By generalizing (pos/v --> equiv_node_feature), you've taken out the need to rewrite the whole forward function.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The aim is to support the development equivariant architectures by providing a specific variable for handling equivariant information. This is done by improving the variable names to inv_node_feat and equiv_node_feat instead of vaguely named x, pos, respectively. One advantage would be that for many architectures, the forward function is handled by the Base class.

@RylieWeaver
Copy link
Collaborator

RylieWeaver commented Oct 30, 2024

@JustinBakerMath

Are the model stacks like PAINN, DimeNet, etc... finished with conversion to your proposed method here? If so, then I can take inspiration and adjust MACE tomorrow :)

Also, I think a version diff could be making black give you extraneous changes to the files in HYDRA, maybe check that black==21.5b1

@JustinBakerMath
Copy link
Collaborator Author

Yes. I will change the extra formatting back. I ran into some other issues with PAINN and PNAEq as observed in the most recent check. I ran out of time to reason through it yesterday. I will check it out this evening.

I have temporarily converted MACE to this format but I believe there is a better way to handle the variables. I would definitely appreciate help cleaning up MACE. Let me ping you when the checks pass for PAINN and PNAEq.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants