Molecule for forcefield

[yaoyi92]

Summary

Discussed in #1123. Following the same strategy as ase tasks, output ForceFieldStructureTaskDocument or ForceFieldMoleculeTaskDocument based on the input type of mol_or_struct.

Checklist

Work-in-progress pull requests are encouraged, but please put [WIP] in the pull request
title.

Before a pull request can be merged, the following items must be checked:

• Code is in the standard Python style.
  The easiest way to handle this is to run the following in the correct sequence on
  your local machine. Start with running ruff and ruff format on your new code. This will
  automatically reformat your code to PEP8 conventions and fix many linting issues.
• Doc strings have been added in the Numpy docstring format.
  Run ruff on your code.
• Type annotations are highly encouraged. Run mypy to
  type check your code.
• Tests have been added for any new functionality or bug fixes.
• All linting and tests pass.

Note that the CI system will run all the above checks. But it will be much more
efficient if you already fix most errors prior to submitting the PR. It is highly
recommended that you use the pre-commit hook provided in the repository. Simply run
pre-commit install and a check will be run prior to allowing commits.

[yaoyi92]

Dear @JaGeo, can you help take a look at this PR at your convenience?

[JaGeo]

Thank you!

I am tagging @utf and @esoteric-ephemera as well as we have to decide how to handle molecular and structural outputs in general.

[yaoyi92]

Here is my understanding of how to handle molecular and structural outputs. I saw in atomate2, two approaches exist. In FHI-aims, and cp2k engines, their taskdoc inherents from both StructureMetadata, MoleculeMetadata and the output structure takes the same type of the input structure. While, in ase engine, the implementation is to output StructureTaskDoc or MoleculeTaskDoc based on the input structure. Since, the forcefield inherents mostly from ase, I picked the second approach. The FHI-aims/cp2k approach is cleaner in software engineering. However, StructureMetadata and MoleculeMetadata seems to have different symmetry types. I am not sure whether a conflict will happen is symmetry is used. My understanding is to make them fully compatible with each other would require a rework at the emmet-core level.

[esoteric-ephemera]

Hey @yaoyi92, thanks for making this extension to the forcefields! The split that occurs for StructureMetadata and MoleculeMetadata-based task documents in ASE is to ensure there are no collisions between attributes with the same names.

I would avoid merging the ememt-core classes - we're already in the process of reworking the TaskDoc and other schemas in emmet-core to enforce stricter typing

To @JaGeo's point: we have too many disparate schemas for each code, and it would likely be best to have them originate with the same base document models. Maybe we should start an issue for this?

[JaGeo]

@esoteric-ephemera I agree with your points and I also believe we should think about the task docs more broadly.