SIGILL: 4 error

[MartinezRuiz-Carlos]

Hi all, I am running nanomonSV from the Docker container for a tumour region and matched normal of Nanopore long read data. The parse commands work well for both tumour and normal, but when I run the 'get' command I get the following output:

05/22/2023 17:32:33 - nanomonsv.run - INFO - Clustering rearrangement type supporting reads for putative SVs
05/22/2023 17:32:53 - nanomonsv.run - INFO - Clustering insertion type supporting reads for putative SVs
05/22/2023 17:47:18 - nanomonsv.run - INFO - Clustering deletion type supporting reads for putative SVs
05/22/2023 17:58:42 - nanomonsv.run - INFO - Clustering single breakend type supporting reads for putative SVs
05/22/2023 17:59:23 - nanomonsv.run - INFO - Gathering sequences of supporting reads
05/22/2023 18:15:50 - nanomonsv.run - INFO - Preparation for parallel execution
05/22/2023 18:15:50 - nanomonsv.run - INFO - Generate consensus sequences (0)
05/22/2023 18:15:50 - nanomonsv.run - INFO - Generate consensus sequences (1)
05/22/2023 18:15:50 - nanomonsv.run - INFO - Generate consensus sequences (2)
05/22/2023 18:15:50 - nanomonsv.run - INFO - Generate consensus sequences (3)
05/22/2023 18:15:50 - nanomonsv.run - INFO - Generate consensus sequences (4)
05/22/2023 18:15:50 - nanomonsv.run - INFO - Generate consensus sequences (5)
05/22/2023 18:15:50 - nanomonsv.run - INFO - Generate consensus sequences (6)
05/22/2023 18:15:50 - nanomonsv.run - INFO - Generate consensus sequences (7)
05/22/2023 18:15:50 - nanomonsv.generate_consensus - WARNING - Command '['racon', '-u', '/path/to_file.consensus_seq.0.txt.tmp_dir/chr1,103182548,103182575,+,chr1,103182549,103182576,-,i,25.supporting_read.fa', ''/path/to_file.consensus_seq.0.txt.tmp_dir/chr1,103182548,103182575,+,chr1,103182549,103182576,-,i,25.parasail.paf', ''/path/to_file.consensus_seq.0.txt.tmp_dir/chr1,103182548,103182575,+,chr1,103182549,103182576,-,i,25.tmp.seg.first.fa']' died with <Signals.SIGILL: 4>.

This goes on for a while, but basically the job finishes with no actual errors, just the died with <Signals.SIGILL: 4>., and generating an empty vcf file. I have tried increasing memory, to no avail, any ideas what might be causing this? Here is the code I ran:

singularity exec -B  "/nemo":"/nemo" $PWD/image/nanomonsv_v0.5.0.sif \
  nanomonsv \
    get \
    $PWD/results/LTX0388/LTX0388 \
    path/to_tumour.bam \
   reference/hg38.fa \
    --control_prefix $PWD/path/to_normal \
    --control_bam /path/to_normal.bam \
    --processes 8 \
    --single_bnd \
    --use_racon \
    --control_panel_prefix $PWD/control_panel/hprc_year1_data_freeze_nanopore_minimap2_2_24_merge_control/hprc_year1_data_freeze_nanopore_minimap2_2_24_merge_control

Many thanks!

[friend1ws]

Hi. We have encountered this error several times. We believe that this may have occurred because the CPU on which the image was built does not match the CPU on which the image is running. When we encountered this error, we built the docker image on an Intel CPU, turned it into a singularity image with a singularity pull and ran it on a node with an AMD CPU.

For example, one option would be to build a singularity image by yourself from the Dockerfile on your CPU. Or, you may try installing using conda.

[MartinezRuiz-Carlos]

Thank you for the quick response. I tried using the conda install, and it indeed worked past the SIGILL: 4 error. However, it lead to the following error:

Exception: module 'numpy' has no attribute 'int'.
`np.int` was a deprecated alias for the builtin `int`. To avoid this error in existing code, use `int` by itself. Doing this will not modify any behavior and is safe. When replacing `np.int`, you may wish to use e.g. `np.int64` or `np.int32` to specify the precision. If you wish to review your current use, check the release note link for additional information.
The aliases was originally deprecated in NumPy 1.20; for more details and guidance see the original release note at:
    https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations

I replaced all instances of np.int in the smith_waterman.py script (the only one where I saw it happening) and it is now running. I checked whether it could be a version clash, but I seem to be using the latest nanomonSV version (0.5.1) and numpy (1.24.3). If not a version clash I think this could be an easy to solve bug

Many thanks again!

[friend1ws]

Thank you very much and sorry for the late reply! I was mainly using the old version of Python. But when using 3.9, and upgrading numpy to 1.24.3, I could reproduce this bug. I included your suggestion in the code in the devel branch and a new version fixing this bug will be released very soon.