Weather data time series portrayal and delivery

[alexander-petkov]

Synopsis

The RTMA dataset represents near-surface observed weather conditions. The system produces hourly analyses at 2. 5 km resolution for the Conus NDFD grid, 3 km for the Alaska NDFD grid and 2.5 km for the Hawaii, Puerto-Rico and Guam NDFD grids.

Website: https://nomads.ncep.noaa.gov/txt_descriptions/RTMA_doc.shtml

Data download: ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/rtma/prod/

NDFD (National Digital Forecast Database) is a suite of forecast products. Website: https://www.ncdc.noaa.gov/data-access/model-data/model-datasets/national-digital-forecast-database-ndfd

Global Forecast System (GFS)

The Global Forecast System (GFS) is a weather forecast model produced by the National Centers for Environmental Prediction (NCEP). Dozens of atmospheric and land-soil variables are available through this dataset, from temperatures, winds, and precipitation to soil moisture and atmospheric ozone concentration.

Website: https://www.ncdc.noaa.gov/data-access/model-data/model-datasets/global-forcast-system-gfs

Question: I assume we need the Forecast datasets... Probably the .5 deg data.

Data URL: ftp://nomads.ncdc.noaa.gov/GFS/Grid3

[alexander-petkov]

What is ds.sky.bin?

[wmjolly]

Yes, we want the GFS Forecast. Probably @ 0.5 degrees.

ds.sky.bin is the hourly skycover / cloud cover file from RTMA.

[wmjolly]

Do you have what you need to setup the data downloads for RTMA, NDFD and GFS? I already have the RTMA and NDFD coming into the server but it could be better.

[alexander-petkov]

Do you have what you need to setup the data downloads for RTMA, NDFD and GFS?

I could use help with verifying the data sources for download. Also, the list of variables we need to portray via web services.

I followed the crontab source for the RTMA data. I have a 14-day archive downloaded. I am working on getting it displayed as a multi-dimensional coverage in Geoserver.

[wmjolly]

The NDFD files are already downloading once per day. They are GRIB2 files but have a .bin extension. They are all here: /home/mjolly/n2n/degrib/data/ndfd/conus

[wmjolly]

They are downloaded using the DEGRIB tool.

[alexander-petkov]

Variables: I have hand written notes with the following variables:

1. Temp
2. RH
3. Wind
4. Dewpoint

For some reason I remember a more extensive list. I'll keep looking for it through communication archives.

[alexander-petkov]

Variables: I have hand written notes with the following variables:

1. Temp
2. RH
3. Wind
4. Dewpoint

This list mirrors the one from wfas net: Edit: except for rain. I should probably stop by for a consult to confirm this.

[wmjolly]

We need:

1. Temp
2. RH
3. Wind speed
4. Wind direction
5. Rainfall 6: Cloud cover

That'll get us close.

MJ

On Mon, Jul 1, 2019 at 10:32 AM alexander-petkov notifications@github.com wrote:

Variables: I have hand written notes with the following variables:

1. Temp
2. RH
3. Wind
4. Dewpoint

This list mirrors the one from wfas net: [image: Weather variable list from wfas.net] https://user-images.githubusercontent.com/39599557/60452243-5c51df00-9beb-11e9-9c3a-933d12dbc4fa.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexander-petkov/wfas/issues/7?email_source=notifications&email_token=AA4G3D24PZDAF6WH5NMPMQ3P5IWRBA5CNFSM4HS2F7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY6VUPA#issuecomment-507337276, or mute the thread https://github.com/notifications/unsubscribe-auth/AA4G3D7M2NMKFXQNUFEAARTP5IWRBANCNFSM4HS2F7BA .

[wmjolly]

RAWS_ELEVATION: 4025 RAWS_WINDS: Ave RAWS_UNITS: English

Year Mth Day Time Temp RH HrlyPcp WindSpd WindDir CloudCov 2019 1 1 0100 -9 73 0.00 2 166 0 2019 1 1 0200 -9 73 0.00 2 169 0 2019 1 1 0300 -6 75 0.00 2 165 0 2019 1 1 0400 -6 75 0.00 2 166 0 2019 1 1 0500 -5 77 0.00 2 126 0 2019 1 1 0600 0 79 0.00 2 132 0 2019 1 1 0700 4 76 0.00 3 132 0 2019 1 1 0800 7 74 0.00 7 206 0 2019 1 1 0900 10 71 0.00 10 221 0 2019 1 1 1000 12 68 0.00 7 217 77 2019 1 1 1100 17 57 0.00 10 211 14 2019 1 1 1200 22 52 0.00 8 219 0 2019 1 1 1300 27 45 0.00 7 234 0 2019 1 1 1400 31 38 0.02 7 184 100 2019 1 1 1500 26 44 0.01 8 174 100 2019 1 1 1600 25 47 0.00 5 179 0

