<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Benjamin,<div class=""><br class=""></div><div class="">Thank you for reporting this.</div><div class=""><br class=""></div><div class="">I have confirmed the behavior you described below and have created a JIRA ticket for this issue ("NCL-2711" for future reference). Hopefully we can get a solution for this into NCL before 6.5.0 is released.</div><div class=""><br class=""></div><div class="">Thanks again!</div><div class="">Kevin</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 10, 2018, at 8:15 AM, Ben Green - NOAA Affiliate via ncl-talk <<a href="mailto:ncl-talk@ucar.edu" class="">ncl-talk@ucar.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello,<div class=""><br class=""></div><div class="">I believe that the NCL function wgt_volrmse has a bug -- namely, that the formula is wrong. I am using NCL V6.3.0, but downloaded the source code of V6.4.0 and confirmed that the relevant source code is unchanged. I also could not find any reports on a bug in wgt_volrmse on the NCL website.</div><div class=""><br class=""></div><div class="">I first became suspicious of a bug when my code using wgt_volrmse were an order of magnitude different than results that a colleague of mine obtained using raw Fortran code.</div><div class="">So I downloaded the source code for versions 6.3.0 and 6.4.0 to look at wgt_volrmse. The relevant fortran file is under ./ncl_ncarg-6.4.0/ni/src/lib/nfpfort/volRmse.f</div><div class=""><br class=""></div><div class="">I looked at this code and it appears that a square is being taken twice:</div><div class="">First, SUMTQ = (T - Q)**2</div><div class="">Then, VARTQ = (SUMTQ/SUMWZ)**2</div><div class="">A square root is taken at the end. So that "negates" only one of the **2 operations.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I then looked at the code for wgt_arearmse. In theory, these two functions should provide identical answers if the third-from-rightmost dimension is of size 1 and no weighting is applied to this dimension in wgt_volrmse.</div><div class="">The relevant source code for wgt_arearmse is under ./ncl_ncarg-6.4.0/ni/src/lib/nfpfort/areaRmse.f</div><div class=""><br class=""></div><div class="">This code takes a square once (SUMD) then takes a square root at the end. So I have no reason to believe that wgt_arearmse has a bug.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">As I said earlier, in theory wgt_volrmse and wgt_arearmse should provide identical answers if the third-from-rightmost dimension is of size 1 and no weighting is applied to this dimension in wgt_volrmse.</div><div class="">I tested this out with a script, and with data samples. I upload a .tar file (demo_RMSEbug.tar, <b class="">filesize 530K</b>) via ftp. The contents of this .tar file are:</div><div class=""><a href="http://fcst.nc/" class="">fcst.nc</a> (a file of size (1, 181 lat, 360 lon) of forecast 2-m temperatures): <b class="">filesize 260K</b></div><div class=""><a href="http://obs.nc/" class="">obs.nc</a> (a file of size (1, 181 lat, 360 lon) of observed 2-m temperatures): <b class="">filesize 261K</b></div><div class="">demo_bug.ncl (a small sample script): <b class="">filesize 1.5K</b></div><div class=""><br class=""></div><div class="">In my test script, I calculate RMSE using both wgt_arearmse and wgt_volrmse, and print the output. As might be expected with the extra **2 operation in wgt_volrmse, the RMSE I get with this function is much higher than the RMSE I get when using wgt_arearmse. Values from both are printed out within the code.</div><div class=""><br class=""></div><div class="">I believe that this conclusively demonstrates a bug in wgt_volrmse (or at least an inconsistency with wgt_arearmse). If not, I apologize.</div><div class=""><br class=""></div><div class="">Other relevant information:</div><div class="">ncl -V returns 6.3.0</div><div class="">uname -a returns <span style="font-variant-ligatures:no-common-ligatures;font-family:Menlo;font-size:11px" class="">Linux tfe10 3.10.0-693.11.1.el7.x86_64 #1 SMP Fri Oct 27 05:39:05 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux</span></div>
<div class=""><br class=""></div><div class=""><br class=""></div><div class="">Please let me know if you have any further questions.</div><div class=""><br class=""></div><div class="">Thank you very much for all of the work you do for NCL -- it is a great tool.</div><div class=""><br class=""></div><div class="">Sincerely,</div><div class=""><br class=""></div><div class="">Benjamin Green</div><div class=""><br class=""></div><div class="">-- <br class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class="">Benjamin Green<div class="">CIRES Research Associate at NOAA/ESRL/GSD</div><div class="">David Skaggs Research Center, Room 2B-501</div><div class="">Phone: 303-497-5132</div></div></div></div></div></div></div>
</div></div>
_______________________________________________<br class="">ncl-talk mailing list<br class=""><a href="mailto:ncl-talk@ucar.edu" class="">ncl-talk@ucar.edu</a><br class="">List instructions, subscriber options, unsubscribe:<br class="">http://mailman.ucar.edu/mailman/listinfo/ncl-talk<br class=""></div></blockquote></div><br class=""></div></body></html>