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

Ats9870 dev branch2 #338

Merged
merged 64 commits into from
Sep 22, 2016
Merged

Ats9870 dev branch2 #338

merged 64 commits into from
Sep 22, 2016

Conversation

damazter
Copy link
Contributor

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

damazter and others added 30 commits February 17, 2016 18:12
…he code and structure is written.

More functions would be nice and several todo items are important before actual implementation
…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
@AdriaanRol
Copy link
Contributor

What I have seen of this driver in action I see no reason not to merge it 👍 . Just awaiting @giulioungaretti or @alexcjohnson for 💃

Copy link
Contributor

@alexcjohnson alexcjohnson left a 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
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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?)

Copy link
Contributor Author

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
Copy link
Contributor

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?

Copy link
Contributor Author

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)

Copy link
Contributor

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.

Copy link
Contributor Author

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)
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor Author

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}
Copy link
Contributor

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)
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@nulinspiratie
Copy link
Contributor

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?

@alexcjohnson
Copy link
Contributor

@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.

@damazter damazter mentioned this pull request Sep 21, 2016
@damazter
Copy link
Contributor Author

@nulinspiratie
If you can make a pullrequest into this branch that would be fine.
But I will also be working to resolve as much issues as i can


class Multiples(validators.Ints):
'''
requires an integer
Copy link
Contributor

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
"""

@giulioungaretti
Copy link
Contributor

Aside from my minor comments, and in general the lack of docstrings (or proper format) the rest is ok for me. Also almost impossible to say more than style without having a card here!

good job @damazter @elrama- and all the others!

@damazter
Copy link
Contributor Author

@alexcjohnson
@giulioungaretti
I think I have adressed al your issues.
If you have any issues left, please inform me

" found '" + str(model) + "' instead.")


class Multiples(validators.Ints):
Copy link
Contributor

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.

Copy link
Contributor Author

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

@alexcjohnson
Copy link
Contributor

@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:
Copy link
Contributor

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.

@damazter
Copy link
Contributor Author

waiting on pr #339

@damazter
Copy link
Contributor Author

#339 is now incorporated, so I am ready to be merged
💃 to the core developers to merge

@alexcjohnson alexcjohnson merged commit f856cca into master Sep 22, 2016
@alexcjohnson alexcjohnson deleted the ATS9870-dev-branch2 branch September 22, 2016 14:50
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.

8 participants