sokrypton / sokrypton/ColabFold
A possible bug in search.py
Nobody has claimed this yet.
- Dominant language
- Jupyter Notebook
- Stars
- 2.9k
- Forks
- 747
- PR merge metrics
- No merged PRs in 30d
Description
Hi All,
I've reading through search.py, I and I think there may be a bug when writing query fasta file when there are multiple jobs.
The current code will reset the id counter in each iteration of the outer loop, thus there will be multiple fasta entires named 101, 102, etc.
Perhaps this does not matter later in the code, but still might be nice to clean up (unless I'm somehow wrong)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Inspect colabfold/mmseqs/search.py around line 437, focusing on how the query FASTA is written inside the outer job loop. Run a multiple-job search or trace the generated FASTA entries to check whether identifiers repeat; done means confirming whether IDs must remain unique across jobs and documenting the observed behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- bioinformatics
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100