This is very good to know. It makes sense.
Since I do not have access to an HPC using SLURM or others..., I'm wondering whether I should use AWS.
(I was initially planning to run the first part of juicer (till the .hic file) on the LSF and then run HiCCUPS on AWS)
Are the updates made to juicer.sh (for other versions than the LSF one) slightly (or drastically) improving the calling of the loops or are they just removing some minor bugs or speeding up the processing?
Could the quality of the results of my analyses be improved if I used a more recent version of juicer (better sensitivity or resolution...)?
If I correctly understood your last answer, juicer.sh can process multiple fastq files from different sequencing runs corresponding to the sample (batch1_R1.fastq.gz, batch1_R2.fastq.gz, batch2_R1.fastq.gz, batch2_R2.fastq.gz, batch3_R1.fastq.gz, batch3_R2.fastq.gz, ...) and create one .hic file with all the data combined, while mega.sh can combine hic files from different replicates of the sample.
For example, now I have 1.2 billon reads for one sample spit into 9 distinct fastq files (18 total with the R1 an R2). Juicer.sh will automatically analyze all the 9 fastq files and give me one .hic file. At this stage, I won't need to use mega.sh.
But if a bit later, I decide to get Hi-C data from the same sample but at a different cell passage, get another 1.2 billion reads split into multiple fastq files, combine the data into one .hic file, then if I want to merge this latter .hic file with the previous .hic file, then I would have to run mega.sh to combined these two .hic files.
Am I correct?
Thank you very much in advance!
Best,
Etienne