<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">GrADS and the GrADS Data Server are in maintenance mode. There have been updates since 2019 that are documented here:<br>
<a href="https://github.com/j-m-adams/GrADS/blob/master/ChangeLog" title="Original URL:
https://github.com/j-m-adams/GrADS/blob/master/ChangeLog
Click to follow link.">https://github.com/j-m-adams/GrADS/blob/master/ChangeLog</a>
<br>
<a href="https://github.com/j-m-adams/GrADS-Data-Server/blob/main/ChangeLog">https://github.com/j-m-adams/GrADS-Data-Server/blob/main/ChangeLog</a>.
<br>
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.<br>
--Jennifer<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;color:#212121">-- </span><span style="font-size:9.0pt;color:black"><br>
<b>Jennifer Miletta Adams</b><br>
Senior Scientific Software Developer<br>
Goddard Earth Sciences Data and Information Services Center (GES DISC)</span><span style="font-size:12.0pt;color:#212121"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;color:black">NASA/GSFC, Code 619</span><span style="font-size:12.0pt;color:#212121"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;color:#404040">Building 32, Room S159</span><span style="font-size:12.0pt;color:#404040"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#212121"> </span><span style="font-size:12.0pt;color:#212121"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span lang="EN-AU" style="font-size:12.0pt;color:black">From:
</span></b><span lang="EN-AU" style="font-size:12.0pt;color:black">gradsusr <gradsusr-bounces@gradsusr.org> on behalf of mike@weatherwatch.net.au <mike@weatherwatch.net.au><br>
<b>Date: </b>Thursday, November 30, 2023 at 9:02 PM<br>
<b>To: </b>gradsusr@gradsusr.org <gradsusr@gradsusr.org><br>
<b>Subject: </b>[EXTERNAL] [BULK] [gradsusr] Future of GRADS<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-AU" style="font-size:11.0pt;mso-ligatures:standardcontextual">Hi all,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-size:11.0pt;mso-ligatures:standardcontextual"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-size:11.0pt;mso-ligatures:standardcontextual">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-size:11.0pt;mso-ligatures:standardcontextual"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-size:11.0pt;mso-ligatures:standardcontextual">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).
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-size:11.0pt;mso-ligatures:standardcontextual"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-AU" style="font-size:11.0pt;mso-ligatures:standardcontextual">Cheers, Mike<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>