Choice of ligands in the repo

[annamherz]

Hello! I'm going to be running a benchmark with the p38, mcl1 and tyk2 ligands. Looking at the ligands available in this repo, I've noticed that some of the ligands are not included when compared to those included in the JACS 2015 benchmark paper, and I was wondering why? I've read through section 4.2 in the paper but was wondering if there was more specific documentation for why each specific ligand that was not included was omitted in this repo?

Thank you!

[nonsensejoke]

For MCL1 system, the ligands which are missing SDF in this repo have aromatic ring that can take two conformations. I guess this could complicates the FEP simulation.

[ijpulidos]

Apologies for such a late response on this. You are correct at pointing out that the ligands in the repo don't correspond exactly to the ones in the JACS paper. For that we suggest you use the release 0.2.1.

The reason that these ligands are now not in the dataset is because we have detected some issues with them. The discussion around it can be seen in #52 if that helps.

[greglandrum]

Apologies for such a late response on this. You are correct at pointing out that the ligands in the repo don't correspond exactly to the ones in the JACS paper. For that we suggest you use the release 0.2.1.

The reason that these ligands are now not in the dataset is because we have detected some issues with them. The discussion around it can be seen in #52 if that helps.

For what it's worth, I also just got bit by this. We were looking to access the data used for @dfhahn's "Current State of Open Source Force Fields in Protein−Ligand Binding Affinity Predictions" paper and noticed all the missing targets.

Finding the discussion(s) of when/why ligand sets were removed requires searching both through issues and PRs and isn't necessarily trivial. Would it be possible to put something at the top of the README pointing people to the release if they are trying to reproduce the previous work?

[IAlibay]

Would it be possible to put something at the top of the README pointing people to the release if they are trying to reproduce the previous work?

This repo is used for several different publications / works and is meant to be a living resource that updates through time. I'm not necessarily sure it makes sense for the repo to have a comment at the top of the readme that specifically singles out a single paper. Ideally the release artifact should have been linked through in the paper itself.

If folks feel otherwise, then maybe we should just archive this repo and start again future efforts at updating the PLB elsewhere.

[greglandrum]

Would it be possible to put something at the top of the README pointing people to the release if they are trying to reproduce the previous work?

This repo is used for several different publications / works and is meant to be a living resource that updates through time. I'm not necessarily sure it makes sense for the repo to have a comment at the top of the readme that specifically singles out a single paper.

That's a good point. If your goal is a living repository, then having specific info for a few papers at the top doesn't really make sense. Suggestion withdrawn. :-)

Ideally the release artifact should have been linked through in the paper itself.

They actually did mention the version, but they didn't link to it. It was user error on my part to just go to the repo and not the appropriate tag.

[IAlibay]

I will say the initial causes of this issue (and further confusions) are valid and we do need to address them. The current status of main is really unclear and possibly shouldn't reflect a "work in progress" (unless we make it clear in docs that it's the case).

We definitely should have docs that says "if you're looking for a sepcific version, click through to the relevant tag".

[davidlmobley]

We could ask @dfhahn about whether he's amenable to submit an erratum to the paper that points to the relevant release here to alleviate confusion.