Please see the two attached figures; one showing 2m temperature summary plot for error statistics and the other is the timeseries at a specific station. Summary plot shows that there is a positive bias in early morning hours while timeseries plot show that the model underpredicts 2m temperature from evening to early morning hours. If I am not in mistaken, MET_summary.R calculates the bias using (mod-obs) difference. This calculation then makes a positive bias as overprediction while most of the timeseries that I analyzed shows that the model underpredicts 2m temperature. Therefore, I am confused why timeseries plot show underestimation of 2m nighttime temperature while diurnal variation of 2m temperature bias shows that it is overestimated. I understand that summary report is over the modeling domain in focus while timeseries is only at one station. However, I looked at many station timeseries and the model is underestimating the nighttime temperature.
Is my understanding for the calculation of bias correct such that positive bias means overprediction of 2m temperature through (mod-obs) calculation?
Why does the timeseries show an underestimation of 2m temperature while 2m temperature bias show overestimation over the same evening hours ?
I would appreciate if you could help me to understand the plots better by answering these two questions. Thank you Robert.
Not sure I agree Kemal. Screen capture of your timeseries below. Red and blue are two model runs. Black is the observed temperature. The model has a positive bias overall (model – obs). It is hard to tell at the peak daily temperature as much, but clear as temps cool overnight the positive bias grows, then declines closer to zero throughout the day. The diurnal summary plot has a near zero bias from about 20-02 UTC, then increases above 1 K until after 18 UTC when it quickly goes back to near zero. Don’t see any inconsistencies. Let me know if my coffee this early AM has not kicked in yet.
Thank you for the input Robert. Since many stations report underestimation and not a single station with overestimation of evening and early morning temperature, it is clear that bias should be negative at those hours. Yet, visual calculation is different than the machine calculation. So, I will have to take the results as it is and state that while domain average bias is positive, many station based bias is negative at evening and early morning hours. Thank you again for the input. With my best regards.
I’m still a bit confused and want to understand this in case there is an error in AMET.
The timeseries plot you provided is one site.
At this site the model has a positive temperature bias.
“Since many stations report underestimation and not a single station with overestimation of evening and early morning temperature”
Could you provide a timeseries of a site that has a negative bias of temperature?
Previous response was just comparing the plot above that show positive temp bias with the summary that also shows positive temp bias. Those two are consistent.
Alternatively you can do a spatial plot of temperature bias. It would be interesting to see that temp bias map. You can even use the input/spatial_surface.input file to do spatial plots for different parts of the day.
e.g., set lines like this. These will add conditions on what data is extracted for the spatial plots.
The truth and mistake should be told. I think I got myself confused. Although I had come up with the right conclusion earlier, then I got confused again later on when I was trying to understand those two figures and asked the question of underestimation and positive bias simultaneously. As your explanation helped me to understand the situation better, a positive bias (mod-obs) is also an underprediction (mod-obs) (by looking at minimum temperature figure although it confused me first) based on the comparison of those two figures. Conversely, when the model prediction comes short of reaching the maximum temperature, this time it the bias is negative (mod-obs) and yet the model still underpredicts the maximum temperature. Having said that, it would be worthwhile to look at spatial plots that you mentioned. That should give a clearer picture. Thank you for your explanation that helped me to correct myself. More minds and especially trained minds like yours are better than one like mine. I appreciate your help. With my best regards.
I now have a problem in extracting rawinsonde data with MPAS limited area model output while I extract rawinsonde data with MPAS global model output files. Here is the error (cut-and-paste):
---------------- begin ---------------------
324 Sites **** CYRB **** excluded because out of MPAS domain
325 Sites **** 20292 **** excluded because out of MPAS domain
326 Sites **** CWEU **** excluded because out of MPAS domain
327 Sites **** 20046 **** excluded because out of MPAS domain
328 Sites **** CYLT **** excluded because out of MPAS domain
*** DATABASE ACTION ***: Updating stations table in AMET database: ametdb
Total sites in current observation dataset: 662
Num sites excluded because outside of MPAS domain: 328
Finished: Mapping observation sites to MPAS grid. Number of sites mapped: 334
Site 1 of 334 unique sites - 89009 20130110 Model time: 00:00:00 Obs time: 00:00:00
Error in if (is.na(levels[l]) || is.na(profiles[l, 1]) || is.na(profiles[l, :
missing value where TRUE/FALSE needed
Calls: raob_query_native
Execution halted
--------------- end ---------------
While the “matching_raob.csh” script is the same as the one I used for global model output that works fine, I still attached it here.
Errors states that native query option is not set, but is it not the one set with “setenv NATIVE T”?
Where is this error coming from? Since the script works for global model output, but not with limited area output, does this have to do with the limited-area domain similar to previous problem that we had?
Thank you again buddy for identifying a problem. I thought I tested this with the limited area MPAS domain when the other issue was resolved, but may have not. Think both the raob and surface use the same site matching. At any rate, I should be able to look at this today. Just looked an I still have stuff set up from the last debugging.
Really sorry for the delay. Some time off and other stuff just got in the way. I finally looked at this issue this morning. Please try the attached update site mapping script. Just place in your AMET/R_db_code and rename with extension .R not .txt
Unfortunately the first bug update for limited area MPAS grids was not correct. It is used for the surface meteorology, so I would not use the results of that until you rerun the AMET matching.
Briefly, what I found was the accounting for sites in the domain is done by an index sitenum. If you look at your output sent in the email attached you will see 334 unique sites were found in the domain. This is just not accurate as there are only a handful of RAOB sites around California. Some 400+ around the world. When I added the check to see if a site was in the domain, I neglected to notice that prior this sitenum was advanced sitenum+1. This effectively adds the current unique site to the main domain obs site list before the check to see if it resides in the domain. All I know is when you ran the surface met matching, there is no way those sites were matched properly. Did not dig deep enough to understand why it still ran, but know it is incorrect.
So I moved all the sites-in-domain accounting after the check to see if in the domain. Now only 6 raob sites are found. I need you to help me as you find time. Rerun the surface met matching and compare statistics to see if you see improvements. Also, run the raob and do some of the analysis to verify there are not wild differences between the model and obs. I think all should be working. I need to check to make sure it does not break anything with regards to our global domains.
