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/
