lo-co/atm-py

Set of python packages for processing atmospheric data.

A few words about this repository...

This repo is currently under heavy revision in preparation for actual publication. Issues that we will be investigating are:

• Package and repository structure
• Unit testing for entertaining pull requests
• Continuous integration for managing the code

It is not advisable to fork this repository until the structure is hardened. At that time, this readme will be replaced.

atm-py's Issues

Documentation?

It looks like far and away the most popular format for documenting python modules is reStructuredText with Sphinx for generating the documentation for this. Any thoughts?

Also, starting a hacking guide in the top-level-directory in the NewStructure branch...

Add unit tests

We will run unit tests for all new code. Add tests that can be run via nose or the python UnitTest object. nose allows us to run tests from the top level and I believe we can run these automatically in GH.

Add tests folder to each module. These folders should not be modules themselves (i.e. there should be no __init.py__ in the folder). I will provide some examples of this and explain how to do this in HackThis.

Using external libraries

So, my SMPS module needs a lot of work and I noticed that I have imported the following libraries:

• tkinter
• matplotlib
• pandas

I use tkinter to produce a file dialog, matplotlib to plot some results and pandas to read in data. My gut feeling is that none of these are necessary and that basically we want to provide tools for analysis and not a graphical package or a package tied to a specific data format. In this instance, the use of pandas.read_csv presupposes a file format that is not some kind of industry standard. In addition, tkinter is kind of tacked on to allow the user to choose a file but there is also a tool for programatically allowing the user to provide data files. So, my conclusion is that none of this is necessary for this module. My question is - when is it appropriate to require external modules?

Moving water saturation out of atmosphere.py

Move water saturation equations into file called water.py (or some variant thereof), changing name of atmosphere.py to gas_props.py.

Adding density calculation for gases to ``Gas`` object

As it says. Will override in Air to calculate as a function of t and p as well as water content as in NewStructure.

Builds failing due to poor travis-ci support

Update script to install using miniconda as found here.

what is the folder "/__pycache__" good for?

I guess that should go into .gitignore?

clean up that mess

Everyone! :-)
give some suggestions about how to rearrange the repository!!!!

Proposal for sampling efficiency

I haven't thought this out to much yet, but I think that we might be able to provide a nicer API for the sampling efficiency. My suggestion is to have a root class that is a composition of it's children. The root class has a single method get_efficiency or something like that that will serve as the signature for returning an efficiency or array of efficiencies. This class might also have some attributes such as diameter and efficiency. Then, the children would implement the details and decorate the parent with methods and attributes specific to that implementation. The get_efficiency in the parent object would then be a product of the overriden methods in the children. This sounds confusing so I will try to show what I mean. All of Hagen's calculations in the existing module would remain the same.

Mie code

So, there is Mie code in a couple of places in the libarary: in the POPS instrument folder and in it's own folder. The POPS implementation is kind of chaotic and not well documented while the other library is pulled from an external library and likely needs some investigating. Gavin - you have done a lot of work with Mie code - do you think you could implement something? My suggestion is to create a new branch based on the ''NewStructure'' branch and add routines in their own folder under aerosols/phys/opt (I realize that is not there right this moment, so we need to add this too).

Need solid naming conventions

Obviously as described in #3 we need some standardization. Discuss this here.