“run_spatial_surface.csh” of AMET script plots world/state boundaries on the map with the desired model performance values. When I zoom into the map, I see that country boundaries are drawn twice and they don’t overlap (see attached image). I think the “world” map plotting routine uses a different spatial resolution than the “state” map plotting script that these two boundaries don’t overlap. I think I pinpointed this problem to “MET_amet.plot-lib.R” script, line 898. We have to have state boundaries plotted for regional plots and commenting out the world boundaries causes empty maps. How can I eliminate the double lines that are seen in plots?
Update: I eliminated the drawing of double map boundaries by setting the line thickness in the world map to zero. Since I am zooming in, the state boundaries provide the map boundaries that I need.
1 Like
Another update: When I eliminated drawing the world boundaries by setting the line thickness to zero, it inadvertently eliminated the islands off the coast of Southern California. So, it seems that I have to have world boundaries plotted. Then the question still stays: How can I eliminate the double map outlines that are coming from world and state boundaries? Thank you for your help.
I’m glad you found a solution. For others out there, these scripts were originally designed to work for the US only since the MADIS obs data was US-centric. Since we expanded to using models like the global MPAS, we’ve tried to accommodate global plotting. Perhaps in upcoming versions we’ll make the map background/political boundaries more dynamic to account for different domains, but right now it is not.
This is the spatial surface map writing script bit. Users can do a little background exploration on the R packages “maps” and “mapdata” to understand that various options. And then test changes to $AMETBASE/R_analysis_code/MET_amet.plot-lib.R (see plotSpatial function) to customize the map background for their area of the world. You can see below the customization for the USA. The world country boundaries (world) are drawn first and then if the domain covers the CONUS according to the lat-lon bounds, US State boundaries are draw.
Kgurer’s solution obviously worked and may be the best, but they could have changed “world” to “state”, especially if most of there modeling is CONUS. I think the reason just commenting out the “world” line below did not draw anything is the “world” call is the first map draws. If you look at the “state” call afterward, it has add=T, which means it’s adding to an existing map. Probably does not work if the world map was not drawn first.
m<-map(‘usa’,plot=FALSE)
map(“world”, xlim=c(lonw,lone),ylim=c(lats,latn),resolution=0, boundary = TRUE, lty = 1)
if(lonw > -150 & lone < 0 & lats > 0 & latn > 25) {
map(“state”, xlim=c(lonw,lone),ylim=c(lats,latn),resolution=0, boundary = TRUE, lty = 1, add=T)
}
points(sinfo$lon,sinfo$lat,pch=spch, cex=scex, col=pcols)
box()
May I know which version of AMET you are using? I’m trying the 1.4b version and having some trouble with both AQ and MET examples.
Thanks!
Hi Thuy,
Hmm. I am surprised to see that you are sending your email “directly” to me. I am just another user of AMET. Did you mean to send your email to me directly, or
to CMAS group? Maybe I don’t understand how this forum works.
Regardless, I am using version 1.3 and not having any problems in reading files and generating any images. What specific problem are you experiencing? Maybe I
can help.
Kemal.
I’m not sure if the email went “directly” to you as I just simply hit “Reply” to the thread.
Anyway, it’s good to know you don’t have problems with version 1.3, so I can compare the R source codes between 1.3 and 1.4b to see the differences. I’m working on the matching surface right now; it complains the model data wrfout_subset/20160701_0000 is not “standard WRF or MPAS output”, and thus terminated the matching. The model_data set shouldn’t be a problem since it was from AMET. So I’m not sure what the issue is.
Thanks,
Thuy
Hi Thuy,
Based on the error message that you get, it seems like this WRF output’s structure is different than what AMET expects. I would recommend that you try to read
your WRF output “wrfout_subset/20160701_0000” via ncdump and compare it with an older WRF output that you have. This might give you clues as to why AMET is complaining about your WRF output. If you have written or converted classical WRF output into another
form of netcdf that AMET doesn’t understand, that might send the error message of “not standard WRF”. I would recommend you use nccopy (https://www.unidata.ucar.edu/software/netcdf/workshops/2011/utilities/Nccopy.html)to convert the existing WRF output into another netcdf format and try to read via AMET.
Kemal.
Thanks! I will try. However, this output is from AMET, not my own. I’m trying to run the MET example that AMET provides; so nothing is from mine.
Thuy
Hi Thuy,
If you are trying to get AMET working first with the WRF data that it comes with, then I don’t know what to think. Only possibility that comes to my mind at the
moment is that there may be some AMET installation issues. But, regardless, you should still try to read your own WRF data to see if AMET reads WRF output.
Kemal.