-
Notifications
You must be signed in to change notification settings - Fork 317
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
Ats9870 dev branch2 #338
Ats9870 dev branch2 #338
Conversation
…he code and structure is written. More functions would be nice and several todo items are important before actual implementation
fixed some small errors
…tors to validate that the value is in the values of the dictionary. The driver now calls the validate function of the parameter class to enforce this validation. Solved the problem with sample rates changed the default of some parameters implemented trivial dictionaries. Driver still largely untested
Changes: * Typo in line 345 of ATS.py * Avoiding error handling for 518 (see explanation on github post) * Example notebook for ATS, still at a draft stage
Add a TODO item, remove obsolete variable and revert a change regarding post_trigger_size variable to improve code readability
What I have seen of this driver in action I see no reason not to merge it 👍 . Just awaiting @giulioungaretti or @alexcjohnson for 💃 |
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.
@damazter just a few comments on the AcquisitionController
implementation. The rest of it I've had my fingers in before, looks good to me but I'd like to give @giulioungaretti a chance to weigh in before we merge.
return None | ||
|
||
def fit(self, buf): | ||
# Discrete Fourier Transform |
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 isn't exactly a Fourier Transform... it's just one Fourier component. Is it common usage to refer to a single frequency output this way?
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.
@alexcjohnson
For us, this is very common. During an acquisition, we do not have the (computational) speed to calculate the entire transform. We only really need a single point though, as when we demodulate a signal, our target frequency is fixed and well known.
If other users want to demodulate more frequencies, they would have to write their own acquisition_controller
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 wasn't commenting on the functionality, which makes perfect sense, just on the naming. I know I'm not the only one who was puzzled by calling this a Fourier Transform, so I wonder if we could give it a more precise name, like SingleFreq_AcquisitionController
perhaps? Again, if it's common usage to call this a Fourier Transform I'm happy to be overruled (but then what will we call it when we make one that returns the full transform, perhaps averaged over many shots?)
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.
@AdriaanRol suggested Demodulation_AcquisitionController
so I will change it to something like that. As it is only an example acquisitioncontroller, my feeling about the name is actually not that intense.
instrument_class=AlazarTech_ATS) | ||
|
||
def _get_alazar(self): | ||
return self.alazar |
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.
It's a little backward to use an underscored method to retrieve a non-underscored attribute :) Can we just set self._alazar
and take out this method?
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.
@alexcjohnson
@giulioungaretti
I would like some more help in this point, I have renamed self.alazar
to self._alazar
but i want to have the self._get_alazar as an interface function to the children of this class.
Having this method will make it very clear to users that a reference to the alazar can be obtained.
However, this method must be private as it makes no sense to obtain a reference to the alazar across different servers, or to the end user. so would it be ok to leave this function in the code?
(repeating myself, I will rename self.alazar
to self._alazar
)
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.
OK, my main point is addressed now that you have self._alazar
- thanks! But if the only reason to have the getter method is so users can find it more easily (and in the method's docstring you even suggest just using the attribute itself), you could also consider an Attributes
section in the class docstring.
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 added it to the class docstring, maybe the amount of references to the existence of self._alazar
is a bit extreme, but it also cannot hurt
# make a call to the parent class and by extension, create the parameter | ||
# structure of this class | ||
super().__init__(name, alazar_name, **kwargs) | ||
self.add_parameter("acquisition", get_cmd=self.do_acquisition) |
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.
Can we move this (along with do_acquisition
and set_acquisitionkwargs
) into the AcquisitionController
base class?
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.
@alexcjohnson
I have thought about this, but I would like to keep the base class as empty as possible.
I think that many 'real' acquisition controllers will want to do something very different. For example, I expect them to calculate their own acquisition_kwargs such that set_acquisitionkwargs to becomes obsolete in these implementations.
I expect similar things for do_acquisition, maybe other users want to split their acquisition into a different (larger) set of parameters
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.
OK, we can leave it for now and revisit this as people add more controllers and we see how this structure varies.
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.
@alexcjohnson
I don't know if all acquisition controllers will be uploaded to the qcodes repo, but thnx for keeping it this way.
class DFT_AcquisitionController(AcquisitionController): | ||
def __init__(self, name, alazar_name, demodulation_frequency, **kwargs): | ||
self.demodulation_frequency = demodulation_frequency | ||
self.acquisitionkwargs = {'acquisition_controller': self} |
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 would not put 'acquisition_controller'
in these kwargs - bad things would happen if you ever changed that! just do alazar.acquire(acquisition_controller=self, **self.acquisitionkwargs)
self.add_parameter("acquisition", get_cmd=self.do_acquisition) | ||
|
||
def set_acquisitionkwargs(self, **kwargs): | ||
self.acquisitionkwargs.update(**kwargs) |
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.
if you mean update you should call it update_acquisitionkwargs
, as set implies replacing them all... but it's not clear to me that this is better than just letting users edit self.acquisitionkwargs
directly - which is implied to be allowed since it doesn't start with an underscore. Anyway, this will feel safer when acquisition_controller=self
is separated out.
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.
@alexcjohnson
I agree with you here, I have renamed it to update_acquisitionkwargs.
The reason to use update is that it enables users to change a single parameter of the acquisitionkwargs that have been set before.
The pull request I made with some modifications to this branch actually deals with some of the points @alexcjohnson raises. Would it make sense to merge that branch first? |
@nulinspiratie #330 I guess? Looks good to me, to first merge that one into this branch (which may be easiest by cherry-picking your commit onto this branch, since this branch has diverged a bit from your starting point) then I can look again, but maybe chat with @damazter first. |
@nulinspiratie |
|
||
class Multiples(validators.Ints): | ||
''' | ||
requires an integer |
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.
Needs proper docstrings IMHO.
"""
Does fooo bar
Args:
divisor
"""
@alexcjohnson |
" found '" + str(model) + "' instead.") | ||
|
||
|
||
class Multiples(validators.Ints): |
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.
nonblocking, but this seems generically useful enough that we could move it into the core validators
module.
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'll make a pr for that
@damazter thanks for the changes. I made a few new nonblocking comments, in particular see what you think about my naming comment but I don't want to hold this up any more so have approved my review. Nice job, this is not an easy driver to make and I think this will be quite a powerful framework for these cards! |
'This method should be implemented in a subclass') | ||
|
||
|
||
class TrivialDictionary: |
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'd document why you want a TrivalDictionary in this driver.
waiting on pr #339 |
#339 is now incorporated, so I am ready to be merged |
Replaces pr #66
Changes proposed in this pull request:
add a general driver for ATS acquisition cards and a specific driver for the ATS9870
@elrama- @AdriaanRol
This branch is ready to merge, example notebook runs perfectly.
Some changes will be needed to this driver in the future to fix some compatibility issues with the
ATS9360 and ATS9440
@nataliejpg @nulinspiratie
I think those changes are best reviewed as separate pull requests to the master branch.
@alexcjohnson @giulioungaretti