Overwriting jh_coeff column in nmonths table

[lbross]

Will be same value for all rows (months). Geoffrey to provide calculation so this can be calculated in VB.

Median elevation of AOI. Use raster statistics? Make sure aoi boundary is set as mask. No buffer.

[lbross]

Locate jul min/max and aug min/max data layers in the aoi data bin. Names for jh_coeff layer are fixed. If they are missing, populated jh_coeff with noData value from Profile Builder. Throw warning message stating that data is missing and parameter needs to be edited manually.

[jdduh]

Mean Jenson-Haise PET coefficient for the AOI is based on PRISM temp grid for July and August months.

For the AOI, e1 = 6.1078 * EXP[(17.269_t1)/(t1+237.30)] e2 = 6.1078 * EXP[(17.269_t2)/(t2+237.30)] jh_coef = 27.5 - 0.25(e2-e1)-(AOI_median_elev_ft/1000)

Where e1 and e2 are the minimum and maximum saturation vapor pressures. t1 is the mean minimum temperature (degrees Celsius) for the warmest month of the year. t2 is the mean maximum temperature (degrees Celsius) for the warmest month of the year. The warmest month is defined as: the July or August whichever has the higher of the average of tmin and tmax (i.e., (tmin+tmax)/2). The unit of elevation value must be in feet.

[lbross]

Will need to extract t1 and AOI_median_elev_ft from AOI databin

[lbross]

Upon further reflection, I'd like to try to do this calculation in a model. If it ever changes, the calculation won't be hard-coded into the app. Will put it in the same toolbox as the HRU JH_Coeff unless there is an objection.

[jdduh]

Sounds good. Please name it distinctively so that users won't try to define it as regular method. How about creating a new toolbox (bagis_p_system_methods.tbx) or put the model in the building blocks toolbox? Does adding a new toolbox affect how BAGIS-P handles the toolboxes?

[lbross]

Agreed to put it into the building blocks toolbox. Adding a new toolbox doesn't affect how BAGIS-P handles the toolboxes but it's one more thing to keep track of and I don't expect we'll have many other system models. Right now I am calling it JH_Coef_AOI but it's easy to rename.

[lbross]

Copied new version of bagis_method_building_blocks.tbx to basins to backup my work. There is a new method in the toolbox called JH_Coef_AOI that calculates JH_Coeff at the AOI level.

[lbross]

Posted a new version of bagis_method_building_blocks.tbx to basins. I am now passing in the output table name as a parameter so it can be managed by BAGIS-P. The JH_Coef_AOI does not have an accompanying .xml file. The parameters are set by BAGIS-P code. Note that this model was created using ArcMap 10.2.2 so it is not visible from ArcMap 10.0 similar to the other recently edited models.

[lbross]

Potential fix committed to issue_8 branch. Posted copy of add-in to version 1.8.0 release page. This issue required significant changes to BAGIS-P code. Will merge issue_8 into master when functionality is verified.

[jdduh]

For debugging purpose on ArcGIS 10.0, you can right-click on the 10.2 toolbox and save it as an ArcGIS 10.0 Toolbox.

[lbross]

Just tried exporting to 10.0 and executing on Masoud's computer. The tool shows up but has a red 'x' and says it cannot execute. However, when I edit the data sources and run it from ModelBuilder, it runs successfully.

[jdduh]

When you see the red x, just open the model in edit mode and save (and close) the model to fix the error.

[lbross]

I tried that initially and it does not work in this case.

[jdduh]

The script "Is August Warmer" is not packaged with the toolbox. I have fixed the problem by copying the script to the building_blocks toolbox and "linking" it to the model. Please verify the model calculation when you get a chance to run it. You can get the updated model at:

https://github.com/PSU-CSAR/bagis-p-settings/tree/master/methods

[lbross]

Thanks for finding this error. I had to export the model from GitHub to 10.0. Then I had to "link" "Is August Warmer" to the exported model. I clicked on the script embedded in the model and browsed to my local copy of the Python script. There was also a step to convert the units that needed to be "linked" to the local copy. Not sure how this would copy to another computer running 10.0 but it is working for me.

I'm not 100% sure what the results of the calculation should be but it is in the ballpark with results for the hru's.

[lbross]

Should we consider caching the results of the jh_coeff at the aoi level? We could write it to the settings.xml for the aoi along with the date it was created. The calculation takes a long time and seems to make the export take a long time.

There are a couple of ways we could let the user choose to recalculate if desired but the underlying data doesn't change much. We could pop a messageBox when the parameters are exported indicating the date the coeff was last calculated and asking if we should recalculate. We could also add some fields to the export form with a checkbox so the user could choose to recalculate.

[jdduh]

Good idea. I prefer to not add additional information to the settings.xml. Can you save the value in a separate ASCII file and put it in the AOI folder (in, say, param folder)?

[lbross]

Using a separate ASCII file would take 3x as long to program. If we re-use the Settings object all we need to do is add a couple of fields to implement CRUD operations. This data is stored at the AOI level just like the data sources so it is a logical place. It will be at the same level as and could appear either before or after all the data sources. Your choice. But if you feel strongly about a separate file, I can do that.

Also, please let me know your preference for letting the user know that jh_coeff has been pre-calculated, and giving them the option to re-calculate.

[jdduh]

If that's the case, then put the calculated JH_Coef in the AOI's settings.xml. Right after the user clicks on the Export button, "pop a messageBox when the parameters are exported indicating the date the coeff was last calculated and asking if we should recalculate" I think this approach is easier than using a checkbox, which you need to determine its behavior based on if the JH_Coef value exists in the settings.xml file.

[jdduh]

Please hold the implementation on this function. George indicates that the nmonth JH_Coef shouldn't be calculated, but instead, predetermined. He though asks two additional nmonth parameters (evaportranspiration and solar radiation) to be calculated in BAGIS-P. He will provide the data and algorithms for the estimation.

[lbross]

Thanks for letting me know. We may be able to follow the same model with these new nmonth parameters where we store them in settings.xml rather than re-calculating them every time. It also makes sense to put the algorithm in a model so that it can be updated.

Let me know if I should comment out the calculation of JH_Coef in BAGIS-P on the parameter export screen to improve performance. Also if we need to undo any of the work in the data source editor that relates to JH_Coef.

[jdduh]

Please implement the jh_coef caching feature in BAGIS-P. The updated ModelBuilder model has a new set of "correct" equations to calculate the value for the nmonth table.

[lbross]

Caching the jh_coef value at the AOI level has been implemented in BAGIS-P v1.9.2. A new version of the add-in has been posted to the releases page.