graylab / flab Goto Github PK
View Code? Open in Web Editor NEWFitness landscapes for antibodies
Fitness landscapes for antibodies
Looking at the data file in data/binding/Shanehsazzadeh2023_trastuzumab_zero_kd.csv
it appears that the HCDR3 sequences from https://github.com/AbSciBio/unlocking-de-novo-antibody-design/tree/main have been copied over but in place of trastuzumab's HCDR1 instead of its HCDR3.
For example the first heavy
entry is EVQLVESGGGLVQPGGSLRLSCAASTRYFFNGWYYFDVIHWVRQAPGKGLEWVARIYPTNGYTRYADSVKGRFTISADTSKNTAYLQMNSLRAEDTAVYYCSRWGGDGFYAMDYWGQGTLVTVSS
The designed HCDR3 TRYFFNGWYYFDV
has been swapped for trastuzumab's HCDR1 (GFNIKDTY
) and trastuzumab's HCDR3 (SRWGGDGFYAMDY
) is still present.
For the Koenig and Warszawski sets, I have been trying to find out what the fitness values actually represent. They are surely not KD values in nM as labeled. At least for the Koenig set, your 'fitness' seems to be positively correlated with binding affinity (unlike KD) so then I find myself confused by why the correlations with affinity were calculated with -np.log(fitness) - this seems like the wrong direction at least for the Koenig binding affinity data. I'll justify this in the third paragraph based on sanity checks from the Koenig manuscript data.
Rows for the wildtype do not exist in your csvs. I noticed that something called 'wildtype' was somehow plotted in some deleted plots in the commit history. However, in the plots that show wildtype against the rest, the thing labelled 'is_first_row' is deemed wildtype in the plots, but the sequence is clearly not actually the wildtype sequence. See the PDB fastas and code, csvs, plots I attached here that are pulled from this commit: 39fec5a. "wildtype" is not the correct wildtype, just seems like some mutated sequence labelled as wildtype. The wildtype sequences for Koenig:G.6.31 and Warszawski:D.44.1 can be inferred from looking at the different mutants or by looking at the respective PDB fastas (Koenig: https://www.rcsb.org/fasta/entry/2FJF/display, Warszawski:https://www.rcsb.org/fasta/entry/1MLC/display). The wildtype affinity values are supposed to be 0.36/0.4 nM for G.6.31 and 135/137 nM for D.44.1 (the stated values vary a bit even within the publications).
Based on the plot in the Koenig paper, the wildtype affinity (~0.36nM KD) should sit between that of light chain mutants I106V (KD of ~0.3, fitness of 1.993) and F83S (KD of ~0.4, fitness of 1.6879). That should put the wildtype 'fitness' for Koenig G.6.36 somewhere around 1.8. As a further check, the Koenig paper says that the G.6.31 F83A light chain mutant is supposed to have a binding affinity 3x greater than the wildtype - so approximately KD of 0.12 nM. The fitness value provided for that entry is 5.689, which is one of the higher fitness values and also around 3x of 1.8 which I'm ballparking as the wildtype 'fitness'. Fortunately this all checks out so the relative rankings seem to make sense, but this 'fitness' definitely seems positively correlated with binding affinity. I wasn't able to find the full Koenig data online and the source seems to be the early commit from Jeffrey Ruffolo in this repo. If someone could provide the original source or find it online for me - I can try to get the data in actual KD form myself and make a contribution.
Then for Warzawski, the fitness is also clearly not KD in nM as labeled. If 'fitness' were actually equal to KD in nM, then the wildtype fitness of 135nM would either be the strongest or weakest binder of the whole set which is obviously not the case based on the manuscript. At least I can find the original log-enrichment data online, so I can try processing it myself.
I wasn't interested in the other sets so I haven't checked those yet. But for Koenig and Warszawksi sets, I would like to warn everyone that these 'fitness' values absolutely cannot be interpreted as KD values in nM as labeled. For Koenig they actually seem to correlate with binding affinity in the other direction from KD. The exact relationship of these fitness values to KD is unclear to me right now.
There's something way back in the commit history called "all model scripts, still need to fix W_kd, K_Kd, K_er" so there seemed to be awareness of these issues at some point - but the fitness values don't seem to have changed since then. It might have fallen off the radar, but I'd like to put this out there for anyone else who tries to use this data so they can be aware of the headaches in advance.
Here's some relevant attachments as support for my points:
Koenig2017_g6_Kd_ppl.csv
Warszawski2019_d44_Kd_ppl.csv
002_score.py.txt
Hi,
I believe that fitness
values in the Rosace et al. binding datasets were not scaled to nM and are expressed in M.
Cheers,
Ivan
When trying to run the README command:
sbatch sbatch/structure.sh data/tm/Hie2022_C143_Tm.csv
The input works as is of course because the supplied file has a fitness column. However, I can't see where those values are generated from. If I wanted to run my own heavy/light sequences through FLAb, how would I populate the fitness
column here?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.