Provided: patch for big-endian support

[pc297]

star_big_endian_saindex_git.patch

STAR-master-bigendian-saindex-patched.zip

Logs.zip

Hi Alex,

Following up on our previous discussion regarding big-endian support, I spent some time investigating the error:

"BUG: next index is smaller than previous, EXITING"

I traced the failure from genomeSAindex.cpp through the suffix-array index generation code and identified several endian-sensitive code paths. With the help of ChatGPT, I examined additional code involved in packed-array and suffix-array handling and produced a patch addressing a number of little-endian assumptions in:

• SuffixArrayFuns.cpp
• PackedArray.{h,cpp}
• Genome_genomeGenerate.cpp

I tested the patch on Debian ppc64 (big-endian) systems.

Validation performed:

• Successful --runMode genomeGenerate on the STAR bacterial test genome.
• Successful alignment using the STAR bacterial test FASTQ files.
• samtools flagstat reported expected alignment statistics (100% alignment on the bacterial test dataset).
• Successful --runMode genomeGenerate on mm10 (sjdbOverhang 99).
• Successful alignment using the mm10 index and the publicly available mouse RNA-seq test dataset:
  https://zenodo.org/records/4249555

The initial testing was performed on a Quad G5 (PowerPC 970MP) running Debian ppc64 (big-endian). The bacterial tests completed successfully on this machine. However, mm10 index generation and alignment proved to be memory-limited on the G5 platform (28 GB RAM available max although I am hoping to get that up to 32 GB).

To validate operation on a large genome, I then ran the same ppc64 big-endian binaries on a POWER8 server running Debian ppc64 (big-endian) with 128 GB RAM. Using the same binaries compiled on the G5, mm10 genome generation and alignment completed successfully, suggesting that the remaining limitation on the G5 was memory capacity rather than correctness.

The resulting alignments appeared correct on inspection, and samtools flagstat produced expected mapping statistics.

The patch and patched source tree are attached for review and further testing:

• star_big_endian_saindex_git.patch
• STAR-master-bigendian-saindex-patched.zip

Although most modern POWER Linux installations now use little-endian mode (ppc64le), this patch may still be of interest for users of older big-endian POWER systems (POWER6/POWER7 and earlier), as well as potentially for current s390/s390x (IBM Z/LinuxONE) systems, which remain big-endian architectures.

I have not had access to s390x hardware for testing. If anyone in the community has access to an IBM Z/LinuxONE system and would be interested in testing the patch, I would be very interested to hear the results.

Many thanks again for STAR and for the previous discussion that helped narrow down the source of the issue.

Best regards,

Pierre Cauchy

[Scottcjn]

Independent big-endian confirmation — Power Mac G5 (PowerPC 970, Mac OS X 10.5.9).

Built your patched STAR on a different big-endian PowerPC system from your Quad-G5/POWER8 Debian setup — a Power Mac G5 running Mac OS X 10.5.9 (Darwin/PowerPC, big-endian), GCC 10.5. Two Mac-specific build tweaks were needed, both unrelated to your byte-order patch: build opal with CXXFLAGS_SIMD= (drops the x86 -mavx2; opal's bundled SIMDe provides the portable path on PowerPC), and a #define SHM_NORESERVE 0 guard (Mac's SysV shm lacks it — STAR already has this under COMPILE_FOR_MAC).

Results with your patch:

• --runMode genomeGenerate: completes successfully — no "BUG: next index is smaller than previous, EXITING". Suffix Array index built and validated, SA/SAindex/Genome written, "finished successfully".
• Alignment: 1000 exact 50 bp reads sampled from the generated genome → 100% uniquely mapped, 0 unmapped, each read placed at its exact source coordinate (e.g. read1 → testchr1:279499 50M, MAPQ 255). On an unpatched big-endian build the suffix array is wrong, so this is a good end-to-end check that your fix produces a correct index.

So the patch holds up on a second, independent big-endian PowerPC platform. Thanks for tracking this down — nice work on the PackedArray/SuffixArrayFuns byte-stream fix.

[Scottcjn]

Second independent big-endian confirmation — native POWER8 (ppc64 BE), Linux/musl.

Following the Power Mac G5 result above, I rebuilt and re-ran your patch on a completely different big-endian platform: a native big-endian POWER8 LPAR (IBM POWER8, pSeries) running Adélie Linux (musl libc), gcc/g++ 13.3.0 — different CPU generation, OS, libc, and compiler from both your setup and the G5.

Build is clean (STAR 2.7.11b, ELF 64-bit MSB PowerPC, OpenPOWER ELF V2 ABI). Three small fixes were needed for the minimal musl environment, all orthogonal to your patch (noting them in case they help others building on musl):

• Adélie ships the C++ frontend separately → apk add g++
• no xxd in the base image → pre-generated parametersDefault.xxd
• source/SharedMemory.h uses SysV-IPC key_t but doesn't include <sys/ipc.h>/<sys/types.h>/<sys/shm.h> — glibc pulls these in transitively, musl does not. Adding the includes fixes it (could be worth a follow-up portability patch).

Test (20 kb reference, 1000 × 100 bp reads generated from known positions):

