Pin MACE calculator version, add missing metadata to AseStructureTaskDoc

[esoteric-ephemera]

Fixes three issues:

• MACE calculator previously relied on default being MACE-MP-0, whereas the default has now changed to an updated model, MACE-MPA-0
• The AseStructureTaskDoc and ForceFieldTaskDocument were missing some metadata fields when constructed from a relax job. These are just convenience things like number of elements, symmetry, etc. but should be populated
• Expands the number of forcefield flows with a from_force_field_name method

The MLFF option MACE still points to MACE-MP-0, whereas specifying:

• MACE_MPA_0 selects MACE-MPA-0
  -MACE_MP_0B3 selects MACE-MP-0b3

I think we want to avoid creating an MLFF forcefield interchange library a la LibXC, so I'm happy to remove the new MLFF values. Also, because MACE-OMat is ASL licensed, don't want to include this as an MLFF by default

[JaGeo]

As there are now 3 different MACE MP 0s, should we use 3b? For phonons, it is a lot better than the initial one, for example

[esoteric-ephemera]

Added 0b3 as well. Avoiding Omat for license reasons. Also added a from_force_field_name method to the phonon and QHA makers to allow easier instantiation of these from a str

[JaGeo]

@esoteric-ephemera thank you!

I am still thinking about a few points:

• i am currently not sure how much better the alexandria model will be but it is the new default in mace
• users might be confused when we do not use the same default as in mace
• we should likely use the same nomenclature as in mace as users might also be confused otherwise
• we should keep the tests with mace-mp-0 (the first one)

What do you think?

[esoteric-ephemera]

@JaGeo these are good points, they merit some discussion. The default in mace_torch is going to change over time as new models are trained. @janosh can comment on that if I'm wrong

I primarily want to avoid a situation where workflows aren't reproducible using the same settings. Adding a MACE_MP_0 MLFF that is identical to MACE, and throwing a warning whenever MACE is specified might be the way to go

[janosh]

Adding a MACE_MP_0 MLFF that is identical to MACE, and throwing a warning whenever MACE is specified might be the way to go

agreed, that sounds good 👍

[JaGeo]

@JaGeo these are good points, they merit some discussion. The default in mace_torch is going to change over time as new models are trained. @janosh can comment on that if I'm wrong

I primarily want to avoid a situation where workflows aren't reproducible using the same settings. Adding a MACE_MP_0 MLFF that is identical to MACE, and throwing a warning whenever MACE is specified might be the way to go

Agreed! This sounds very good! Backward-compatibility is extremely important as well!

[JaGeo]

@esoteric-ephemera thank you very much! This is great! I will merge!