You are not logged in. Click here to log in.

Application Lifecycle Management

Search In Project

Search inClear

csip-climate: Likely invalid NRCS windgen station .idx file#51262/v9
Tags:  not added yet

csip-climate: Likely invalid NRCS windgen station .idx file[BUG-51262]

Tracker: Bugs Priority: HighHigh Status: Resolved
Resolution:
Fixed
Severity:
Critical
Detected in: Release in:
--
Assigned to:
casespFeb 12 2019 22:07
Submitted by: JRCarlsonFeb 12 2019 22:07 Modified by: casespFeb 13 2019 14:47
Traceability
Loading…
Description
See email below. Also .idx and .wdb files from Larry Wagner's February 11th 11:06 am message attached, which are the files he uses for desktop WEPS. Fix probably is to replace previous wind_gen_his_upper_US_RP_NRCS.idx file used by csip-climate/m/windgen with the new one provided by Larry, test, and verify.

wind_gen_his_upper_US_PR_NRCS.idx

wind_gen_his_upper_US_PR.wdb

wind_gen_his_upper_US_PR.idx

On Feb 11, 2019, at 11:50 AM, Wagner, Larry <Larry.Wagner@ARS.USDA.GOV> wrote:

I’ve read farther into your email now. I’ve removed the JSON messages so that I can reference your earlier emails and you can get to them easier, etc.

Is it an error if the interpolation code generates potential wind stations that actually don’t exist in the wind station input file?

Yes, the windgen stations listed in an index file must be in the database or things will obviously not work correctly. The most current database file and the two index files I provided in the earlier email should be consistent in that regard. If you find that is not the case, let me know.

If number 1 above is “No”, is there a minimum number of expected result wind stations to be returned, and if that minimum is not met, is that an error that should be thrown?

This should not occur. Is it possible that the ARS (full) index is being used to find the stations for interpolation and then the NRCS index is somehow being used to locate the selected stations? If so, then the interpolation will fail if the NRCS index does not contain the station(s) in the ARS (full) index.

Other than that, I am not sure what would be causing the issue, unless the index files are not consistent with the database being used, which I mentioned in the previous questions answer.

On Dec 14, 2018, at 1:18 PM, Case,Shaun <Shaun.Case@ColoState.EDU> wrote:

I’ve run this through the debugger and found the problem:

Not every query, within the service, to parse out a wind station from the input file actually finds a wind station. The queries are generated from the interpolation code because these locations are in the interpolate boundary. For each interpolated query, one expects to find a wind station, however, they aren’t all there. Consequently, assumptions in code caused an exception.

I will add checks in the code to not allow empty wind stations to be dereferenced, and can post that to 8086.

However, we need to answer a couple of questions as well:

Is it an error if the interpolation code generates potential wind stations that actually don’t exist in the wind station input file?

If number 1 above is “No”, is there a minimum number of expected result wind stations to be returned, and if that minimum is not met, is that an error that should be thrown?

On Feb 11, 2019, at 11:06 AM, Wagner, Larry <Larry.Wagner@ARS.USDA.GOV> wrote:

The lat/lon below for Childress County, TX is showing it is in Hall County, TX for me. Not sure of why there is a discrepancy there. The field does border the county line though.

I do not have any issue running these two lat/lon locations with WebStart WEPS using the NRCS windgen index file. I have no problem with the TX run, even if I move the lat/lon location into Childress county either.

For your information, we use the “centroild of the county” lat/lon for windgen interpolations. Thus, one should always get the same interpolated windgen station within the county, regardless of the field lat/lon specified within that county.

When I moved the lat/lon into Childress county, it used different stations and weights for interpolation because of the shift into a different county. But, I had no issue with that WEPS run either.

If I run locally and switch to the ARS (full) windgen index file, I get additional windgen stations that are blacklisted in the NRCS windgen file. Here is a screenshot of the WEPS Map Viewer displaying the complete list of windgen stations, but shows the triangulation lines using only the NRCS windgen stations.

So, for the NRCS windgen index file, the triangulation lines encompassing the “centroid of the county the field lat/lon resides in (Hall county, TX here) shows the Amarillo, Lubbock and Altus AFB windgen stations would be used for interpolation. If the ARS (full) windgen index file is used then a smaller encompassing triangle (not displayed here) around the county centroid lat/lon with endpoints of Plainview/Hale, Childress Muni and Amarillo windgen stations would be used for interpolation.

Thus, I get a different interpolated windgen station using the ARS (full) windgen index file than I do with the NRCS windgen index file and thus potentially different wind erosion results.

Regardless of which index file is used though, it should not impact the ability to make a WEPS run.

For additional debugging, here are the “interpolated_weights.out” files I got with the TX runs using the two index files:

Using the NRCS windgen index file:

  1. ID |WEIGHT |NAME

723630 |0.2739365576756853 |AMARILLO ARPT(AWOS)

722670 |0.2924606516934801 |LUBBOCK INTL ARPT

723520 |0.4336027906308347 |ALTUS AFB

Using the ARS (full) windgen index file:

  1. ID |WEIGHT |NAME

723601 |0.7197657479753496 |CHILDRESS MUNI

723630 |0.1598752339471471 |AMARILLO ARPT(AWOS)

722676 |0.1203590180775032 |PLAINVIEW/HALE CO.

I’ve also included as an attachment another copy of the NRCS index file we are using for local runs (wind_gen_his_upper_US_PR_NRCS.idx). The ARS (full copy) of the index file does not include “NRCS” in the name (also included). Note that the current windgen database file should have the same name as the ARS index file, but with the extension of “.wdb” (also attached):

Note that when running WebStart WEPS with remote execution of the windgen interpolation and windgen generator, I got the same results for the lat/lons given as I did for local execution runs. So, I am apparently using a windgen CSIP endpoint that is using an NRCS version of the windgen index file. It may not be using the most current windgen database and index file, but the latest changes would not have affected these two lat/lon locations. Here are the windgen endpoint(s) I am currently using with WebStart WEPS:

<parameter> <!-- choose interpolate stations - endpoint -->

<name>CD-SC-windgen-interpolate-endpoint</name>

<value>http://csip.engr.colostate.edu:8083/csip-climate/m/interpolate/1.0</value>

<access>write</access>

</parameter>

<parameter> <!-- generate iterpolated data - endpoint -->

<name>CD-SC-windgen-interpolate-genData-endpoint</name>

<value>http://csip.engr.colostate.edu:8083/csip-climate/m/interp_wdb/1.0</value>

<access>write</access>

</parameter>

<parameter> <!-- generate wind data - endpoint -->

<name>CD-SC-windgen-endpoint</name>

<value>http://csip.engr.colostate.edu:8083/csip-climate/m/windgen/1.0</value>

<access>write</access>

</parameter>

So, I am not sure exactly what is wrong here yet, but I suspect I am not currently using the windgen endpoints you are, so I would not experience your problems anyway.

Details
Comments & Attachments (1)
Associations
Children
SCM Commits
History (9)
Baselines
All (9)

Submitted Comment
JRCarlson
Feb 12 2019 22:07
wind_gen_his_upper_US_PR_NRCS.idx 66.9 KB
wind_gen_his_upper_US_PR.idx 91.5 KB
wind_gen_his_upper_US_PR.wdb 15.2 MB