stoped during the iteration in 26 more often as two peoples mentioned in a previous topic

[zhiqiang chen]

Hi Robert,

I am running STITCH in Linux, the script worked well at the first few iterations, but it suddenly stopped in the middle of iterations. 

below are my scripts and the error messages. Do you know the reason? 

/crex/proj/uppstore2017145/V3/users/chen/bin/STITCH/STITCH.R --method=pseudoHaploid \
--chr=$fout \
--regionStart=1 \
--regionEnd=10000000 \
--buffer=100000 \
--switchModelIteration=38 \
--niterations=40 \
--bamlist=/crex/proj/uppstore2017145/V3/users/chen/bin/STITCH/bamlist.KAW1063_new.txt \
--posfile=pos.tabulated.txt \
--outputdir=$outputdir_diff_k \
--K=$2 --nGen=100 --nCores=16

[2023-04-14 10:03:54] Start of iteration 26
[2023-04-14 10:04:04] Error in forwardBackwardHaploid(sampleReads = sampleReads, eHapsCurrent_tc = eHapsCurrent_tc,  :
  Mat::operator(): index out of bounds

Error in check_mclapply_OK(single_iteration_results) :
  An error occured during STITCH. The first such error is above
Calls: STITCH -> completeSampleIteration -> check_mclapply_OK
In addition: Warning message:
In mclapply(sampleRanges, mc.cores = nCores, FUN = subset_of_complete_iteration,  :
  all scheduled cores encountered errors in user code
Execution halted

I also saw the same error messages in a previous discussion topic. But I did not see an answer from you. Could you explain a little bit?

Cheers

Zhiqiang

[zhiqiang chen]

# continue to previous errors 

See below, I am wondering what is the split reads , average N=510. From iteration 25 to 26, it take almost 6 hours. Could be the cause of error produced?

[2023-04-14 01:46:05] Refill infrequently used haplotypes - on average, 24.1% of regions replaced
[2023-04-14 01:46:06] Start of iteration 19
[2023-04-14 02:08:01] Start of iteration 20
[2023-04-14 02:30:08] Start of iteration 21
[2023-04-14 02:52:12] Start of iteration 22
[2023-04-14 03:14:23] Start of iteration 23
[2023-04-14 03:36:55] Start of iteration 24
[2023-04-14 03:59:21] Start of iteration 25
[2023-04-14 10:03:53] Split reads, average N=510 (0.307 %)

[2023-04-14 10:03:54] Start of iteration 26
[2023-04-14 10:04:04] Error in forwardBackwardHaploid(sampleReads = sampleReads, eHapsCurrent_tc = eHapsCurrent_tc,  :
  Mat::operator(): index out of bounds

Error in check_mclapply_OK(single_iteration_results) :
  An error occured during STITCH. The first such error is above
Calls: STITCH -> completeSampleIteration -> check_mclapply_OK

[Robbie Davies]

Hi,

Sorry for the late reply. I believe I just replied privately, but to give the answer greater visibility, here is what I said. 

This is likely a bug in STITCH. By default, on the 25th iteration, STITCH tries to find really long reads that would be better modelled if they were split in two, reflecting heuristic difficulties / true recombinations that are otherwise hard to model. However I have seen errors like these before and haven't had the time / data to properly debug it. 

My recommendation is to turn this feature off by setting for instance splitReadIterations to -1. 

Sorry about this and best wishes,

Robbie

--
You received this message because you are subscribed to the Google Groups "STITCH imputation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stitch-imputat...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stitch-imputation/d3767742-ac5d-487f-8b51-fd5711801d79n%40googlegroups.com.

[zhiqiang chen]

Hi Robert,

Thanks for your suggestions. It works now. But, my new run comes with a new error for memory from iteration 38 using the method "pseudoHaploid" to iteration 39 using the method "diploid". Is there any suggestion for solving this error, except for running with a smaller genome region?    

My script is running under 20 cores, and 256G RAM. Is this related to the R version or any other things?

#*******************

[2023-04-18 10:30:43] Switching from pseudoHaploid to diploid - iteration 39
[2023-04-18 10:30:43] Start of iteration 39
[2023-04-18 12:13:06] Error : cannot allocate vector of size 10.9 Gb

Error in check_mclapply_OK(single_iteration_results) :
  An error occured during STITCH. The first such error is above
Calls: STITCH -> completeSampleIteration -> check_mclapply_OK

In addition: Warning messages:
1: In mclapply(1:length(sampleRanges), mc.cores = nCores, FUN = loadBamAndConvert_across_a_range,  :
  scheduled core 1 did not deliver a result, all values of the job will be affected
2: In mclapply(sampleRanges, mc.cores = nCores, FUN = subset_of_complete_iteration,  :
  scheduled cores 1, 3, 4, 6, 7, 8, 10 did not deliver results, all values of the jobs will be affected
3: In mclapply(sampleRanges, mc.cores = nCores, FUN = subset_of_complete_iteration,  :
  scheduled cores 2, 11, 5, 9 encountered errors in user code, all values of the jobs will be affected
Execution halted. 

Cheers

zhiqiang

[Robbie Davies]

Hi,

This bit 

Error : cannot allocate vector of size 10.9 Gb

means you ran out of RAM. The diploid switch makes the algorithm use a lot more RAM with higher K (the diploid method uses RAM proportional to the square of K, while the pseudoHaploid uses RAM linear in K).

My suggestion would be to run with fewer cores, while retaining the same amount of RAM. 

Best,

Robbie

To view this discussion on the web visit https://groups.google.com/d/msgid/stitch-imputation/a3726ce6-8f9c-4800-8c02-347b579fe27cn%40googlegroups.com.