pyEPR icon indicating copy to clipboard operation
pyEPR copied to clipboard

analyze_all_variations not working with restricted number of modes

Open UlysseREGLADE opened this issue 4 years ago • 13 comments

Here is the description of the issue:

I have a simulation with 10 modes, and I would like to work only with 2 of them:

eprd.do_EPR_analysis(modes=[0, 8])

But, when I go to quantum analysis, by doing:

epra = epr.QuantumAnalysis(eprd.data_filename) epra.analyze_all_variations(cos_trunc = 8, fock_trunc = 15)

I get:

AssertionError Traceback (most recent call last) in 6 7 # Analyze ----> 8 epra.analyze_all_variations(cos_trunc = 8, fock_trunc = 15)

G:\Git\pyEPR\pyEPR\core_quantum_analysis.py in analyze_all_variations(self, variations, analyze_previous, **kwargs) 459 result[variation] = self.results[variation] 460 else: --> 461 result[variation] = self.analyze_variation(variation, **kwargs) 462 463 self.results.save()

G:\Git\pyEPR\pyEPR\core_quantum_analysis.py in analyze_variation(self, variation, cos_trunc, fock_trunc, print_result, junctions, modes) 681 PHI_zpf, 682 cos_trunc=cos_trunc, --> 683 fock_trunc=fock_trunc) 684 else: 685 f1_ND, CHI_ND = None, None

G:\Git\pyEPR\pyEPR\calcs\back_box_numeric.py in epr_numerical_diagonalization(freqs, Ljs, φzpf, cos_trunc, fock_trunc, use_1st_order, return_H) 64 65 Hs = black_box_hamiltonian(freqs * 1E9, Ljs.astype(np.float), fluxQ*ϕzpf, ---> 66 cos_trunc, fock_trunc, individual=use_1st_order) 67 f_ND, χ_ND, _, _ = make_dispersive( 68 Hs, fock_trunc, ϕzpf, freqs, use_1st_order=use_1st_order)

G:\Git\pyEPR\pyEPR\calcs\back_box_numeric.py in black_box_hamiltonian(fs, ljs, fzpfs, cos_trunc, fock_trunc, individual) 102 fs).any() == False, "freqs has NAN, this is NOT allowed! Fix me." 103 assert fzpfs.shape == (njuncs, n_modes), "incorrect shape for zpf array, {} not {}".format( --> 104 fzpfs.shape, (njuncs, n_modes)) 105 assert fs.shape == (n_modes,), "incorrect number of mode frequencies" 106 assert ejs.shape == (njuncs,), "incorrect number of qubit frequencies"

AssertionError: incorrect shape for zpf array, (1, 2) not (1, 10)

I there a work around ?

UlysseREGLADE avatar May 06 '20 13:05 UlysseREGLADE

Does it work when you try to analyze all the modes without the restriction?

DanielCohenHillel avatar May 06 '20 13:05 DanielCohenHillel

I got an other error, but I think this one is due to poor simulation convergence of non relevent modes. This is why I'm restricting my self to only two modes of interest. The error is a:

unsupported format string passed to Series.format, in the file core_quantum_analysis.py line 506

UlysseREGLADE avatar May 06 '20 13:05 UlysseREGLADE

Here is the complet error message:

TypeError Traceback (most recent call last) in 6 7 # Analyze ----> 8 epra.analyze_all_variations(cos_trunc = 8, fock_trunc = 15)

G:\Git\pyEPR\pyEPR\core_quantum_analysis.py in analyze_all_variations(self, variations, analyze_previous, **kwargs) 459 result[variation] = self.results[variation] 460 else: --> 461 result[variation] = self.analyze_variation(variation, **kwargs) 462 463 self.results.save()

G:\Git\pyEPR\pyEPR\core_quantum_analysis.py in analyze_variation(self, variation, cos_trunc, fock_trunc, print_result, junctions, modes) 648 # Get matrices 649 PJ, SJ, Om, EJ, PHI_zpf, PJ_cap, n_zpf = self.get_epr_base_matrices( --> 650 variation) 651 freqs_hfss = self.freqs_hfss[variation].values 652 Ljs = self.Ljs[variation].values

G:\Git\pyEPR\pyEPR\core_quantum_analysis.py in get_epr_base_matrices(self, variation, renorm_pj, print) 575 576 res = self._get_participation_normalized( --> 577 variation, renorm_pj=renorm_pj, print=print) 578 579 PJ = np.array(res['PJ'])

