ElasticMaker shouldn't use submaker as default factory by design

[chiang-yuan]

ElasticMaker shouldn't use submaker as default factory otherwise chgnet will be required to be installed as dependency

atomate2/src/atomate2/forcefields/flows/elastic.py

Lines 62 to 70 in 313f809

	bulk_relax_maker: ForceFieldRelaxMaker | None = field(
	default_factory=lambda: CHGNetRelaxMaker(
	relax_cell=True, relax_kwargs={"fmax": 0.00001}
	)
	)
	elastic_relax_maker: ForceFieldRelaxMaker | None = field(
	default_factory=lambda: CHGNetRelaxMaker(
	relax_cell=False, relax_kwargs={"fmax": 0.00001}
	)

[utf]

So currently, this doesn't actually require CHGNet to be installed I don't think. I.e., you can import this and overwrite those makers to get a MACE or M3GNet elastic constant workflow. However, it could make sense to create several versions of the workflow, one for each universal force field?

One thing I realised looking at this is that we can remove the prev_calc_dir_argname function from the BaseElasticMaker and subclasses since this has now been standardised across all codes.

[JaGeo]

So currently, this doesn't actually require CHGNet to be installed I don't think. I.e., you can import this and overwrite those makers to get a MACE or M3GNet elastic constant workflow. However, it could make sense to create several versions of the workflow, one for each universal force field?

One thing I realised looking at this is that we can remove the prev_calc_dir_argname function from the BaseElasticMaker and subclasses since this has now been standardised across all codes.

@utf also in the Abinit workflows?

[chiang-yuan]

Yes @utf you are definitely right - one could always replace default factory with the relaxmaker they like to use. However, I think this design is a bit counterintuitive and one might just want to set the forcefield calculator name and the code switch the input generator accordingly like what we did for MDMaker

Not a serious issue so maybe I shouldn't call it bug at the first place (I think it is the template..)