Spaces:
Running on Zero
Running on Zero
Commit History
6 days ago
-
Report the sites the cutoff rejected, instead of nothing Running
Feedback from a reviewer: running INS and IAPP found no alternative reading frames, and they guessed the missing ribosome-profiling data was the reason. It is not. Scored down to 0.0005 on held-out folds, those two transcripts contain four sites in total -- the two annotated starts, an in-frame INS N-truncation at 0.0037 and an IAPP 3'UTR ORF at 0.0008. Nothing in another frame registers at all. The model looked and said no. The UI gave no way to tell those two stories apart, so every run now scores down to a floor of 0.0005 whatever cutoff is set, and the rejected sites are listed in their own tab with the best one quoted under the funnel. Same work for the model; an empty result now carries its own evidence. Adds IAPP as a fourth example (chr12, fold 3) and says plainly in the app and the README that a near-zero score is the model's prior, not a missing input. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>c357a0a -
Replace examples with ones that show where the model actually fails
The old set (INS, TYK2, ACTB) returned nothing but canonical starts at the default cutoff, so the demo opened on an empty result and ACTB earned its place only as a negative control the others already provided. Running validated non-canonical ORFs through the model gives a sharper finding than "it only finds canonical starts", which was wrong: MIEF1 upstream ORF 70 aa 0.674 found, outranks the canonical ATF4 uORF2 59 aa 0.303 found HOXB-AS3 peptide 53 aa 0.000892 missed TYK2 uORF 8 aa 0.000038 missed ATF4 uORF1 3 aa 0.000044 missed Sensitivity tracks ORF length, not whether the start is canonical. ATF4 is the controlled case: both uORFs sit in the same 282 nt leader, 99 nt apart, and the 3 aa one is invisible despite a textbook Kozak context. That matters because microproteins are short by definition, so the model loses sensitivity exactly in the regime this project is about. It is also fairer to the tool, w…fc30842
9 days ago
-
Score each example on a fold that held out its chromosome
The demo ran everything on fold 0, whose test set is empty, so it scores any chromosome including ones it trained on. INS (chr11), TYK2 (chr19) and ACTB (chr7) are all in fold 0's training set. The tool warns about this at runtime, but the warning is buried in the log. Re-running each gene on a fold that excluded its chromosome (TYK2 on 3, INS and ACTB on 4) shows the leakage is worth about +/-0.06: canonical starts score 0.889-0.985 held out versus 0.944-0.965 on fold 0. So the model does generalise on canonical starts, which is fair to report. The headline finding survives and is now defensible. On fold 3, with chr19 never seen, the validated TYK2 uORF at position 186 scores 0.000038 against 0.984922 for the canonical start in the same transcript, roughly 26,000x. At the default cutoff the model now proposes only the three annotated starts and nothing non-canonical at all. Updates the README numbers, adds a section on choosing a fold, and spells out the per-example folds in the UI…0e84302 -
Pin MHCflurry to CPU so ZeroGPU does not reject it
The reported failure was not the TIS stage, which ran fine on GPU and returned the expected 4 sites. It was MHCflurry: class1_processing_neural_network.py:1565 network.to(device) torch._C._cuda_init() RuntimeError: Low-level CUDA init reached. ZeroGPU's PyTorch CUDA emulation mode did not intercept a CUDA operation in your code. MHCflurry 2.3 is a PyTorch model whose device defaults to "auto", so on a GPU box it moves its network to CUDA during prediction. That call happens in the Gradio worker thread, outside any @spaces.GPU function, and ZeroGPU refuses it. The GPU allocation belongs to TIS Transformer. MHCflurry scores tens of thousands of peptides in seconds on CPU, so configure_pytorch(backend="cpu") costs nothing and removes the conflict. Only `backend` is set; the sibling option gpu_device_nums=[] would set CUDA_VISIBLE_DEVICES process-wide and break the TIS stage that currently works. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>ad07374 -
Fall back to CPU when the GPU path fails
The ZeroGPU path was the one branch never exercised locally -- every test ran with TRISTAN_ACCELERATOR=cpu, which takes the subprocess route. It contained a real bug: _resolve_entrypoint() ran unconditionally, so the in-process path raised if the `tis_transformer` console script was not on PATH, even though that path drives main() directly and never needs it. Rather than just fixing that, make prediction degrade instead of failing. The GPU is attempted first where there is one, and any failure falls back to the subprocess CPU route, which is the tested one. On inputs this size CPU takes seconds, so there is no reason for a GPU problem to take the Space down. Both failures are reported together if neither works, so the next report is actionable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>dfc65a6 -
Correct the TYK2 uORF claim and sharpen what it shows
The earlier README implied the uORF this model predicts at position 214 is the one described in the literature. It is not. Walters et al. (doi:10.2337/db24-0527) characterise an 8 aa primate-specific uORF, MPGSVLNV, spanning the first two exons of the TYK2 5' leader, and validate it by mutating its start codon. Reading the sequence from their Figure 5C and matching it against ENST00000525621.6 places it at position 186. Our prediction at 214 is a different, longer, unvalidated ORF, out of frame with both the TYK2 CDS and theirs. Checking the raw per-nucleotide output at the validated position makes the point better than the original claim did: @186 published uORF (validated) 0.000000 @214 our 36 aa ORF 0.002004 @378 canonical CDS 0.944035 The model scores a functionally validated beta-cell uORF at zero, and the highest score anywhere in the 378 nt leader is 0.002. It misses what is known to be real and ranks what it does find too low to act …3bedd9b -
Chain TIS prediction to epitope prediction end to end
Extends the Space from a single-model wrapper into the full pipeline the collaboration proposal describes: sequence -> TIS Transformer -> ORF typing -> MHCflurry -> candidate peptides All three stages are existing, openly-licensed tools. MHCflurry (Apache-2.0) is used rather than NetMHCpan, whose academic licence forbids redistribution and so cannot be hosted. Verified against the installed package rather than the docs, which were wrong in ways that mattered: - The FASTA-path CSV schema differs from the documented h5/GTF one. The score column is `output`, not `tis_transformer_score` -- so the previous tidy() matched no column and the cutoff slider and sorting silently did nothing. - TIS_pos is 1-based; everything here is 0-based. The conversion lives in one named function because an off-by-one shifts every reading frame and still yields a plausible protein. - Weights ship inside the wheel, so there is no download to warm. - --start_codons defaults to near-cognate (.*TG$…5278136 -
fix read me
558539b -
run model
fe26600 -
initial commit
Verified signaturec4ce6c8