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

Improved sampling algorithm for mcsolve #2218

Merged
merged 20 commits into from Aug 25, 2023

Conversation

dkweiss31
Copy link
Contributor

Description
Added functionality associated with an improved monte-carlo sampling algorithm described in https://journals.aps.org/pra/abstract/10.1103/PhysRevA.99.052327 . This algorithm samples the no-jump trajectory only once, then only samples jump trajectories afterwards. Expectation values, final states, etc are then computed by appropriately weighting the no jump and jump trajectories by the no-jump probability.

@dkweiss31 dkweiss31 changed the title Mcsolve efficienvy v2 Improved Sampling algorithm for mcsolve Aug 21, 2023
@dkweiss31 dkweiss31 changed the title Improved Sampling algorithm for mcsolve Improved sampling algorithm for mcsolve Aug 21, 2023
@coveralls
Copy link

Coverage Status

coverage: 85.002% (+0.1%) from 84.88% when pulling 966f495 on dkweiss31:mcsolve_efficienvy_v2 into beacadf on qutip:master.

Copy link
Member

@Ericgig Ericgig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the contribution, this seems an interesting variant the the Monte-carlo algorithm.

Should it raise a warning for users that tries to access each trajectories? Or add a note in the docstring? The trajectories would look strange if you don't read the documentation.

I am wondering if MCSolverImprovedSampling could be merged in MCSolver. I am not a fan of having mcsolve use 2 different solvers and it should be accessing by the new class interface. Another options would be that make MCSolverImprovedSampling public and add a new function to call it mcissolve?

I would prefer that you revert the changes made by black. It add a lot of changes that are unrelated to the new feature and makes reviewing the PR annoying. Also we use the pep8 line width of 80 instead of black's 88.
For now, we mostly use black in new code and adding black to existing file should be their own PR.

qutip/solver/multitraj.py Outdated Show resolved Hide resolved
qutip/solver/result.py Show resolved Hide resolved
qutip/tests/solver/test_mcsolve.py Outdated Show resolved Hide resolved
qutip/tests/solver/test_mcsolve.py Outdated Show resolved Hide resolved
seeds=None,
target_tol=None,
timeout=None,
improved_sampling=False,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel this should be in options. options include modification to the algorithm that do not change the physic.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right so I guess the question is: do we make a new function mcissolve or add this as a flag to options. Maybe I'd be more inclined for a new function, but I don't have a strong preference

@dkweiss31
Copy link
Contributor Author

Thanks for the quick reply!

Should it raise a warning for users that tries to access each trajectories? Or add a note in the docstring? The trajectories would look strange if you don't read the documentation.

Maybe, though I'm not sure why they would look strange? It's possible a user could get confused if they don't see any no-jump trajectories other than the first one, but hopefully they wouldn't be confused if they set the flag to use this algorithm.

I am wondering if MCSolverImprovedSampling could be merged in MCSolver. I am not a fan of having mcsolve use 2 different solvers and it should be accessing by the new class interface. Another options would be that make MCSolverImprovedSampling public and add a new function to call it mcissolve?

Yeah this might be the way to go. I only had it the way I did to have MultiTrajSolverImprovedSampling get inherited before MCSolver so that the functionality there gets used and also have resultclass = McResultImprovedSampling. We could do a conditional inheritance in MCSolver, but I'm worried that might be messy/ugly?

I would prefer that you revert the changes made by black. It add a lot of changes that are unrelated to the new feature and makes reviewing the PR annoying. Also we use the pep8 line width of 80 instead of black's 88. For now, we mostly use black in new code and adding black to existing file should be their own PR.

Sorry about that, will revert

…istent line breaking (80), check for self.num_trajectories==1 instead of a no-jump flag since the no jump is always first
Copy link
Member

@Ericgig Ericgig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that MultiTrajSolverImprovedSampling and MultiTrajResultImprovedSampling. We only need one new class for the solver and result, not 2 each.
It would even be nice if it could be inserted into MCSolver without making the code to messy...

I believe that a scaling should be applied in to the McResult.photocurrent method. Could you check. It's an histogram of the jumps times.

The last issue is whether to make a new function or not.
I feel it belong as an options in the existing mscolve, but it would be easy to overlook by users. As a new function it will get more attention. I also don't have a strong opinion on the matter.

qutip/solver/result.py Outdated Show resolved Hide resolved
qutip/solver/multitraj.py Outdated Show resolved Hide resolved
qutip/solver/multitraj.py Outdated Show resolved Hide resolved
… into MCSolver, eliminated MultiTrajSolverImprovedSampling and moved that functionality into MCSolver, MultiTrajResultImprovedSampling -> McResultImprovedSampling, fixed photocurrent computation, fixed tests (mostly adding improved_sampling as a key in options, some pep8 stuff)
@dkweiss31
Copy link
Contributor Author

I believe that MultiTrajSolverImprovedSampling and MultiTrajResultImprovedSampling. We only need one new class for the solver and result, not 2 each. It would even be nice if it could be inserted into MCSolver without making the code to messy...

Agreed

I believe that a scaling should be applied in to the McResult.photocurrent method. Could you check. It's an histogram of the jumps times.

Yes you're right, sorry I missed that. Should be fixed now.

The last issue is whether to make a new function or not. I feel it belong as an options in the existing mscolve, but it would be easy to overlook by users. As a new function it will get more attention. I also don't have a strong opinion on the matter.

I think you are right. I added it as an option to options and updated tests, docs accordingly.

@@ -385,6 +408,9 @@ def __init__(self, H, c_ops, *, options=None):
rhs -= 0.5 * n_op

self._num_collapse = len(self._c_ops)
self.options = options
if self.options["improved_sampling"]:
self.resultclass = McResultImprovedSampling
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something I'm not super happy about: this wants to be defined outside of init (where we have resultclass = McResult now). Maybe still not a good enough reason to define a whole new class MCSolverImprovedSampling though

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe set resultclass to be a property that check the option and return the right type.

Another options would by using a metaclass. It feels overkill, but would be clean (here at least).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The metaclass idea sounds fun but maybe the below simple fix works?

Copy link
Member

@Ericgig Ericgig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good.

I left some ideas on how to improve the resultclass setting.

doc/guide/dynamics/dynamics-monte.rst Outdated Show resolved Hide resolved
@@ -385,6 +408,9 @@ def __init__(self, H, c_ops, *, options=None):
rhs -= 0.5 * n_op

self._num_collapse = len(self._c_ops)
self.options = options
if self.options["improved_sampling"]:
self.resultclass = McResultImprovedSampling
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or maybe set resultclass to be a property that check the option and return the right type.

Another options would by using a metaclass. It feels overkill, but would be clean (here at least).

doc/guide/dynamics/dynamics-monte.rst Outdated Show resolved Hide resolved
qutip/solver/result.py Outdated Show resolved Hide resolved
dkweiss31 and others added 5 commits August 24, 2023 20:44
Copy link
Member

@Ericgig Ericgig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @dkweiss31.
Everything looks fine to me.

@Ericgig Ericgig merged commit 2dc5f3f into qutip:master Aug 25, 2023
12 checks passed
@dkweiss31 dkweiss31 deleted the mcsolve_efficienvy_v2 branch August 25, 2023 17:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants