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
Conversation
… to perturb default functionality. Also ensure state averages calculated correctly
There was a problem hiding this 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/mcsolve.py
Outdated
seeds=None, | ||
target_tol=None, | ||
timeout=None, | ||
improved_sampling=False, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
This reverts commit f034705
Thanks for the quick reply!
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.
Yeah this might be the way to go. I only had it the way I did to have
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
There was a problem hiding this 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.
… 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)
Agreed
Yes you're right, sorry I missed that. Should be fixed now.
I think you are right. I added it as an option to options and updated tests, docs accordingly. |
qutip/solver/mcsolve.py
Outdated
@@ -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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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?
There was a problem hiding this 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.
qutip/solver/mcsolve.py
Outdated
@@ -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 |
There was a problem hiding this comment.
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).
Co-authored-by: Eric Giguère <eric.giguere@calculquebec.ca>
Co-authored-by: Eric Giguère <eric.giguere@calculquebec.ca>
…mproved_sampling"]
…lve_efficienvy_v2
There was a problem hiding this 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.
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.