[alexander-petkov]

Units of measure from the Flammap docs:

It is not clear what is the area unit for HrlyPcp--usually in the weather model data Precip is in kg/sq. m.

[alexander-petkov]

WindSpd For now, I am converting m/s to kph in java:

case "Wind_speed":
    /**
     * Might need to convert this to MPH if English units are used,
     * check with Chuck McHugh
     */
    Quantity<Speed> ws = Quantities.getQuantity(val, Units.METRE_PER_SECOND)
                    .to(Units.KILOMETRE_PER_HOUR);
    wr.ws = ws.getValue().floatValue();
    break;

I need to clarify how it is understood where MPH or KPH is used--maybe whether English units are specified?

[wmjolly]

ENGLISH units specify Wind Speed in Miles / Hour and METRIC units specify Wind Speed in Kilometers / Hour. I don't think FlamMap uses M/S anywhere.

MJ

On Tue, Oct 8, 2019 at 8:39 PM alexander-petkov notifications@github.com wrote:

WindSpd For now, I am converting m/s to kph in java:

case "Wind_speed": /* Might need to convert this to MPH if English units are used, check with Chuck McHugh / Quantity ws = Quantities.getQuantity(val, Units.METRE_PER_SECOND) .to(Units.KILOMETRE_PER_HOUR); wr.ws = ws.getValue().floatValue(); break;

I need to clarify how it is understood where MPH or KPH is used--maybe whether English units are specified?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexander-petkov/wfas/issues/7?email_source=notifications&email_token=AA4G3D2V72S3JRLI3BEHHZLQNU763A5CNFSM4HS2F7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAWKCZY#issuecomment-539795815, or mute the thread https://github.com/notifications/unsubscribe-auth/AA4G3D7H4D7CU6OBCEK7BODQNU763ANCNFSM4HS2F7BA .

[alexander-petkov]

Might need to adjust the time span for the Weather time series, due to the fact that NDFD Precip (qpf) is limited to 3-day period (see comment in NDFD ticket)

Possible solutions:

1. 10-day RTMA-->3 day NDFD-->13 day GFS data
2. 10-day RTMA->16-day GFS, and abandon NDFD

[wmjolly]

Option 1 would work. 10 Day RTMA-> 3 Day NDFD-> 13 Day GFS.

Also, there is another higher resolution forecast product for Precip called QPF (Quantitative Precipitation Forecast) and it is available daily for 7 days. We could do something with that and the Probability of Precip (POP) layer from NDFD.

On Tue, Oct 29, 2019 at 6:34 AM alexander-petkov notifications@github.com wrote:

Might need to adjust the time span for the Weather time series, due to the fact that NDFD Precip is limited to 3-day period.

Possible solutions:

1. 10-day RTMA-->3 day NDFD-->13 day GFS data
2. 10-day RTMA->16-day GFS, and abandon NDFD

https://raw.githubusercontent.com/alexander-petkov/wfas/master/random%20files/LfiCkGzUapo.jpg

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexander-petkov/wfas/issues/7?email_source=notifications&email_token=AA4G3D3VRTEEUJ46ZDXH3LDQRAUU3A5CNFSM4HS2F7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECQKCBI#issuecomment-547397893, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4G3D3TIFEPZ24NNKYCTV3QRAUU3ANCNFSM4HS2F7BA .

[alexander-petkov]

I am using QPF from the NDFD archive, bit it is for days 1-3 (72 hours), and absent from days 4-7: ftp://tgftp.nws.noaa.gov/SL.us008001/ST.opnl/DF.gr2/DC.ndfd/AR.conus/

Also, I dropped the pop12 dataset.

[wmjolly]

We should keep the POP12 dataset. Also, here is a QPF data source that is better. Not everything we need but still better;

https://www.wpc.ncep.noaa.gov/qpf/qpf2.shtml

On Tue, Oct 29, 2019, 08:01 alexander-petkov notifications@github.com wrote:

I am using QPF from the NDFD archive, bit it is for days 1-3 (72 hours), and absent from days 4-7: ftp://tgftp.nws.noaa.gov/SL.us008001/ST.opnl/DF.gr2/DC.ndfd/AR.conus/

Also, I dropped the pop12 dataset.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexander-petkov/wfas/issues/7?email_source=notifications&email_token=AA4G3D5MRHQZY4YPUSQX2GDQRA62VA5CNFSM4HS2F7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECQS6WI#issuecomment-547434329, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4G3D6C72YLAVY4IGBXZJ3QRA62VANCNFSM4HS2F7BA .

[alexander-petkov]

I've deployed the WeatherStream WPS to the Geoserver cluster on Plume:

I added additional input, so I could query archives individually for testing.

It takes 38 minutes to generate a WxS file from all observed and forecast data. I will have to look to optimize the mosaics further.

Sample XML-encoded request:

<?xml version="1.0" encoding="UTF-8"?><wps:Execute version="1.0.0" service="WPS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.opengis.net/wps/1.0.0" xmlns:wfs="http://www.opengis.net/wfs" xmlns:wps="http://www.opengis.net/wps/1.0.0" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" xmlns:wcs="http://www.opengis.net/wcs/1.1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsAll.xsd">
  <ows:Identifier>gs:WeatherStreamWPS</ows:Identifier>
  <wps:DataInputs>
    <wps:Input>
      <ows:Identifier>Longitude</ows:Identifier>
      <wps:Data>
        <wps:LiteralData>-115</wps:LiteralData>
      </wps:Data>
    </wps:Input>
    <wps:Input>
      <ows:Identifier>Latitude</ows:Identifier>
      <wps:Data>
        <wps:LiteralData>37</wps:LiteralData>
      </wps:Data>
    </wps:Input>
    <wps:Input>
      <ows:Identifier>English units</ows:Identifier>
      <wps:Data>
        <wps:LiteralData>false</wps:LiteralData>
      </wps:Data>
    </wps:Input>
    <wps:Input>
      <ows:Identifier>Archive</ows:Identifier>
      <wps:Data>
        <wps:LiteralData>all</wps:LiteralData>
      </wps:Data>
    </wps:Input>
  </wps:DataInputs>
  <wps:ResponseForm>
    <wps:RawDataOutput mimeType="application/octet-stream">
      <ows:Identifier>output</ows:Identifier>
    </wps:RawDataOutput>
  </wps:ResponseForm>
</wps:Execute>

[wmjolly]

Great work Alex! Any thoughts on why it is so slow? 38 minutes seems like a really long time to extract a single point.

MJ

On Mon, Nov 4, 2019 at 3:11 AM alexander-petkov notifications@github.com wrote:

I've deployed the WeatherStream WPS to the Geoserver cluster on Plume: [image: Screenshot from 2019-11-04 02-54-27] https://user-images.githubusercontent.com/39599557/68112455-93dcda80-feae-11e9-9c5b-469d48955364.png

I added additional input, so I could query archives individually for testing.

It takes 38 minutes to generate a WxS file from all observed and forecast data. I will have to look to optimize the mosaics further.

Sample XML-encoded request:

<?xml version="1.0" encoding="UTF-8"?>

gs:WeatherStreamWPS Longitude -115 Latitude 37 English units false Archive all output — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or unsubscribe .

[alexander-petkov]

Reading 1440 images just for RTMA... I am now trying tiling for the Geotiffs, seeing if that helps.

[alexander-petkov]

Tiling helped quite a bit--simply adding 'TILED=yes' to gdal_translate proved beneficial.

Generating a WxS file for the RTMA archive completed under 13 minutes, previously was 33 minutes.

Consequent runs showed times under 6 minutes, probably due to caching.

Next thing to try is a smaller tile size, the default is 256x256.

UPDATE: Changing default tile size has no effect on query times.

[alexander-petkov]

I have replicated the RTMA archive on ,my laptop. Querying the archive takes around a minute and 20 sec.

Under the docker setup, I have gotten the process to run as fast as ~6 minutes. There is a bottleneck due to virtualization, or docker, or both...

I have also noted that resource availability and allocation plays a noticeable role. Doubling the number of CPUs and RAM to a VM instance helped some, but not as much as I would have thought--time for executing the WPS was reduced by about 30%.

Next step I will take--stand a Geoserver instance on a VM without Docker, and measure performance again. Also adjust the amounts of min and max RAM available to Tomcat

UPDATE: I installed Geoserver outside of Docker on a VM, using ceph mounted storage. The tests confirmed similar times--around 6 minutes for reading single point values for the entire RTMA archive. Bumping minimum RAM to 4 Gigs (up from 2) made no measurable difference in performance tests. Docker containers are not the bottleneck, which is good. That leaves either Ceph, or VM performance as suspects...

UPDATE 2: Ceph seems to be the culprit, at least one of them.

Testing read/write speed on my laptop SSD:

dd if=/dev/urandom of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.92415 s, 136 MB/s

sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"

dd if=./largefile of=/dev/null bs=4k
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.9312 s, 366 MB/s

Testing read/write speed on a VM with mounted Ceph storage:

sudo dd if=/dev/urandom of=/mnt/cephfs/tmp/largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.4375 s, 167 MB/s

sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"

sudo dd if=/mnt/cephfs/tmp//largefile of=/dev/null bs=4k
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 10.4811 s, 102 MB/s

I will update the Ceph cluster to 10 Gig Ethernet when I get back.

[alexander-petkov]

I wrote a threaded version of the Weather data CSV export WPS. This version runs a number of threads equal to the number of variables in an archive (6 in our case)

Plotted results over 20 runs (RTMA archive):

The first data point in the single threaded version can be ignored, due to initial first reading without cache.

Multiple threads version helps to increase performance around 28% on average. Not orders of magnitutde as one might think, but still a considerable increase in speed... Might be because the Imagemosaic plugin is already threaded

Also, my laptop has 4 cores--assigning more cores to a VM instance might improve performance further.

[wmjolly]

That does look better. So is that saying that they take ~30 seconds per query?

On Wed, Jan 22, 2020 at 2:57 PM alexander-petkov notifications@github.com wrote:

I wrote a threaded version of the Weather data CSV export WPS. This version runs a number of threads equal to the number of variables in an archive (6 in our case)

Plotted results over 20 runs (RTMA archive): [image: Weather CSV export--multiple vs single thread version] https://user-images.githubusercontent.com/39599557/72937553-966d0480-3d26-11ea-83df-8f23cd1d86dc.png

The first data point in the single threaded version can be ignored, due to initial first reading without cache.

Multiple threads version helps to increase performance around 28% on average. Not orders of magnitutde as one might think, but still a considerable increase in speed... Might be because the Imagemosaic plugin is already threaded

Also, my laptop has 4 cores--assigning more cores to a VM instance might improve performance further.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexander-petkov/wfas/issues/7?email_source=notifications&email_token=AA4G3D7ZGGW4ZNUZUPDFEILQ7C6MNA5CNFSM4HS2F7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJVIA2Q#issuecomment-577405034, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4G3D6GPC3ZC5A6VM3IICLQ7C6MNANCNFSM4HS2F7BA .

[alexander-petkov]

That does look better. So is that saying that they take ~30 seconds per query?

For RTMA--which is the bulk of all datasets, in terms of number of scenes, as well as size.

[alexander-petkov]

Here is the plotted speed test result of the Weather Stream WPS deployed on AWS.
The result is from reading the RTMA archive only. The data is hosted on a EBS volume, attached to the VM. The VM instance has 4 cores and 8G RAM assigned to it.

Here are the numbers (in seconds) for 20 runs:

threaded	single
29.976	72.35
30.641	72.051
30.735	78.48
30.666	76.778
30.733	71.642
30.667	73.259
30.72	74.723
30.683	76.548
30.7	75.011
30.711	76.067
30.701	82.314
30.705	79.368
30.699	75.817
30.697	76.701
30.722	82.249
30.687	74.603
30.719	74.367
30.685	72.444
30.721	71.601
30.698	75.92

The multi-threaded version of the WPS is 50-60% faster than the single-threaded version. Increasing number of cores and RAM might improve speed even further.

[wmjolly]

That's looking better already

On Tue, Jan 28, 2020, 11:51 alexander-petkov notifications@github.com wrote:

Here is the plotted speed test result of the Weather Stream WPS deployed on AWS. The result is from reading the RTMA archive only. The data is hosted on a EBS volume, attached to the VM. The VM instance has 4 cores and 8G RAM assigned to it.

[image: Single vs Threaded] https://user-images.githubusercontent.com/39599557/73294293-c9017c00-41c2-11ea-8405-6faf8532b865.png

Here are the numbers (in seconds) for 20 runs: threaded single 29.976 72.35 30.641 72.051 30.735 78.48 30.666 76.778 30.733 71.642 30.667 73.259 30.72 74.723 30.683 76.548 30.7 75.011 30.711 76.067 30.701 82.314 30.705 79.368 30.699 75.817 30.697 76.701 30.722 82.249 30.687 74.603 30.719 74.367 30.685 72.444 30.721 71.601 30.698 75.92

The threaded version of the WPS is 50-60% faster than the single threaded version. Increasing number of cores and RAM might improve speed even further.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexander-petkov/wfas/issues/7?email_source=notifications&email_token=AA4G3D5HEQMSDN2PXTUA6TLRAB5CDA5CNFSM4HS2F7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKEOX4Q#issuecomment-579398642, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4G3D5AXVW3Y2FTXDW2QC3RAB5CDANCNFSM4HS2F7BA .

[alexander-petkov]

Querying all 3 archives takes approx 45 seconds.

[wmjolly]

What format does it produce? The FlamMap one?

On Tue, Jan 28, 2020, 19:03 alexander-petkov notifications@github.com wrote:

Querying all 3 archives takes approx 45 seconds.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexander-petkov/wfas/issues/7?email_source=notifications&email_token=AA4G3D5ARVOJKB6YAD5DTC3RADIVPA5CNFSM4HS2F7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKFSWQA#issuecomment-579545920, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4G3D7YD3OVQ7SD7BQ5QJTRADIVPANCNFSM4HS2F7BA .

[alexander-petkov]

What format does it produce? The FlamMap one?

Yes

[wmjolly]

We should share the link with Chuck

On Tue, Jan 28, 2020, 20:57 alexander-petkov notifications@github.com wrote:

What format does it produce? The FlamMap one?

Yes

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexander-petkov/wfas/issues/7?email_source=notifications&email_token=AA4G3DY3GNYNQ6SDDRSQBMDRADWBNA5CNFSM4HS2F7BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKFYSHY#issuecomment-579569951, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4G3DZYMIBU4K2D4MH7FL3RADWBNANCNFSM4HS2F7BA .

[alexander-petkov]

During last Friday's conversation with Reggie, he suggested that it would be nice if the WeatherStream export supported data extraction for start and end dates.

I can definitely see the value of adding additional inputs to restrict the date range(s).

Would there be need at all then to specify which archive to query? Should I take that out? Would users be expected to know what are the RTMA, NDFD, and GFS datasets?

[wmjolly]

I think leaving the archive in is fine, just make sure it defaults to all of them.

As for the date range, maybe we define a date range that can include any combination of the archives?

So if you just wanted 3 days of RTMA and 2 days of forecast, if you put in the correct dates, you get both?

On Tue, May 12, 2020 at 4:12 PM alexander-petkov notifications@github.com wrote:

During last Friday's conversation with Reggie, he suggested that it would be nice if the WeatherStream export supported data extraction for start and end dates.

I can definitely see the value of adding additional inputs to restrict the date range(s).

Would there be need at all then to specify which archive to query? Should I take that out? Would users be expected to know what are the RTMA, NDFD, and GFS datasets?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexander-petkov/wfas/issues/7#issuecomment-627626190, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4G3DYJ4YBIHTF7WPTBQG3RRHCTJANCNFSM4HS2F7BA .

[alexander-petkov]

Yes, currently all 3 datasets are queried by default. So, at the end of RTMA, NDFD data is queried, and at the and of that, GFS follows.

[alexander-petkov]

This commit adds Start and End date as optional arguments for which the Weatherstream output can be restricted.

[alexander-petkov]

Weather dataset summary:

Name	Type	Day Span	Time resolution
RTMA	Observations	Last 10 days	Hourly
NDFD	Forecast	3 days	Hourly for 2.5 days, then every 3 hrs
GFS	Forecast	14 days	Hourly for the first 5 days, then every 3 hrs
HRRR	Forecast	1.5 days (36 hours)	Hourly
NBM	Forecast	1.5 days (36 hours)	Hourly

[alexander-petkov]

Here is an idea for faster mosaic reading:

1. Tile the raster scenes horizontally, for example 3x3
2. Have a separate mosaic for each row/column: 01, 02, 03, 11, and so on.
3. Include an index shapefile (or use a Postgis-based index), for targeting a specific "sub-mosaic" from user coordinates.

I think that this would reduce disk access times significantly, or even after a mosaic is cached. Maybe reduced caching will be a benefit to using less memory?

Experiment with this approach, and measure performance. I think this will certainly be a benefit when using a 20-year data archive.

[alexander-petkov]

Nice speed improvements as a result of

1. Turning off logging in Geoserver.
2. Changing data type to Int16 on most variables when making Geotiffs, (except for Total precip).

Latest performance times are about 8 seconds for a WeatherStream point query.