If we want to make any other changes to our docs or README, this is the PR to do it, since after we merge this in, we will cut the release

Codecov Report

❗ No coverage uploaded for pull request base (main@2e61215). Click here to learn what that means.
The diff coverage is n/a.

• Add list of compatible models

I can't seem to be able to make a multi row or coloum label in markdown (and I rather not have to breakout my html) is this clear? or confusing? better ideas? This would go in the readme

update:

Looks great! Do we want to add espaloma-0.2.x codes? Also, how about a cross (X) instead of a circle? Circles could have positive meanings, and I got slightly confused for a second. Or we could just use the check and leave not-supported as blank?

one concern with the table is that if we have more models and code versions, the table will expand? trying to think if there is a better way.

I wonder if something like the following would work?

EDIT: Or we could use the versions instead of the keyword latest to make it clearer and avoid having to change more things in the future.

Sorry I meant to use ❌ so that we also don't have an issue red-green color blindness as well.

Looks great! Do we want to add espaloma-0.2.x codes?

I can, but is espaloma-0.2.x relevant still? As in, do we want users to think about that version of the code? Our papers explain the versions used so I think that satisfies concerns about reproducibility.

one concern with the table is that if we have more models and code versions, the table will expand? trying to think if there is a better way.

I think we only need to expand it for the same "family" of models, we could make a separate table for the 0.4.x series for example

or something like this one?

I wonder if something like the following would work?
Code version support
espaloma-0.3.0.pt model ⚠️ up to 0.3. 0
espaloma-0.3.1.pt model ✅ latest
espaloma-0.3.2.pt model ✅ latest

EDIT: Or we could use the versions instead of the keyword latest to make it clearer and avoid having to change more things in the future.

This isn't bad, I might change ⚠️ up to 0.3.0 to ⚠️ only version 0.3.0 (since I don't think 0.3.0.pt works with espaloma<0.3.0) But it is compact and communicates the same information.

Thinking more, I would still put the code versions ✅ latest (>=0.3.1) or something just to make it more clear.

or something like this one?
Model DOI Supported Espaloma version Release Date Espaloma architecture change?
espaloma-0.3.2.pt 0.3.1, 0.3.2 Sep xx, 2023 No
espaloma-0.3.1.pt 0.3.1, 0.3.2 Jul 17, 2023 Yes
espaloma-0.3.0.pt 0.3.0 Apr 26, 2023 Yes

Oh Ken I really like this! I think that is a really good snapshot and has extra info that people are going to want to know about

Took the idea from openff-forcefield. I thinks it flexible and extensible. We could add zenodo links to inform what datasets were used to train the model.

I really like that idea, @kntkb . I would just add the ⚠️ and ✅ (or some kind of visual aid as possible). I think it helps finding the information much quicker if we do something like that.

Okay, adding Ken's table (and some emoji). I will track down the DOIs. I will also add a note explaining that espaloma-0.3.1.pt is the same as espaloma-0.3.2.pt

Looks like zenodo wasn't turned on for espaloma, so I will add in the DOI after we make our release (zenodo gives you a DOI when you make a release, so I will make a PR after we make the release to update the README)

Okay this is what it is looking like now