Skip to content

Conversation

@ElliottKasoar
Copy link
Member

Resolves #327

For model_path (or equivalent inputs e,g, model), this adds mlip_model as an info label when structures are output.

For strings and paths, this is fine. For already-loaded torch models, it's less clear what the best label is, so I'm open to alternatives.

This will also interact with any implementation of #240, but we can deal with that when we come to it.

@alinelena, was the suggested info['{arch}_{model}'] = model replacing info["arch"] or additional? To me it doesn't make sense to have "{arch}_model" as well as "arch", which is how I originally interpreted it, but perhaps it makes sense to combine them into a single info label, which I just realised may be what you meant.

@ElliottKasoar ElliottKasoar added the enhancement New/improved feature or request label Oct 22, 2024
@alinelena
Copy link
Member

we need to think about this one, what happens if we have two calculations, both arch=mace but model=small and model=large, how will the extxyz look and similarly if we have some models passed by paths(do we get only the basename for mlip?). I think will be nice to document all this structure of what we want and then review the code accordingly

@ElliottKasoar
Copy link
Member Author

we need to think about this one, what happens if we have two calculations, both arch=mace but model=small and model=large, how will the extxyz look and similarly if we have some models passed by paths(do we get only the basename for mlip?). I think will be nice to document all this structure of what we want and then review the code accordingly

Good question. At the moment I think having the same arch is relatively clean, if not perfect, since info["arch]", info["mlip_model"], and labelled results should all just be replaced. This means we can't save both sets of results, but at least I don't think it should be a confusing mix of both.

E.g. arch=mace, mlip_model=small, mace_energy=x -> arch=mace, mlip_model=large, mace_energy=y

When we change architecture, this is a bit more complicated, since we'd change info["arch]", info["mlip_model"], but keep both sets of results.

E.g. arch=mace_off, mlip_model=small, mace_off_energy=x -> arch=mace_mp, mlip_model=large, mace_off_energy=x, mace_mp_energy=y.

I implemented it this way for now since it means mlip_model essentially works the same as arch already does - we can only keep the last one, even if we add new results.

We could change both to potentially be lists (if more than one value), either as two individual lists or a combined entry {arch}_model={model}.

This does make things more complicated though, since we'd then want to do something like convert repeated {arch}_{property} entries e.g. mace_energy into a list too, but only if the model has changed...

similarly if we have some models passed by paths(do we get only the basename for mlip?)

Regarding paths, at the moment model paths are saved as str(Path(model_path).expanduser()) e.g. ~ expands to mlip_model=/home/ek/.cache/mace/46jrkm3v, but you might get mlip_model=46jrkm3v for a relative model path. Maybe we should change this to absolute.

@alinelena
Copy link
Member

ok I think we need to document very well the behaviour of this with examples since there is no obvious solution.

@alinelena alinelena merged commit 563742a into stfc:main Nov 14, 2024
8 checks passed
@ElliottKasoar ElliottKasoar deleted the update-arch-info branch November 14, 2024 16:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New/improved feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

add model info to extxyz

3 participants