[gradsusr] [EXTERNAL] [BULK] Future of GRADS

[mike at weatherwatch.net.au]

Hi Jennifer,

 

Thanks you so much for all the work you and the team have been doing for
GrADS.  It's been a fundamental piece of software for use in our company and
it has definitely made life a lot easier for us.  With regards to the larger
datasets, what we've been doing now is using wgrib2 to split this into
smaller subsets for processing and it has made a significant difference.  A
meteogram for example for 0-228 hours used to take 25s on GFS data, we've
now got this down to around 6s by using a smaller temporary subset. We've
also utilised things like spawning multiple instances of grads at the same
time for "multithreading" support if generating things like soundings that
require multiple Z levels, this has also significantly improved speed to <1s
in most cases. 

 

Cheers, Mike

 

From: gradsusr <gradsusr-bounces at gradsusr.org> On Behalf Of Adams, Jennifer
M. (GSFC-619.0)[ADNET SYSTEMS INC]
Sent: Sunday, December 3, 2023 8:18 AM
To: GrADS Users Forum <gradsusr at gradsusr.org>
Subject: Re: [gradsusr] [EXTERNAL] [BULK] Future of GRADS

 

GrADS and the GrADS Data Server are in maintenance mode. There have been
updates since 2019 that are documented here:
https://github.com/j-m-adams/GrADS/blob/master/ChangeLog  
https://github.com/j-m-adams/GrADS-Data-Server/blob/main/ChangeLog. 
I am doing my best to support existing features in both packages during my
spare time or when required for operational support at GES DISC. I continue
to use GrADS almost every day, but I think it's safe to say that rewriting
the GrADS I/O layer to support multithreading is unlikely. The recent
additions to the python interface (GradsPy) allow users to leverage Python
for I/O and do analysis and plotting with GrADS, or the reverse -- GrADS
does the I/O and Python does the analysis and plotting. The get() and put()
methods allow you to pass defined variables back and forth. Maybe those
features can help you build a better workaround.
--Jennifer

 

-- 
Jennifer Miletta Adams
Senior Scientific Software Developer
Goddard Earth Sciences Data and Information Services Center (GES DISC)

NASA/GSFC, Code 619

Building 32, Room S159

 

 

 

From: gradsusr <gradsusr-bounces at gradsusr.org
<mailto:gradsusr-bounces at gradsusr.org> > on behalf of
mike at weatherwatch.net.au <mailto:mike at weatherwatch.net.au>
<mike at weatherwatch.net.au <mailto:mike at weatherwatch.net.au> >
Date: Thursday, November 30, 2023 at 9:02 PM
To: gradsusr at gradsusr.org <mailto:gradsusr at gradsusr.org>
<gradsusr at gradsusr.org <mailto:gradsusr at gradsusr.org> >
Subject: [EXTERNAL] [BULK] [gradsusr] Future of GRADS

Hi all,

 

Just wondering what the future of GRADS is at all, the last update for it
was 2019 and with GRIB data getting more and more high res and larger, GRADS
is getting left behind significantly in terms of performance.. I've got
cases now with Australian BOM ACCESS data where it can take up to 10s to
generate an image due to how high res it is thanks to GRADS being single
threaded.  

 

To overcome this, I used a "workaround" for most charts which involves
segmenting a single chart into a 3x3 grid, getting grads to execute all 9
instances in parallel and then stitch the resulting panels together in a
final image. problem is that it just doesn't look "quite right" especially
when contouring is involved.  This is the only way I can get huge data to
load up quickly.  What is everyone else using these days to handle huge GRIB
files that can generate charts quickly using multithreading? (needs to be
able to run in a headless linux environment - no GUI at all, which is why
GRADS was perfect at the time). 

 

Cheers, Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gradsusr.org/pipermail/gradsusr/attachments/20231207/ccbd71a2/attachment.html>