New Forecast Soundings Online - SHARPpy

Now that I've had time to look through some of your code - I am massively impressed. Great work by you guys. I changed the default site just fine, but if you have any hints on how to add the day-of-the-week (%a I assume?) to the upper-left timestamp displayed that'd be appreciated.
 
Got everything downloaded, ran through all the command prompts to set up, and now I'm getting an error when I try to pull up the GUI. It runs through till it stops and says "ImportError: No module named PySide." I went through Anaconda for Python and the packages. I'll keep trying what I can think of, but I'm still learning this side of things and my knowledge is limited.
 
I have it running on Ubuntu, but I set up Anaconda a while ago. "ImportError: No module named PySide" indicates that PySide is not installed correctly. Is it possible that you have more than one python environment installed on your machine?
 
Reviewing some of the old posts...

The reason the Moist Adiabats aren't drawn is because they take way too long to calculate, making the program slow to a crawl anytime the GUI is updated. Along those lines, later this year, I hope to undertake a massive rewrite of number crunching part of the code in order to speed it up.
 
I have it running on Ubuntu, but I set up Anaconda a while ago. "ImportError: No module named PySide" indicates that PySide is not installed correctly. Is it possible that you have more than one python environment installed on your machine?

I just looked, and that appears to be the case. There's a set in my anaconda folder, and there's one in my user/bin folder.
 
I just looked, and that appears to be the case. There's a set in my anaconda folder, and there's one in my user/bin folder.

Someone with more Linux experience can probably help you change the default python to Anaconda. In the meantime, try running "~/anaconda/bin/python full_gui.py" (make sure you're in the SHARPpy-master/runsharp directory when you do this.)
 
I finally stopped messing with it last night. Figured I'd be better off starting again after I get home from work tonight to take a fresh look at it. If anyone else has any tips though I'm game.
 
Are these error logs of any value? I get them periodically - this was just from running the 18Z NAM on a site in MO.Capture.JPG
 
I'm am thrilled to see this finally starting to take off and get wider use!

A quick note regarding bug reports: it helps us a TON if you open up bug reports (issues) on our GitHub page, because it notifies us when a new issue is opened, in addition to us being able to keep track of what all we need to fix in a centralized location. Keeping tabs on emails, Facebook, twitter, and now StormTrack would be a full time job in and of itself! link: https://github.com/sharppy/SHARPpy/issues

And if you aren't already aware, Greg has put together a spiffy website to help keep track of documentation, references, etc. Link: http://sharppy.github.io/SHARPpy/index.html

(if you wish to contribute to the website documentation: https://github.com/sharppy/SHARPpy/tree/gh-pages)

As Greg and Tim have said, there is still a lot of work to be done on all fronts. Documentation of features and code, implementation of placeholder features, total rewrites of older features, and new/suggested features are all on the table. Sadly, there are only 4 of us - one of us works full time at SPC, and the others are all students (myself/Greg/Tim) who do this in their free time :). That being said, suggestions, and especially bug reports, are always welcome, and it makes me excited to see this thread reviving!

Sadly, I have not been able to do as much on the development side post-AMS due to classes, but once summer rolls around, I think development will kick back into full gear. Greg and I were able to get it to this current status last summer, so who knows where we can get it by the end of this summer!

That being said, here's a roadmap of some things that myself, Greg, and Tim have planned for the future. Keep in mind that these are the big picture ideas - there are plenty of smaller issues that will be worked on (as well as introduced) in the process.

  • Re-writing the GUI to support variable DPI/4K displays.
This is likely something that I will have to take on since I wrote most of the GUI, but the initial GUI write used static pixel widths/sizes for the "pens" that draw on the GUI frame. This is great if you have only one type of display/computer. Terrible for cross computer/cross platform programming. So, I have to go in and start using percent based pixel sizes so that it's more friendly on other displays. I've already started this on a couple of the frames, but it's a very slow moving fix due to the shear number of frames used, so this likely won't be done until summer rolls around.
  • Fix NUMEROUS bugs regarding functionality on Windows
A lot of these bugs will be fixed by fixing how the "pens" draw the frames as stated above, because the text sizing/placement on Windows looks much different than on Linux/OSX. However, there are other bugs, such as no menu bar, weird placement of the window on open, the already mentioned looping bug, etc, that all arise from platform dependance.
  • A re-write of the sounding location picker/map
Tim has already made significant headway in this department, and will likely be one of the next major releases in the next month or two. We've been using static HTML pages to do the clickable map, where the new system will be fully able to pan/zoom/use custom data locations.
  • A config file based system of data source management
Speaking of custom data locations, Tim has also thrown around the beginnings of an XML based configuration system for managing custom data sources. Given the volume/variety of people wanting to use SHARPpy for their specific purposes (i.e. NWS offices, Universities, the PECAN field project), it would be really helpful to have some sort of system for putting in custom sounding locations and data. Not sure the ETA on this, as I imagine making something general and flexible enough to do this is challenging.
  • Documentation of insets/features/windows (essentially training modules)
Greg and I began some of this for our release of the program at the AMS meeting in Phoenix, but we've (specifically Greg and Tim) have added a multitude of new features that could probably use more documentation.
  • Binary distributions of the SHARPpy package
This is something I have already toyed around with and should be relatively simple to do. However, PySide has not been playing nicely with this. Ideally, it would be nice for people who are only interested in the GUI to be able to just install a binary. Not everyone is interested in using the packages for research/computational purposes. I'm hoping to at least have this done before our next major release (which we are overdue for, given the vast improvements since January).

My final remarks on this long winded post is that we are always looking for suggestions/contributions! The beauty of the open source platform of programming is that other people have the ability and power to influence the development process. Things like documentation require little to no programming experience, so contributions are not just limited to the computer literate. Also, we love hearing about how/why people are using the program, and their suggestions for improvement. We take it very seriously, because we want this to be a program people use!

Thanks for all the comments/suggestions/kind words. Hopefully we can alleviate some of the bugs/pains of the beta status of the program and keep this thing moving forward :).
 
Back
Top