Prep for 0.3.0 release.

[drowenhorst-nrl]

Update change log, version number.
Signed-off by: David Rowenhorst [email protected]

[hakonanes]

I can have a look at the docs and the one failing test by early next week, if you want.

[drowenhorst-nrl]

Sorry for the rush, I am about to head off on some travel, and wanted to get this out the door. Andrew Polonski was curious about some updates, and I thought this looked good enough for release. I, and a few others at the lab, were complaining that NLPAR on large scans takes long enough that it is a pain to rerun each time, but also the extra file storage is a bit of an issue; keeping an extra 60-150GB file around starts to add up. Thus, the goal was to get NRLPAR fast enough that a user can conceivably trash the NLPAR file. I think this release does that - I can NLPAR process a 60GB scan (120 x 120 patterns) in about 4 minutes now, before was about 45 minutes. PyEBSDIndexing takes 2.75 minutes to then index that same scan.

Thanks for taking a look, but I think I figured out what was happening on the failing test ... I hacked together a more complicated pyopencl test in __init__.py, which not only checks for the installation of pyopencl, but also that at least one GPU is found. In the test package, it was only really checking to see if the pyopencl is importable (I think that is a real word). I changed the test to also check if it can find at least one GPU. Perhaps it could be better by not just catching any type of exception and assigning it a ImportError(), but near as I can tell, there are a bunch of possible errors that pyopencl might throw before it finds a GPU (could fail to find a platform, or might fail to find a GPU or ...).

I will admit that I did not recheck the documentation to make sure it is all compatible with the new changes, but in the testing I did do (and a few others here at the lab), I think I got everything figured out to be transparent to the user.

Finally - there are some hidden features regarding making pattern masks (becoming an issue with some of the DE detectors) that DO require a good bit of documentation that are actually in this release, but have no instructions. I want to write up some helper classes/functions to make that easier. Currently, setting the rhomask to something either <0.0 or >1.0 does some interesting things. < 0.0 --> instead of a fraction of the minimum detector size (default for 0.0-->1.0, it uses a fraction of the maximum distance of the detector size. > 1.0 --> acts as a dilation filter on anything that is labeled as not viable on the detector.