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

[Feature request]: Reconciling multi task models with ase Calculator interface. #217

Closed
6 tasks
laserkelvin opened this issue May 15, 2024 · 2 comments · Fixed by #224
Closed
6 tasks

[Feature request]: Reconciling multi task models with ase Calculator interface. #217

laserkelvin opened this issue May 15, 2024 · 2 comments · Fixed by #224
Assignees
Labels
enhancement New feature or request

Comments

@laserkelvin
Copy link
Collaborator

Feature/behavior summary

Per #215 MultiTaskLitModules are a supported type of task to be passed into the calculator, but the calculate step doesn't treat it any differently even when it is actually required.

Request attributes

  • Would this be a refactor of existing code?
  • Does this proposal require new package dependencies?
  • Would this change break backwards compatibility?
  • Does this proposal include a new model?
  • Does this proposal include a new dataset?
  • Does this proposal include a new task/workflow?

Related issues

No response

Solution description

We need a way to:

  1. identify when inference results come from a MultiTaskLitModule
  2. In the case where only one subtask is relevant, figure out how to extract those results and map them into the Calculator
  3. In the case where multiple subtasks are relevant, figure out how to aggregate the result and report a scalar as expected by ase

Additional notes

No response

@laserkelvin
Copy link
Collaborator Author

@melo-gonzo please add scenarios I might have missed!

@melo-gonzo
Copy link
Collaborator

Some more notes for consideration:

Related to 3, two subtasks may output relevant information but not complete information. For example using a ScalarRegressionTask for energy prediction, and GradFreeForceRegression for forces.

Initially I think doing basic combinations of output heads with the same task keys would be best, and future aggregations could be PR'd later as features. Perhaps starting with mean, and weighted mean (weigh by subtask) would be a good starting point.

Finally, I think related to #104, the datasets which are used with MultiTaskModules may have slightly varying keys (energy, energy_total, corrected_total_energy, ...) so introducing a mapping to proper/uniform outputs could be important as well.

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

Successfully merging a pull request may close this issue.

2 participants