Input CSV about cinnabar HOT 6 CLOSED

John also sent me some references about 'best reasonable guesses' for what the experimental errors are likely to be, in the absence of having no experimental uncertainty. I will look at making both of these changes in the near future.

• read in the exp values as node properties (will need to change in wrangle)

• turn these into edge properties

• write a module that estimates experimental uncertainty

from cinnabar.

This would reduce the chance of non-consistent experimental DDGs, and we could just add more columns for more additional compt. methods to plot?

Would you allow for more columns in the CALC plot or would you allow more than one CALC block?

from cinnabar.

For the conversion from DGs to DDGs, also for their errors and from different observables (IC50, pIC50, and Ki), we could make use of the PLBenchmark repository.
It's all implemented there. What we still would need is an estimator for the experimental uncertainty (although these are almost always reported).

from cinnabar.

Would you allow for more columns in the CALC plot or would you allow more than one CALC block?

Don't really have a strong opinion. Maybe replicas could be intra-block and different methods could be new calc blocks?

Thanks for the PLBenchmark pointer, what specifically do you mean is in there which is helpful for error estimating? Would you mind pointing to the file/function that handles it? I can figure out what values John said were appropriate for experimental uncertainties.

from cinnabar.

Don't really have a strong opinion. Maybe replicas could be intra-block and different methods could be new calc blocks?

Seems good to me.

The DDG (and associated error) calculation from the DG values is done in here: https://github.com/openforcefield/PLBenchmarks/blob/add_code/PLBenchmarks/edges.py
The conversion from different units is handled in here: https://github.com/openforcefield/PLBenchmarks/blob/add_code/PLBenchmarks/utils.py
(in the convertValue and convertError functions)

from cinnabar.

Ok, so I realised doing this meant that we could only ever do this if we had experimental absolute values, which we might not want to be trapped with - what if we want to compare one relative method vs another relative method?

I liked csv file to start with because they are so easy, but what if we went to a yaml... therefore if we have absolutes, we can add them, if we don't then we can just add relative values

absolute:
  name: CAT-13a
  dg: -8.83

absolute:
  name: CAT-13b
  dg: -9.83
  ddg: 0.40 # this is optional, if it's not set we can make a reasonable approximation?

relative:
  ligandA: CAT-13a
  ligandB: CAT-13b
  ddg: 1.10
  ddg_err: 0.45
  method: perses-repex # this could be optional, but we could then have a file with perses/gromacs/schrodinger/amberti all in the same file.


# if we have a repeat it just be an additional entry

relative:
  ligandA: CAT-13a
  ligandB: CAT-13b
  ddg: 1.70
  ddg_err: 1.30
  method: perses-repex # this could be optional, but we could then have a file with perses/gromacs/schrodinger/amberti all in the same file.

from cinnabar.