NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Thank you, Stonie. However, this misunderstanding occurred because of a major change in how the LDM is being updated, enhanced, and modified without any prior notification of this change, or any input from the university community. And this is entirely my point: if there are going to be significant changes in software or protocols, we need to know and understand why something is to be changed, and with input and feedback from the UNIDATA community. This is an attitude that starts at the top, not just with you. It should not have taken two emails that were quite unprofessional to know what is happening nearly a year after the fact on one aspect of UNIDATA’s software efforts. And as Mike Zuranski pointed out, the fact that there has been no communication from the top…other than “here’s a summary of what we’re doing this right now” in monthly newsletters is anything but good for this community. As others have expressed, this is very disappointing…and colleges and Universities are being left not on the sidelines, but on the outside of the stadium trying to listening to the PA system to know what the score is. That simply is not how UNIDATA is designed to be, regardless of staff size. Since others have noted this has gone on for years, where is the UNIDATA leadership on this? What is the Users Committee doing now about this? Gilbert Sebenste Meteorology Support Analyst [cid:image001.png@01DAE9A9.DC4B2CF0] From: Stonie Cooper <cooper@xxxxxxxx> Sent: Thursday, August 8, 2024 2:44 PM To: Sebenste, Gilbert <sebensteg@xxxxxxx> Cc: ldm-users@xxxxxxxxxxxxxxxx; mcidas-x@xxxxxxxxxxxxxxxx; NOAAPORT <noaaport@xxxxxxxxxxxxxxxx>; mcidas@xxxxxxxxxxxxxxxx; conduit@xxxxxxxxxxxxxxxx Subject: [External] Re: [mcidas-x] Concerns about the future of UNIDATA CAUTION: This email originated from outside of COD’s system. Do not click links, open attachments, or respond with sensitive information unless you recognize the sender and know the content is safe. I've been asked to clarify my reply to Gilbert. I am only speaking of the LDM, and support for the IDD. I completely understand the concern for the support for the Unidata portfolio as a whole, but my reply was addressing the concern Gilbert indicated due to the lack of source code check-ins on the LDM github, and the implication that nothing was being done. Which is furthest from the case, but the release of a new version will occur with control and extensive testing . . . and the fact is, Steve Emmerson’s code is solid and incredibly stable. In the name of transparency: what I am working on are enhancements and moving source code codification out of the source and into configuration files. Such as feedtypes, product ID assignments within noaaportIngester, and other items that are currently articulated as #defines in the source. This is to make it much easier to respond to changes on the satellite feeds without needing new source code – i.e. changes to the configuration file, and a “restart.” As part of this paradigm, the IDD will act as a delivery mechanism for updating configuration files, where new configurations updated at Unidata will be inserted on an isolated feedtype at the IDD head, and those that wish to have those updates stored local to their installations when they come out can create the appropriate pqact entries to save them off. Or simply download them from our website. One of the first tasks that I was given when I came to Unidata roughly 18 months ago was to extend the LDM with a client installation that can be run without needing to be root or have root access. I had completed the proof of concept of this shortly after arriving, which results in binaries for the most utilized Linux distributions and versions. As I am still updating aspects of the LDM source to accommodate this paradigm yet maintain the current install paradigm, those binaries will be made available for the user community with the new source version. This also has classroom activity in mind, as multiple LDM sessions can run on the same server space but under different accounts. User accounts specific to students can stream data between each other on the same server space without impacting a larger scope, and provides first-hand experience in running the LDM. A much larger development effort is conversion of the C (and some C++) to memory safe languages. Both “Go” and “Rust” were assessed, and the current test is moving LDM helper applications to Rust for determination of fitness and difficulty of code conversion. Finally, the process of providing new versions of LDM has long since moved from true “development” mode and is fully into “maintenance” mode. There is no schedule to regular releases, but rather addressing the before mentioned enhancements and migration to configuration files . . . which require extensive code alterations, and testing. Especially with respect to feedtypes. Finally, I joined Unidata on a team of seven; I am now on a team of four, of which tasks of the three that are not longer at my Unidata team have fallen largely to me. I also have tasks and responsibilities that are outside of the LDM/IDD realm. In fact, I am right now at a TCU assisting an AIHEC student with her field project of creating a micronet on Sovereign Nations land. I will continue to perform due diligence on the support-* mechanism of addressing issues with the Unidata supported LDM, IDD, and adjacent SBN/GRB interests, but the fact is my response will generally be short, to the point, as time is of the essence. Stonie Cooper, PhD Software Engineer III NSF Unidata Program Center University Corporation for Atmospheric Research I acknowledge that the land I live and work on is the traditional home of The Chahiksichahiks (Pawnee), The Umoⁿhoⁿ (Omaha), and The Jiwere (Otoe). On Wed, Aug 7, 2024 at 4:04 PM Sebenste, Gilbert <sebensteg@xxxxxxx<mailto:sebensteg@xxxxxxx>> wrote: Good day everyone, With the recent loss of 3 extremely valuable UNIDATA staff members, I wanted to inquire UNIDATA concerning several disturbing trends that I have been seeing with the organization. And quite frankly, what I discovered is disconcerting. Over the past several years, UNIDATA has been moving away from what it was funded to do, namely: provide weather data, software, and support to the University community for teaching, and also for research: “Unidata is a diverse community of education and research institutions with the common goal of sharing geoscience data and the tools to access and visualize that data.” – https://www.unidata.ucar.edu/about With this stated goal, excellent software packages used to support the educational and research communities have either been retired. or development has stopped…with minimal input from the user community. These software packages include GEMPAK, McIDAS, LDM (which hasn’t been touched on GitHub since Steve Emmerson retired), as well as others. In fact, McIDAS was sunset without any announcement or input from universities. When I brought these concerns to the Unidata User Committee chair, Victor Gensini, I found out that he had resigned nearly a month ago. This, again, was done without any announcement to the community. The User’s Committee is much more than an advisory board; it is one of shared governance. And the decisions made over the past several years have now culminated in an utter lack of transparency with the recent loss of staff. In a scientific community, the governing process must involve transparency to the highest extent possible to maintain integrity of the staff, community, services they provide, data, and success for end users. This is already starting to have a profoundly negative effect at the College of DuPage, which prompted me to write this. Even though we are a community college, we believe in UNIDATA’s stated vision and have shared our data via our website to all. Our setup here shares the weather data as much as we are able. Without UNIDATA’s McIDAS, GEMPAK, WXP and other software packages, we will not be able to share this data with others; additionally, we will not be able to teach the next generation of students with adequate software tools in a time where interest in the atmospheric sciences is about to peak. As a result, we have started to migrate towards commercial solutions to fill in the gaps. In the first 20 years of UNIDATA, that would be unthinkable. What is being supported? IDV is being built on a dying platform (Java), with apparently very few users, and one of the two AWIPS developers was one of the three people let go. What is left? Two of these staff members were the future of UNIDATA, and the other took care of critical systems and engagement with underserved communities. Who is doing that now? Nobody has answered these questions. Complete transparency has been and continues to be absolutely critical to the success that highlighted UNIDATA’s efforts over many years. These decisions have been made in darkness. Where leadership has been required, silence has occurred. It should not have been left to a terminated employee to make that announcement on his own free will. I am saying this with all sincerity because I believe that UNIDATA is going off-mission. I am speaking out like this because I am gravely concerned that UNIDATA has lost it’s way, delving into areas beyond what it was supposed to be, while failing to maintain and flourish what it’s mission statement demands. The end result has been the loss of critical software and support that we need, as an educational institution. And let’s be blunt here: if the https://weather.cod.edu<https://weather.cod.edu/> site went down, a lot of Universities who use us would be in trouble. We know, because we see the number of “hits” from them in our web logs. And, if the LDM isn’t maintained, especially with major NOAAport/SBN feed changes on the horizon, the very backbone of the NWS data feed is in jeopardy. If McIDAS isn’t maintained, our satellite imagery goes away. And despite requests for Canadian radar data and other datasets that can be helpful (several Canadian radars cover portions of the border states reasonably well), not a yes or a no has been spoken to me. UNIDATA, as a DeSouza award winner, I beg that you turn back to what made you great: tried and true, as well as new software…data and software for all of us, and unquestionable, excellent support. With respect, Gilbert Sebenste Meteorology Support Analyst [cid:image001.png@01DAE9A9.DC4B2CF0] _______________________________________________ NOTE: All exchanges posted to Unidata maintained email lists are recorded in the Unidata inquiry tracking system and made publicly available through the web. Users who post to any of the lists we maintain are reminded to remove any personal information that they do not want to be made public. mcidas-x mailing list mcidas-x@xxxxxxxxxxxxxxxx<mailto:mcidas-x@xxxxxxxxxxxxxxxx> For list information or to unsubscribe, visit: https://www.unidata.ucar.edu/mailing_lists/
mcidas-x archives: