Closed LucaYoy closed 1 year ago
@as2457 @NicholasSynesi
help! I am receiving this error on HPC when trying to run my script. I have memory put to 10g on the sh file and then I put it to 20g, but it still kills my jobs... @NicholasSynesi what did you put your mem to ?
@Luca, did what N are you using?
Did you try running a script on your laptop to see how much RAM it is using as a test? It might just take a lot...
Can you also send a screenshot of the shell script? Did you make sure that you have uploaded the latest version to the HPC?
@as2457 I'm using N=14. I have run it on my PC for N=6 and everything seemed fine, I'm not sure how to check RAM on my pc plus how do I check for N=14? Or do I check for 6 and then scale that exponentially to 14?
@LucaYoy Just try run it for N=14 on your laptop. You can try building up with N=10, 12, 14 (in case you run into memory issues on your laptop). While the script is running, you can check the memory usage in activity monitor. Se the number of iterations high enough that you have time to check.
@as2457 @NicholasSynesi N = 14, M = 5 , sweeps = 10000. Not sure how to read this, im not sure which memory section is the one relevant for HPC
Update: Ramped up memory to 40GB still getting my jobs killed
@LucaYoy something doesn't look quite right. Can you send a screenshot of the shell script as well?
@as2457
The script is killed when it reaches the approxSateRand line (line 19)
@LucaYoy @NicholasSynesi if you make sure GitHub is up to date and let me know which are the files to run on HPC I'll take a look tomorrow morning to figure it out.
@as2457 everything is pushed on the 43-investigate-optimisation branch, the HPC scripts are placed in HPC folder and im planning to run the main.py files using the sh script. Have a nice rest of weekend!
@LucaYoy @NicholasSynesi I found out the issue and pushed the fix to the branch.
Basically, there were two things:
Note:
I think you can now try on HPC, and probably get away with 1G (to be safe), or even as low as 200M RAM.
Just to make a note of my findings: Everything on my end seems to be fine, apart from the fact that I highly underestimated how long the scripts would take for additional layers. When I was running a few scripts in the meeting, it was for 3 layers. Pushing it up to 5 layers, even for 8 qubits the rates I'm getting for 8 qubits are 1000 iterations per 30 seconds, which is of course fine.
I managed to get 10 qubits 5 layers 20,000 sweeps working which ran overnight. However for 14 qubits I don't think it's feasible. Doing a test on my laptop for n=14 m=5, 10 sweeps (yes, 10) has just taken 12 minutes, so it would take about 2 and a half weeks for this to run! I'm going to assume to push the number of qubits down to 12, which does seem doable (on my laptop I'm predicting 12 hours per 20,000 sweeps), and keep everything else the same as discussed in the meeting.
@NicholasSynesi yes, it sounds sensible to start with N=12. You can then always try push to N=14 once you have these results.
Note, I don't think the scaling will be as bad as you think. For 10 sweeps I am sure most of that 12 minutes will be setting up the Hamiltonian and finding the ground state. Try this again with the sparse ExactDiagSparse function I added to Luca's code. I was able to run 400 iterations in a few seconds.
@LucaYoy I found another issue with your code. Don't use param.values(). Since all of the variables except run is the same for all, just set them statically. E.g.
N = 14 j = 1 h = 1 g = 1 M = 3 maxIterations = 200 run = which + 1
If the variable does depend on the job in the array, then set it with N = param["N"]
Oh yeah the new exact diagonalization method was definitely what was taking the most time, I should be able to get 14 qubits working now.
@as2457
which-1
, the sh file already has array 0-9 so 0 indexedparam.values()
also memory intensive just wondering@LucaYoy sorry you are right. You can just use which. My bad.
param.values() resulted in strange behaviour when I ran it. I don't think you can guarantee that a dictionary is ordered, so you should read them out using keys. Otherwise just use a list where you know the order of elements. Since you only change one thing at a time, I would just assign your variables individually.