... completed Suffix Array index ... finished successfully     # no "next index is smaller than previous" BE failure
Number of input reads                 | 1000
Uniquely mapped reads number          | 1000
Uniquely mapped reads %               | 100.00%
Number of reads mapped to multiple loci | 0
Number of reads unmapped: too short   | 0

Coordinate check: every sampled read maps to its exact source position (e.g. read at pos 10541 → SAM POS 10541, 100M, MAPQ 255), 0 mismatches.

So the patch now has two independent native-BE reproductions on different hardware/OS/toolchain — Power Mac G5 / Darwin / gcc 10 and POWER8 / Linux-musl / gcc 13. Suffix-array generation is correct and alignment coordinates are exact on both. 👍

[pc297]

Thanks a lot for trying it out and glad it could be reproduced on both G5 and POWER8 BE platforms!

Yes on the G5 I built it successfully on debian ppc64 (big endian) using any of the following on gcc 14.2.0-9:

make STAR -j4
make STAR CXXFLAGS_SIMD="-mcpu=970 -maltivec" -j4
make STAR CXXFLAGS_SIMD="-03 -ftree-vectorize -mcpu=970 -maltivec -mabi=altivec -DSIMDE_ENDIAN_FORGE_BIG" EXTRA_FLAGS="-m64" LDFLAGSextra="-m64" -j4

all three versions could successfully build the SA from the test fasta (from debian):

./STAR --runThreadN 4 --runMode genomeGenerate --genomeDir . --genomeSAindexNbases 8 --genomeFastaFiles foo.fa --sjdbGTFfile  ./foo.gtf

On POWER8 I used the following on debian ppc64 (big endian):

make STAR -j64
make STAR CXXFLAGS_SIMD="-mcpu=power8 -maltivec -mvsx" -j64

both versions could successfully build the SA from the mm10 fasta using:

./STAR --runThreadN 64 --runMode genomeGenerate --genomeDir ./mm10 --genomeFastaFiles ./mm10/mm10.fa --sjdbGTFfile ./mm10/mm10.refGene.gtf --sjdbOverhang 99

My alignment test command on the G5 (bacterial reads, single-end):

./STAR --runThreadN 4 --genomeDir . --readFilesIn reads.fastq

My alignment test command on the POWER8 (mouse reads, single-end):

./STAR --runThreadN 64 --genomeDir mm10 --readFilesIn ~/SRR1552444.fastq.gz --readFilesCommand  zcat

My samtools flagstat on the debian test fastqs on the test bacterial genome on the G5:

1185 + 0 in total (QC-passed reads + QC-failed reads)
979 + 0 primary
206 + 0 secondary
0 + 0 supplementary
0 + 0 duplicates
0 + 0 primary duplicates
1185 + 0 mapped (100.00% : N/A)
979 + 0 primary mapped (100.00% : N/A)
0 + 0 paired in sequencing
0 + 0 read1
0 + 0 read2
0 + 0 properly paired (N/A : N/A)
0 + 0 with itself and mate mapped
0 + 0 singletons (N/A : N/A)
0 + 0 with mate mapped to a different chr

My samtools flagstat on SRR1552444.fastq.gz (https://zenodo.org/records/4249555) using large genome settings (mm10) on the POWER8:

8221 + 0 in total (QC-passed reads + QC-failed reads)
8151 + 0 primary
70 + 0 secondary
0 + 0 supplementary
0 + 0 duplicates
0 + 0 primary duplicates
8221 + 0 mapped (100.00% : N/A)
8151 + 0 primary mapped (100.00% : N/A)
0 + 0 paired in sequencing
0 + 0 read1
0 + 0 read2
0 + 0 properly paired (N/A : N/A)
0 + 0 with itself and mate mapped
0 + 0 singletons (N/A : N/A)
0 + 0 with mate mapped to a different chr
0 + 0 with mate mapped to a different chr (mapQ>=5)

I also verified that the unpatched STAR binary cannot use a genome index generated on x86_64. This indicates that the issue is not limited to suffix-array generation, but also affects reading and interpretation of the stored index. Accordingly, the patch also updates the endian-sensitive packed-array and suffix-array handling (PackedArray.{h,cpp} and SuffixArrayFuns.cpp)

Some of what remains to do:

1. Test bam output functionality using

--outSAMtype BAM SortedByCoordinate

2. Test on a much larger dataset (e.g. full mouse bulk RNA-Seq)
3. Test low-memory SA generation for large genomes on e.g. the G5 with 16 GB RAM using

--genomeSAsparseD 3 \
--genomeSAindexNbases 12

4. Test paired-end functionality
5. Some benchmarking to determine whether the endianness fix induces cycle penalties, this should be done on a large dataset (e.g. mouse) and compare alignment time on a similar LE (x86_64) configuration
6. Test on other BE platforms, e.g. s390/s390x/IBM-z
7. md5sum the SA on BE and compare it to an SA made from a same fasta file on LE (x86_64)
8. Test whether the BE alignment mode works correctly with an SA made on LE (x86_64) for the sake of index portability

Many thanks for confirming in any case!