Plasmapy: Adding Langmuir probe data analysis

[jasperbeckers]

The current direction of PlasmaPy seems to be mostly theoretical/computational. I think it would be good to cater to experimentalists too, for example by providing data analysis functionality. There have been previous discussions about this (eg. https://github.com/PlasmaPy/PlasmaPy/issues/86) but I don't know if those ever went anywhere.

In any case, I'd like to begin implementing some basic Langmuir probe data analysis functionality as a start. It is one of the most common diagnostics and therefore integral to plasma physics as a whole.

The overall functionality would be rather simple; taking potential and current measurements along with some probe and species properties and returning the obtained plasma parameters. This could look something like [T_e, n_e, V_B, V_P, ...] = plasmapy.langmuir.analyze(potential, current, species, probe_properties). Of course there is a large amount of theory written on the subject and many different methods, depending on ie. plasma regime and magnetization. Implementation of the most common methods, along with good documentation, would probably be sufficient initially.

Thoughts?

[StanczakDominik]

• agreed 100%
• Pandas is neat for experimental data and it's probably as close as python
  comes to a standard on that, does it make sense to accept dataframes and
  have the function logic separate the columns as need be?
• How about uncertainties? The first version probably doesn't need to
  include them but it'd be nice to have
• I'd love to have some sample data and expected parameters for that, it'd
  make testing way better!
• plasmapy.langmuir sounds neat!

[lemmatum]

I've got a code for triple Langmuir probe analysis in the "current-mode", as opposed to the more common "voltage-mode", that I could eventually clean up and contribute.

[jasperbeckers]

@StanczakDominik

• I am not very familiar with pandas, but I think I get what you're saying. It sounds like it would help clearing up the data handling a bit, but at the cost of having to include an entirely new module and requiring users to deliver their data in a format they might not know.
• Uncertainties are highly important academically and should definitely be included at some point, where possible
• Yeah, we should gather some V-I traces with known plasma parameters!
• Maybe we should consider bundling all experimental data analysis into a single module? As a start plasmapy.langmuir would probably be fine though.

@lemmatum
Sounds good, could you send some background or theory for that method? Is it widely used?

[StanczakDominik]

I am not very familiar with pandas, but I think I get what you're saying. It sounds like it would help clearing up the data handling a bit, but at the cost of having to include an entirely new module and requiring users to deliver their data in a format they might not know.

Pandas ships with Anaconda and is basically the bread to python data science's butter, adding it as a dependency wouldn't hurt much. The main functionality could be independent of pandas and we could then find some way of adding that, maybe via a wrapper to that main functionality.

Maybe we should consider bundling all experimental data analysis into a single module? As a start plasmapy.langmuir would probably be fine though.

Sure, I was thinking about that as well. So we'd end up having plasmapy.experiment.langmuir or some such path. Seems enough reasonable to me to start with just plasmapy.langmuir for now, we're not exactly anywhere close to feature stable yet!

[jasperbeckers]

@StanczakDominik I agree with all you said. As a start I'll try to find some Langmuir V-I traces and make a rough outline of what the submodule could look like.

[StanczakDominik]

Awesome! Looking forward to that!

[lemmatum]

Might I suggest plasmapy.diagnostics.langmuir instead? I think splitting between experiment and theory/simulation is not so clear as those are intimately tied together. For example, is spectroscopy experimental or simulation? You often need simulations to extract plasma parameters from a measured spectrum.

Here is the paper I based my triple probe code on. I'm not sure how widely used it is, but it is cited by 30 articles, and i imagine most of the functions in my code are usable for other theories. The main difference between current-mode and voltage-mode probes is that with current-mode probes you measure 3 time-resolved currents and use those to simultaneously solve 3 equations for temperature, density, and plasma potential. As I understand it, voltage-mode probes often have a floating tip which measures voltage, so some approximations can be used in getting the plasma parameters.

[StanczakDominik]

Sure, calling the subpackage diagnostics makes sense.

I can't dig into the paper just now, but it seems reasonable to include
both voltage and current modes. Given you guys seem more knowledgeable
about this kind of diagnostics, could I ask you two to collaborate on this,
especially when it comes to code review? I can help with the Python side of
things, but I lack the experience to easily say whether the analysis makes
sense.

[lemmatum]

Sure! Just ping me when the initial module gets setup and I can contribute my code to it and review code that @jasperbeckers and others contribute.

[jasperbeckers]

@StanczakDominik @lemmatum Sounds like a plan. I'll make a fork for us to work on and try to find some known V-I curves for the simplest single probe case (I am most familiar with that one).

[lemmatum]

@StanczakDominik would it be reasonable to start a "diagnostics" project over in the projects tab? I have no idea how this functionality works. I assume it's an admin thing?

[StanczakDominik]

Sure, it would be. Already done :) By the way, I went ahead and figured out how to let @PlasmaPy/plasmapy-diagnostics notify you guys, should you accept the invitation!

