Hello, Bastien!
I am not a sequence assembly expert, but we have been running a particular MIRA job for a customer that takes anywhere from 16 hrs to 44 hrs to complete on a system with 512GB of memory. The job itself uses only 80GB of memory + 200GB of buffer cache. We are using the mira_4.0.1_linux-gnu_x86_64_static binary.
Attached are two of the mira_info_assembly.txt files (which show slight differences), and also a mira_info_WARNINGS_critical.txt file (which is otherwise identical in both runs). The mira_info_WARNINGS_medium.txt and mira_info_WARNINGS_minor.txt files are empty. Also attached is the manifest.conf file.
My question is, do you think this run time variability is due to the inherent statistical/threaded nature of MIRA, or do you think it could be computer hardware related? Unfortunately I haven't been able to get a profiled binary to run to completion. Thank you so much for any insights you have!
-- Haruna :)
While differences in run time are to be expected, having runs between 16 and 44 hrs is a bit too much of a variation for my liking. Was MIRA always the only process on the machine? If yes, one might want to make a side by side comparison of run times (in the output log) of the most critical steps within the process to see whether one can pinpoint critical points where things start to diverge.
Thank you, Bastien, for your reply! Yes, MIRA was the only process running. I am currently looking at all of the time stamps like you suggested. Interestingly, the number of time stamps in each log file is different...the longer the elapsed time, the fewer the time stamps! Thank you again, and please let me know if any other ideas come to mind. I will keep you posted as well. I imagine most users do not run the same assembly over and over again like this. ;)
It looks like the timing difference occurs in the part of the code with the attached output. In a slow run, it first takes about 25 seconds, but for some reason it starts to take about 45 seconds, and towards the end it takes about 54 seconds. There are enough of these that when you add them all up, then it makes a large difference in the end, compared to a fast run where this part of the code always takes about 25 seconds. Any insights as to why this might be happening in this part of the code? I'll start digging into the source next. Thank you, Bastien!