Summary
The README's install table for NEAR just says "install from official sources at the versions used in the paper" with a link to https://github.com/TravisWheelerLab/NEAR and no pinned commit, tag, or branch.
Cloning current NEAR (either main or the 2025_paper_evaluation branch NEAR's own README points to for reproducing paper results; I checked both) includes a hard minimum-sequence-length check in src/near_embed.py:
python def create_tensors_from_fasta(file_path, pad_power_two=False, min_seq_length=32, alphabet=None): ... if seq_length < min_seq_length: print(str(i) + ": Sequence is too small, ID=" + record.id) print("Terminating.") exit(-1)
I traced this back with git log: src/near_embed.py (the file containing this check) didn't exist in NEAR's history before a commit titled "2025 rework" (be47d37, 2025-01-24). So any version of NEAR from before that date wouldn't have had this check at all.
Impact
The real astral.fa (15,177 sequences) contains 127 sequences shorter than 32 residues (e.g. d1qcrd2, 29 residues). Running NEAR's target-DB build against the real, unmodified astral.fa hard-exits the moment it encounters the first one, so NEAR can't process the dataset as currently documented. Truncated variants (astral_trunchalf.fa, astral_truncqrt.fa) are affected even more, the 25%-truncation file loses 38.9% of its sequences to this same threshold, since truncating an already-borderline sequence pushes many more below 32.
Given PLMGuard's own repo history starts April 2026 (over a year after NEAR's rework), it's possible this slipped through because the actual experiments behind the paper used an older, pre-rework NEAR checkout that was never re-verified against the currently-documented install instructions.
Suggested fix
Would it be possible to pin an exact NEAR commit or tag in the README; ideally one from before the January 2025 rework, if that's closer to what the paper's original results were generated with? That would let anyone following the documented setup get a NEAR that can actually process the real dataset.
If the current NEAR is the intended target instead, it would really help to have a note about the min_seq_length constraint and how the paper's authors handled sequences below it (excluded? padded? a different dataset subset?), since neither the README nor run_near.sh currently mention it. Happy to help test or submit a PR if that'd be useful.
Summary
The README's install table for NEAR just says "install from official sources at the versions used in the paper" with a link to
https://github.com/TravisWheelerLab/NEARand no pinned commit, tag, or branch.Cloning current NEAR (either
mainor the2025_paper_evaluationbranch NEAR's own README points to for reproducing paper results; I checked both) includes a hard minimum-sequence-length check insrc/near_embed.py:
python def create_tensors_from_fasta(file_path, pad_power_two=False, min_seq_length=32, alphabet=None): ... if seq_length < min_seq_length: print(str(i) + ": Sequence is too small, ID=" + record.id) print("Terminating.") exit(-1) I traced this back with
git log:src/near_embed.py(the file containing this check) didn't exist in NEAR's history before a commit titled "2025 rework" (be47d37, 2025-01-24). So any version of NEAR from before that date wouldn't have had this check at all.Impact
The real
astral.fa(15,177 sequences) contains 127 sequences shorter than 32 residues (e.g.d1qcrd2, 29 residues). Running NEAR's target-DB build against the real, unmodifiedastral.fahard-exits the moment it encounters the first one, so NEAR can't process the dataset as currently documented. Truncated variants (astral_trunchalf.fa,astral_truncqrt.fa) are affected even more, the 25%-truncation file loses 38.9% of its sequences to this same threshold, since truncating an already-borderline sequence pushes many more below 32.Given PLMGuard's own repo history starts April 2026 (over a year after NEAR's rework), it's possible this slipped through because the actual experiments behind the paper used an older, pre-rework NEAR checkout that was never re-verified against the currently-documented install instructions.
Suggested fix
Would it be possible to pin an exact NEAR commit or tag in the README; ideally one from before the January 2025 rework, if that's closer to what the paper's original results were generated with? That would let anyone following the documented setup get a NEAR that can actually process the real dataset.
If the current NEAR is the intended target instead, it would really help to have a note about the
min_seq_lengthconstraint and how the paper's authors handled sequences below it (excluded? padded? a different dataset subset?), since neither the README norrun_near.shcurrently mention it. Happy to help test or submit a PR if that'd be useful.