G:\Git\pyEPR\pyEPR\core_quantum_analysis.py in _get_participation_normalized(self, variation, renorm_pj, print) 504 if np.any(U_diff > 0.15): 505 logger.error(f"WARNING: U_tot_cap-U_tot_ind / mean = {U_diff*100:.1f}% is > 15%.'
--> 506 ' Is the simulation converged? Proceed with caution") 507 508 # global sums of participations

TypeError: unsupported format string passed to Series.format

UlysseREGLADE avatar May 06 '20 13:05 UlysseREGLADE

Thanks for submitting the issue, @UlysseREGLADE . Can I add your lab to the users of pyEPR? Sorry, can't tell from here who this is

zlatko-minev avatar May 06 '20 18:05 zlatko-minev

Well, I'm an intern working with Zaki Leghtas and Alice&Bob.

UlysseREGLADE avatar May 07 '20 07:05 UlysseREGLADE

Ah ok, great! Say Hi to Zaki and team again. Just saw him on Skype the other day.

From: Ulysse REGLADE [email protected] Reply-To: zlatko-minev/pyEPR [email protected] Date: Thursday, May 7, 2020 at 3:47 AM To: zlatko-minev/pyEPR [email protected] Cc: Zlatko Minev [email protected], Comment [email protected] Subject: Re: [zlatko-minev/pyEPR] analyze_all_variations not working with restricted number of modes (#33)

Well, I'm an intern working with Zaki Leghtas and Alice&Bob.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

zlatko-minev avatar May 07 '20 19:05 zlatko-minev

This seems to be only a bug with the line that gives the error, it assumes that all the modes should be present in the analysis. You can try to comment out lines 103-104 in pyEPR\pyEPR\calcs\back_box_numeric.py and see if it works for now. I'm not sure so I'll look into it after the weekend.

Funny thing that the error that happened without the restrictions (the Series.format error) was the exact same thing but in a completely different place (which is now fixed).

DanielCohenHillel avatar May 07 '20 23:05 DanielCohenHillel

Well, turns out this problem is more complicated than I first thought. For now, it's impossible to do so if you have more than 3 modes (see #36), even if you want to analyze only 2 of them. I think it should be possible to get around this issue if you want to analyze only some of the modes and not all. This is something that I need for myself so I'll try to solve it.

DanielCohenHillel avatar May 19 '20 14:05 DanielCohenHillel

You mean in the function call to analyze_all?

Sent from my iPhone

On May 19, 2020, at 10:53 AM, Daniel Cohen Hillel [email protected] wrote:

 Well, turns out this problem is more complicated than I first thought. For now, it's impossible to do so if you have more than 3 modes (see #36), even if you want to analyze only 2 of them. I think it should be possible to get around this issue if you want to analyze only some of the modes and not all. This is something that I need for myself so I'll try to solve it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

zlatko-minev avatar May 19 '20 15:05 zlatko-minev

Yeah, so the problem itself is probably in analyze_variation or back_box_numeric. I tried to analyze a setup where there are a total of 5 modes and I only care about the first one and the last one and it couldn't run because it couldn't generate such a big matrix (was something like 800,000 by 800,000 matrix) which shouldn't be the case since the quantum analysis itself is only on 2 modes (so it should be like 200 by 200). I haven't looked into it yet though.

DanielCohenHillel avatar May 19 '20 15:05 DanielCohenHillel

Yes, right now the code just passes all of the modes to the numerical diagonalization. Just needs some indexing to cut down and some cleanup

Sent from my iPhone

On May 19, 2020, at 11:35 AM, Daniel Cohen Hillel [email protected] wrote:

 Yeah, so the problem itself is probably in analyze_variation or back_box_numeric. I tried to analyze a setup where there are a total of 5 modes and I only care about the first one and the last one and it couldn't run because it couldn't generate such a big matrix (was something like 800,000 by 800,000 matrix) which shouldn't be the case since the quantum analysis itself is only on 2 modes (so it should be like 200 by 200). I haven't looked into it yet though.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

zlatko-minev avatar May 19 '20 15:05 zlatko-minev

Just looked into it a bit, you're right it's just some indexing problems (luckily), anyway if you pass into the kwargs of analyze_all_variations modes=[0,1,2...] it works properly (note that, for example, if you have 3 modes and you analyze modes [0,2], you'll need to enter [0,1]). So all I need to do is make sure analyze_all_variations passes to analyze_variation the correct modes.

Edit: There's a bit of a mismatch between the analyzed modes and the solution modes, I think it would be best if instead of passing the modes into each function, they would be a property of the object

DanielCohenHillel avatar May 19 '20 16:05 DanielCohenHillel

Accidentally closed this... sorry (it closed automatically when I pushed the commit).

Just pushed a commit to solve this issue, please check if the problem was solved for you @UlysseREGLADE. If it is I'll close this issue.

DanielCohenHillel avatar May 19 '20 18:05 DanielCohenHillel