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> 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 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
>
>
>
>
> _______________________________________________
> 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
> For list information or to unsubscribe, visit:
> https://www.unidata.ucar.edu/mailing_lists/
>