[lemmatum]

Dziękuje!

[jasperbeckers]

@StanczakDominik @lemmatum Please see https://github.com/jasperbeckers/PlasmaPy/commit/4508c96d64e78ae4c639ebeb6b56bf3237b995f6 for the initial commit of plasmapy.diagnostics.langmuir! The file outline consists of the class Probe to capture the electrode area(s) and configuration, and functions to obtain the plasma parameters, EEDF and EEPF. Thoughts?

I haven't been able to find example data with known parameters yet.

Also, shall I add you guys as collaborators there?

[StanczakDominik]

Sure, that's probably the best way to do it. That way we can all contribute to that. Another approach would be to get a pull request for the main repository going - there's an option for repository maintainers to be able to push their own code to a contributor's branch. I'm not sure if that works for you guys as team members though, so it might be best to just turn on collaborator access for this one!

A pull request for this one would be handy anyway, for centralized code review etc. :)

[lemmatum]

I'd say pull it into upstream so I can start contributing my own stuff as well 😛

[lemmatum]

@jasperbeckers what's the motivation for adding me to collaborate on your fork? Wouldn't it be better to just work on upstream directly?

[jasperbeckers]

@lemmatum Oh, I thought that'd require me to add you. I'm not very familiar with how GitHub works yet.

[lemmatum]

@jasperbeckers This diagram might help. In this scheme PlasmaPy is "upstream", each of us contributors creates a fork of PlasmPy to our accounts, which we call "origin". We then clone from origin to our local machines (Alice, Bob, etc.). When a feature you want to add is ready, you push to origin on your account and then to upstream. Git then manages all of these pull requests from these different accounts and internally figures out if they conflict. So no need to add me to your origin, we each have our own and then deal with merges and conflicts when pulling into upstream.
Does that make sense?

[jasperbeckers]

@lemmatum Thanks for the explanation! But if I understand correctly I had to add you as collaborator to my langmuir_analysis branch for you to be able to add commits to the pull request? I guess what you mean is that we merge the pull request (with fixed function name) and continue development afterwards.

[lemmatum]

@jasperbeckers Ah, I see what you're getting at, but I don't think that's the right way to git (though I may be wrong). I shouldn't be adding commits to your pull request. Whatever gets pulled doesn't have to be the final version of the code. Once an initial version of the diagnostics part of the code is built by you, you can do a pull request, we'll merge it upstream, and then I can work on it as well.

[StanczakDominik]

I suppose either of those ways is fine. I for one wouldn't mind collaborating on a designated branch of Jasper's, but if you're more comfortable with working alternately via PRs on upstream, that's perfectly fine.

[lemmatum]

Some theory stuff to add

• [ ] ABR
• [ ] BRL
• [ ] Laframboise
• [ ] Kiel (collisional theory)
• [ ] Current-mode probes
• [ ] thermionic emission (super hot probes like to emit particles and it's a pain!)

I think the functions should be available for both forward and inverse analysis.