Author Topic: Timing test for SDv2.6.1  (Read 4359 times)

JyrkiRantaharju

  • Member
  • *
  • Posts: 36
    • View Profile
Timing test for SDv2.6.1
« on: May 28, 2013, 04:32:13 PM »
Hi all,

I measured the time used by the Trajectory routine of SDv2.6.1 and SDv2.5.0, to calculate  trajectory of a single spin system, as a function of the length of the event specification list.  Below are the results:
length of the event
specification list
time used
 by SD 2.6.1
time used
 by SD 2.5.0
500
272.425s
19.457s
1000
621.615s
38.234s
2000
1461.28s
86.901s
what might cause such a great difference?

I made the above test with spin 1 EPR system. Below is another test with very simple spin 1/2 system:

test with SDv2.6.1
Code: [Select]
(t1 = TimeUsed[]; Trajectory[opI["z"] -> opI["z"], {opI["z"], 10^-10} & /@ Range[#]];
t2 = TimeUsed[]; t2 - t1) & /@ {1, 500, 1000, 2000, 3000}
{0.3360219999999997`, 48.35502199999999`, 154.313644`, 578.576158`, 1286.7564180000002`}

test with SDv2.5.0
Code: [Select]
(t1 = TimeUsed[]; Trajectory[opI["z"] -> opI["z"], {opI["z"], 10^-10} & /@ Range[#]];
 t2 = TimeUsed[]; t2 - t1) & /@ {1, 500, 1000, 2000, 3000}
{0.29201900000000025`, 11.000687000000001`, 24.197511999999993`, 51.447215`, 105.486593`}

difference between the simulation times
Code: [Select]
({0.3360219999999997`, 48.35502199999999`, 154.313644`, 578.576158`, 1286.7564180000002`}
 - {0.29201900000000025`, 11.000687000000001`, 24.197511999999993`, 51.447215`, 105.486593`})
{0.04400299999999946`, 37.35433499999999`, 130.11613200000002`, 527.1289429999999`, 1181.269825`}

Jyrki
« Last Edit: May 29, 2013, 10:15:30 PM by Jyrki Rantaharju »

JyrkiRantaharju

  • Member
  • *
  • Posts: 36
    • View Profile
Re: Timing test for SDv2.6.1
« Reply #1 on: May 29, 2013, 09:50:06 PM »
Hi all,

The increase of the simulation time seem to be caused by the
Code: [Select]
\[Rho]intervalfuncs = Function[t,Evaluate[Assuming[(First[#] < t < Last[#]), Refine[\[Rho]func[t]]]]]& /@tintervals;code in the trajectories of several operators subsection of the Trajectory routine.

Jyrki

MalcolmHLevitt

  • Administrator
  • Member
  • *****
  • Posts: 103
    • View Profile
Re: Timing test for SDv2.6.1
« Reply #2 on: June 10, 2013, 06:07:21 PM »
My documentation shows that at v2.5.2 I fixed a bug in CombineTrajectories which was leading to extremely slow calculations, and then fixed another bug in the same routine at v2.5.4, and again for v2.6b2. As I recall, I was seeing mysterious overshoots in the trajectory. I traced these to the FunctionInterpolation function of Mathematica, which I found to be unreliable. So I recoded to avoid FunctionInterpolation, but the efficiency of the code seems to have been compromised at the same time. I tend not to use so many time intervals, so I must have missed its poor efficiency in that case.

Unfortunately I am reluctant to open that can of worms again, given my current commitments.

If anyone volunteers to look at this, I have on file the test notebooks that I used to fix the bugs mentioned above.

If I recall, the line mentioned above:
Code: [Select]
\[Rho]intervalfuncs = Function[t,Evaluate[Assuming[(First[#] < t < Last[#]), Refine[\[Rho]func[t]]]]]& /@tintervals;Has the following purpose.
tintervals contains the set of time intervals for the Piecewise function, i.e. {..,{tb,ta}}
\[Rho]func is the Piecewise function for the density operator Rho, which may be evaluated at any time over the whole trajectory
\[Rho]intervalfuncs is the set of functions for Rho, which apply for the individual intervals, i.e. {..Rhofunc2, Rhofunc1}.
I obtain these from Rhofunc by using Refine and Assuming. This has the benefit of reliability and generality. I found this method to be convenient but there might well be a more efficient method.
« Last Edit: June 10, 2013, 06:18:43 PM by MalcolmHLevitt »

JyrkiRantaharju

  • Member
  • *
  • Posts: 36
    • View Profile
Re: Timing test for SDv2.6.1
« Reply #3 on: June 10, 2013, 06:28:10 PM »
Could not NPropagate feed the density matrix to Trajectory straight as a list of density matrices for each interval?

I will have a look at the SDv2.6.2b2 tomorrow.

MalcolmHLevitt

  • Administrator
  • Member
  • *****
  • Posts: 103
    • View Profile
Re: Timing test for SDv2.6.1
« Reply #4 on: June 10, 2013, 08:57:12 PM »
Could not NPropagate feed the density matrix to Trajectory straight as a list of density matrices for each interval?

I will have a look at the SDv2.6.2b2 tomorrow.

Thanks Jyrki. Yes, that is probably possible - but note that it would be a list of density operator functions, not just the matrices. Unfortunately I think such a solution would involve rather large structural changes and is best avoided unless there is no other option.

I think the Piecewise function output could probably be decoded directly rather than using Refine[.. Assuming]. The code could pattern-match the arguments to Piecewise and extract the appropriate element belonging to a given interval - if such exists - but still holding the Refine code as a backup option if an appropriate match is not found. That might be a good compromise between speed and generality. I would have a go myself but I don't have time right now. Thanks for your suggestions.

JyrkiRantaharju

  • Member
  • *
  • Posts: 36
    • View Profile
Re: Timing test for SDv2.6.1
« Reply #5 on: June 12, 2013, 11:52:49 AM »
Hi Malcolm,

I extracted the list of density operator functions very straightforwardly with code
Code: [Select]
\[Rho]funclist =  Flatten[List @@ (\[Rho]func[[2]] /. ConditionalExpression[stuff : __, ___] :> stuff) /. {op_?OperatorQ, _?NumericQ <= t_ < _?NumericQ} :> op];
and then calculated the \[Rho]intervalfuncs
Code: [Select]
\[Rho]intervalfuncs = Function[t, #] & /@ \[Rho]funclist;this seems to work and fix the timing problem.

Could you send the test notebooks and I could develop this further? I could develop a system which checks that the density operator functions corresponding to right time intervals are at right places, although I don't know why would not they be.

Jyrki.

MalcolmHLevitt

  • Administrator
  • Member
  • *****
  • Posts: 103
    • View Profile
Re: Timing test for SDv2.6.1
« Reply #6 on: June 13, 2013, 06:44:36 PM »
Thanks very much Jyrki,

I found that your code had a problem for a single event so I recoded slightly. Version 2.6.2b3 contains this and also your recoding of parallel. Please try it out. See here:

https://www.dropbox.com/sh/x26heihcib5mbqu/1MN3HBANk5

Thanks a lot
best wishes
malcolm

MalcolmHLevitt

  • Administrator
  • Member
  • *****
  • Posts: 103
    • View Profile
Re: Timing test for SDv2.6.1
« Reply #7 on: July 24, 2013, 11:12:19 PM »
Hi Jyrki,
 I hope that the new version SDv2.7.1 includes most of your fixes for these problems.
malcolm