Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speedup of _correlation_3op_dm #2315

Open
theodotk opened this issue Feb 3, 2024 · 1 comment
Open

Speedup of _correlation_3op_dm #2315

theodotk opened this issue Feb 3, 2024 · 1 comment

Comments

@theodotk
Copy link
Contributor

theodotk commented Feb 3, 2024

Describe the Issue!

Calculation of 2-time correlation is understandably slow. There are two things that can improve _correlation_3op_dm(solver, state0, tlist, taulist, A, B, C) a bit.

  1. In my experience tlist is usually chosen so that at tlist[-1] all correlations are already gone. Calculate them up to tlist[-1] + taulist[-1] is often superfluous. An option can be passed to make last tau dependent on t to make each subsequent simulation shorter. An example could be something like this (but with more thinking about edge cases):
_correlation_3op_dm(solver, state0, tlist, taulist, A, B, C, shorten_tau=False):
    ...
    for t_idx, rho in enumerate(rho_t):
            t = tlist[t_idx]
            if shorten_tau:
                last_tau_index = sum(np.array(taulist) <= t)
                this_step_taulist = taulist[last_tau_index:]
            else:
                this_step_taulist = taulist + t
            corr_mat[t_idx, :] = solver.run(
                C(t) @ rho @ A(t),
                this_step_taulist,
                e_ops=B
            ).expect[0]
            progress_bar.update()
        progress_bar.finished()
  1. Even better way would be to make simulations along taulist in parallel. It seems that it's possible to have different runs of mcsolve at the same time, so here the same framework could be used.
@Ericgig
Copy link
Member

Ericgig commented Feb 3, 2024

Thank you for the suggestions.

(2) It should be easy. We could reuse the parallel_map as you said. I would make a good first contribution.

(1) We need to be careful about this.
I can see case where the user think the correlation is gone by tlist[-1] but it is not, so it should be clear which output are 0 and which are not computed.
Also if we do that, maybe finer control could be given. We could have a variable max_t_plus_tau with default np.inf.

valleyofblackpanther added a commit to valleyofblackpanther/qutip that referenced this issue Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants