Weighted trajectories #2369

pmenczel · 2024-03-29T05:58:51Z

Description

Introduces weights for the trajectories of trajectory solvers. These weights enter all trajectory averages. This concept is a generalization of two things that are already in qutip:

The influence martingale in nm_mcsolve is simply a time-dependent weight from this point of view
The "improved sampling" option for mcsolve weights the no-jump trajectory with its exact probability, and then only samples from the ensemble of trajectories with at least one jump.

Currently, these two things cannot be combined: "improved sampling" does not work for nm_mcsolve. With these changes, it would work.
In the future, there might be at least one more application for weighted trajectories:

For mixed initial states in mcsolve, it might be useful to allow sampling of initial states with frequencies or probabilities that are different from their true prefactor in the initial state. The ratio between the sampling frequencies and true prefactors would be weights on the trajectories.

This also fixes some things in merging McResults and NmmcResults, and perhaps fixes the target tolerance computation for the "improved sampling" option.

Implementation

A difficulty in the implementation is that the weights depend on the total number of trajectories in different ways. For example, the no-jump trajectory has a fixed weight that never changes, but all other trajectories come with prefactors $(1-p_0) / (N-1)$ where $p_0$ is the probability of the no-jump trajectory, and $N$ the total number of trajectories (including the one no-jump trajectory). For this reason, I separate weights into absolute weights (like $p_0$) and relative weights (like the others). The average is performed as follows:

$$ \bar\rho = \sum_{T: \text{abs}} w_a(T) w_r(T) \rho(T) + \frac{1}{N_{\text{rel}}} \sum _{T: \text{rel}} w_r(T) \rho(T) $$

where the first sum is over all trajectories T that have absolute weights, and the second sum over all other trajectories. Here, $w_a(T)$ and $w_r(T)$ are the absolute and relative weights, $\rho(T)$ the state associated with a trajectory, and $N_{\text{rel}}$ the number of trajectories that have not been assigned absolute weights.

Intuitively, the idea is that absolute weights are for trajectories where the contribution to the full state is known exactly, and the trajectories without absolute weights are the stochastic part.

Things to do

Update tests and create new ones
Update photocurrent to work with weights
Update target tolerance calculation to work with weights
Think about how result objects should be added if both contain trajectories with absolute weights
Double-check that this creates no problems for stochastic solvers
Towncrier entry

Related issues or PRs
#2235

coveralls · 2024-03-29T06:26:08Z

coverage: 86.098% (+0.008%) from 86.09%
when pulling cd96a59 on pmenczel:weighted-trajectories
into 320996b on qutip:master.

Ericgig

Thank you for merging the results classes.

The default seems to be a relative weight of 1. Meaning that it should work fine in solver which does not use it (stochastic). But should they just keep using Result until we have a use for those weight?

It there a balancing tools for weight values?
If there are 2 runs, can both have a relative weight of 10 or 0.1 without affecting the end results? If there are 2 starting kets that we want to merge with a weight of 10:1, does the actual values matter or only the ratio?

I feel it would be safer to compute the relative weight as W(T) / sum_T(W(T)) instead of using the number of trajectories.

I am not sure how it works with weight changing over time...

Ericgig · 2024-04-01T02:19:55Z

qutip/solver/result.py

+        # TODO this is wrong if trajectories have weights
+        # unclear how to implement in case of time-dependent weights


Does photocurrent make sense for nm_mcsolve?
If it does not, we could raise an error when used with time-dependent weights.

It probably does not make sense for nm_mcsolve. I have added an error in the case of time-dependent weights, and removed the tests for it.

qutip/solver/result.py

…e results.

pmenczel · 2024-04-01T10:23:19Z

Thank you for your review.

The default seems to be a relative weight of 1. Meaning that it should work fine in solver which does not use it (stochastic). But should they just keep using Result until we have a use for those weight?

I let them use Result again for now. I needed to add some lines here so that the new MultiTrajResult can deal with it. (Which might be a good idea anyway.)

It there a balancing tools for weight values? If there are 2 runs, can both have a relative weight of 10 or 0.1 without affecting the end results? If there are 2 starting kets that we want to merge with a weight of 10:1, does the actual values matter or only the ratio?

I have added a merge function that lets the user merge trajectory results with custom relative weights. I think trajectories with absolute or relative weights are handled consistently. Calling result1 + result2 uses default values for the relative weights, chosen such that every trajectory contributes equally.
(That doesn't currently work for the stochastic solvers, but to my understanding, adding results didn't work for them previously either. It raises a NotImplementedError now.)

I feel it would be safer to compute the relative weight as W(T) / sum_T(W(T)) instead of using the number of trajectories.

Hmm unfortunately I think that this won't work. For the "improved sampling" case, the sum of the relative weights is not one.

…sults

…ries

Ericgig

It's nice to merge McResultImprovedSampling into McResult, but the overall complexity has increased... I believe it would be better to move MultiTrajResult to it's own file.

Did you review the dynamics-nmmonte,rst? Adding a note/example of using the improved sampling option there would be good.

Ericgig · 2024-05-01T19:35:34Z

qutip/solver/stochastic.py

+    def merge(self, other, p=None):
+        raise NotImplementedError("Merging results of the stochastic solvers "
+                                  "is currently not supported. Please raise "
+                                  "an issue on GitHub if you would like to "
+                                  "see this feature.")
+


Why is that not supported?
There are no weight to them, it should be the easiest to merge...

Currently, merging the measurement, dW etc attributes of stochastic results doesn't work, I think. That was the reason why I removed merge here, but maybe that went too far.

Should I just remove this, or maybe leave in a warning in the case a user tries to merge stochastic results where store_measurement was used?

It can be left as is for now. Merging measurement and dW should be easy, it can be done in another PR.

Ericgig · 2024-05-01T20:12:21Z

qutip/tests/solver/test_results.py

+                random_state = qutip.rand_ket(dim, seed=seed)
+                traj.add(t, random_state)
+
+            if time_dep_weights and np.random.randint(2):


Why is that options randomly used?
Having an options explicitly passed ignored randomly depending in a randint result feels strange.

I wanted to add weights to only some of the trajectories, to test that nothing goes wrong if some of the traj don't have weights.

qutip/tests/solver/test_results.py

qutip/solver/result.py

Ericgig · 2024-05-01T21:08:58Z

qutip/solver/result.py

@@ -895,7 +970,31 @@ def __repr__(self):
        lines.append(">")
        return "\n".join(lines)

-    def __add__(self, other):
+    def merge(self, other, p=None):


The __add__ is already in the users hand and part of the official interface.
It is documented in the guide (and maybe the tutorials).
It's new, so it's probably not used much, but still we shouldn't remove it without a deprecation warning or a major release...

It would be better to keep it as merging with the default value of p.

The __add__ still exists, and it does call merge with the default value of p: https://github.com/pmenczel/qutip/blob/weighted-trajectories/qutip/solver/multitrajresult.py#L760

I introduced a new function merge because adding an optional parameter p to __add__ felt like a bad practice.

pmenczel · 2024-05-06T07:02:45Z

It's nice to merge McResultImprovedSampling into McResult, but the overall complexity has increased... I believe it would be better to move MultiTrajResult to it's own file.

Did you review the dynamics-nmmonte,rst? Adding a note/example of using the improved sampling option there would be good.

Thank you for the review. The complexity has increased, more than I expected when I started writing. I hope it is worth it?
I have extracted the MultiTrajResult and its subclasses to a new module, qutip.solver.multitrajresult.

I have added a mention about the improved sampling option in the guide, and I will have a look at the tutorial notebook whether it makes sense to include somewhere there.

Ericgig

I think the increased complexity is fine in this case.
Everything looks good. Thank you.

Ericgig · 2024-05-06T15:02:06Z

qutip/solver/stochastic.py

+    def merge(self, other, p=None):
+        raise NotImplementedError("Merging results of the stochastic solvers "
+                                  "is currently not supported. Please raise "
+                                  "an issue on GitHub if you would like to "
+                                  "see this feature.")
+


It can be left as is for now. Merging measurement and dW should be easy, it can be done in another PR.

pmenczel and others added 8 commits March 24, 2024 13:04

WIP commit: weighted trajectories

0994713

Merge branch 'multitraj-improvements' into weighted-trajectories

4f86221

WIP commit 2: weighted trajectories

1ea5a12

Merge branch 'multitraj-improvements' into weighted-trajectories

80ec47f

Weighted trajectories

b85af2e

Small fixes

4b81f97

Merge branch 'qutip:master' into weighted-trajectories

e65d497

More small fixes

4a79860

Code formatting

24c7952

Ericgig reviewed Apr 1, 2024

View reviewed changes

pmenczel added 6 commits April 1, 2024 14:20

Suggestions from code review

ab87d6f

photocurrent with weights

ada5c04

Removed photocurrent from nm_mcsolve tests

66c2ce6

Revert stochastic solvers to Result instead of TrajectoryResult

b059661

Towncrier entry

b7eadd7

Merging results with weighted trajectories, and mcsolve and nm_mcsolv…

fedb376

…e results.

pmenczel added 7 commits April 3, 2024 13:27

Remove unnecessary fields

f643fdf

Moved runs_weights to MultiTrajResult

d048fef

Updated target tolerance calculation for weighted traj

ba9071b

Started adding tests

95caad4

Added tests for merging multi trajectory results / mcresults / nmmcre…

f4585e8

…sults

Added improved sampling to nmmcsolve tests

e60e283

Fix typo in mcsolve test

283e060

pmenczel marked this pull request as ready for review April 4, 2024 05:37

pmenczel added 4 commits April 4, 2024 18:29

Performance improvement

5fabdd3

Merge remote-tracking branch 'upstream/master' into weighted-trajecto…

64b5251

…ries

Fixed target tolerance calculation

9208fea

Merge remote-tracking branch 'upstream/master' into weighted-trajecto…

3f774b2

…ries

Ericgig reviewed May 1, 2024

View reviewed changes

pmenczel and others added 5 commits May 3, 2024 12:19

Merge branch 'qutip:master' into weighted-trajectories

7f72b23

Created multitrajresult module

18a75b9

Documentation for _TrajectorySum class

bf604c3

Updated nmmcsolve guide and fixed broken links

c48b550

Don't fix random seed in test

cd96a59

Ericgig approved these changes May 6, 2024

View reviewed changes

pmenczel merged commit 94f7392 into qutip:master May 7, 2024
11 of 12 checks passed

pmenczel deleted the weighted-trajectories branch May 7, 2024 04:43

pmenczel mentioned this pull request May 7, 2024

Added improved sampling example to nmmcsolve notebook qutip/qutip-tutorials#94

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Weighted trajectories #2369

Weighted trajectories #2369

pmenczel commented Mar 29, 2024 •

edited

coveralls commented Mar 29, 2024 •

edited

Ericgig left a comment

Ericgig Apr 1, 2024

pmenczel Apr 1, 2024

pmenczel commented Apr 1, 2024 •

edited

Ericgig left a comment

Ericgig May 1, 2024

pmenczel May 6, 2024 •

edited

Ericgig May 6, 2024

Ericgig May 1, 2024

pmenczel May 6, 2024

Ericgig May 1, 2024

pmenczel May 6, 2024

pmenczel commented May 6, 2024

Ericgig left a comment

Ericgig May 6, 2024

		# TODO this is wrong if trajectories have weights
		# unclear how to implement in case of time-dependent weights

Weighted trajectories #2369

Weighted trajectories #2369

Conversation

pmenczel commented Mar 29, 2024 • edited

coveralls commented Mar 29, 2024 • edited

Ericgig left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmenczel commented Apr 1, 2024 • edited

Ericgig left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmenczel May 6, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmenczel commented May 6, 2024

Ericgig left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmenczel commented Mar 29, 2024 •

edited

coveralls commented Mar 29, 2024 •

edited

pmenczel commented Apr 1, 2024 •

edited

pmenczel May 6, 2024 •

edited