Git Product home page Git Product logo

Comments (13)

blalterman avatar blalterman commented on June 5, 2024

from plasmapy.

antoinetavant avatar antoinetavant commented on June 5, 2024

Should we create a TODO.md file to list that ?
Some points I listed :

  • characteristic frequency/distance
  • Easy transformation of units eV <-> K, Pa <-> Torr, T <-> Gauss, an so on
  • Dispersion relation of common waves
  • the legend - wait for it - dary Maxwellian function and its integrations
  • A simple particle pusher in given fields
  • A Child Languir sub-package

from plasmapy.

blalterman avatar blalterman commented on June 5, 2024

from plasmapy.

StanczakDominik avatar StanczakDominik commented on June 5, 2024

Just a quick update on a few of the points raised, keep up the good discussion: would everyone be okay with using github issues instead of a todo file? Everyone can open them, they're easier to track than a single file... it just seems better than a static file in most respects, as long as we keep using them dilligently.

We already kind of have a particle pusher in #54, I'll be finishing that (docs etc) today or tomorrow. The summer heat is making it difficult to work on this :(

from plasmapy.

antoinetavant avatar antoinetavant commented on June 5, 2024

@StanczakDominik I'm not used to github projects, so I'll refer to your opinion. However, if I like Github issues to deal with each issue, I think it is quite scattered. I like Todos because it sums up the goal of the project.

from plasmapy.

blalterman avatar blalterman commented on June 5, 2024

from plasmapy.

SolarDrew avatar SolarDrew commented on June 5, 2024

I agree we should stick to GitHub issues for tracking new features, it keeps bundled in with the codebase itself. We can group issues together into self-contained projects (e.g. v0.1) and if we don't already we should have a 'Feature request' tag for easily searching issues that relate to new things we want to implement.

We also might want different sub-packages for data analysis, simulation, etc.
We do :) (or at least we intend to).

Easy transformation of units eV <-> K, Pa <-> Torr, T <-> Gauss, an so on

astropy.units should make that fairly straightforward.

Dispersion relation of common waves

See #11.

A simple particle pusher in given fields

See #40, #54.

@antoinelpp, the other suggestions are good :) Do you want to go ahead and make some issues for them?

@bla1089, to clarify, you're saying we need data reduction and curve fitting? Could you expand a little on what pandas' groupby does?

from plasmapy.

antoinetavant avatar antoinetavant commented on June 5, 2024

@SolarDrew I'm waiting for the unit discussion to finish and the PR #54 to be merged. But I'll make some issues !

Easy transformation of units eV <-> K, Pa <-> Torr, T <-> Gauss, an so on

astropy.units should make that fairly straightforward.

Gauss, Torr and eV are not common units. I don't think there already are functions do convert them directly.

from plasmapy.

SolarDrew avatar SolarDrew commented on June 5, 2024

I'm waiting for the unit discussion to finish and the PR #54 to be merged. But I'll make some issues !

Cool, no problem :)

Gauss, Torr and eV are not common units. I don't think there already are functions do convert them directly.

True. To clarify: astropy.units allows you to define units and equivalencies between units that aren't technically converible (e.g. nm <--> Hz for wavelength/frequency). What I meant was that it should (in theory) be reasonably simple to use these systems to implement the conversions you want, rather than that they would just work out of the box (although Gauss actually is supported in astropy already and does just work).

from plasmapy.

blalterman avatar blalterman commented on June 5, 2024

from plasmapy.

SolarDrew avatar SolarDrew commented on June 5, 2024

For the record I'm not arguing that pandas and xarray aren't good tools. I guess what I should have asked was "what does groupby do that we need in PlasmaPy?"

This issue asks about what tasks people want to accomplish - I think we should decide first what physics people want to do, and then talk about what tools we want to do it with.

from plasmapy.

blalterman avatar blalterman commented on June 5, 2024

from plasmapy.

lemmatum avatar lemmatum commented on June 5, 2024

My focus is mostly on experiments in high energy density plasmas (though I do some theory), and most of my tasks involve processing raw data into some usable format (e.g. applying calibrations) and then doing some plasma physics analysis with that processed data (e.g. fit simulations, take line ratios to get temperature, run processed data through an inverse model for the diagnostic to get plasma parameters). Here we can add functions like the Saha-Boltzmann equation; Bohm-Gross dispersion equation; a calibration function that given a measured emission spectrum, a whitelight calibration, and a dispersion calibration, then does the correct interpolations and applies those calibrations to the raw measurement and correctly propagates the uncertainties. (On this note, I am trying to make an error propagation class in python. This would handle asymmetric error propagation, unlike other python projects I've seen.)

Another side to experimental plasma physics is exploratory data analysis, mainly plotting and looking for patterns in data when there is no readily applicable theory. On this front it would be handy to have some ready-made plotting utilities and some more advanced data analysis techniques that aren't already found in other packages (e.g. covariance mapping)

And yet another side of this is diagnostic design, where you want to model the geometry of your diagnostic to make sure you are measuring the right thing, or model a certain signal propagating through your optical lines. Here we can add things like the thin lens formula, Bragg diffraction, grating diffraction, etc.

I would suggest putting most of this stuff into a separate "plasmapy/diagnostics" directory and then further separate these by category (e.g. optics, lasers, spectrometers). Other things that overlap could go in other sections. For example, I often use a vector class that I created for simulations with 3D distribution functions or for raytracing. Something like this could go under "plasmapy/math"

from plasmapy.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.