[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[IDV #YZO-547503]: data ingestion into IDV, plotting vectors, display problems

Greetings Kemal!

> Hello,
> I am contacting you to report several issues of IDV that I am experiencing, 
> so I can get some help. I created a tar file that includes all the figures 
> and input data with one time step only to help you to 
> regenerate the issues I am mentioning below and placed it onto:
> ftp://eos.arb.ca.gov/pub/outgoing/kgurer/idv_help.tar.gz
> I am trying to plot wind vectors near the surface from MCIP output of WRF 
> model result and WRF output into IDV3.0u2 on a 64-bit Windows platform having 
> 4 Gb of RAM (HP E8400, 3 GHz, Core2 duo). I 
> can ingest WRF output into IDV using any one of three file type options 
> available in IDV: 1) "aggregate WRF netcdf grids by Time", 2) "Grid files 
> (netcdf/GRIB/OpeNDAP/GEMPAK), and 3) aggregate grids by 
> time, and the wind vector fields look very similar (see figure 
> "feb_2_12Z_from_wrfout_u_v.jpg).
> Because of the use of different grid systems/projections in WRF and MCIP, the 
> least complicated way to compare both outputs is to plot wind vectors using u 
> and v components at 10 m height. These 
> variables are U10 and V10 in WRF, and UWIND10 and VWIND10 in MCIP's output 
> called METDOT3D.
> 1)      When I compare the two plots (WRF and MCIP input) using IDV, I don't 
> see any resemblance of the two fields to each other at all (see figures 
> "feb_2_12Z_from_wrfout_u10_v10.jpg" and 
> "feb_2_12Z_from_metdot3d_uwind_vwind.jpg).

I was able to load in the metdot3d data and get a vector field very similar to 
the WRF field. However, if I flipped the u and v inputs into the flow field 
formula, I was able to generate a plot like 
"feb_2_12Z_from_metdot3d_uwind_vwind.jpg" - double check to make sure you are 
entering the wind components correctly.

> When I independently plot wind vectors using NCL on my Linux box from WRF and 
> MCIP, I see that both plots are identical. Then, this raises the possibility 
> that I am not reading MCIP output (METDOT3D) 
> into IDV correctly since vector plot of WRF output on windows is the same as 
> the one generated on Linux box (The Linux cluster doesn't have a good 
> graphics card, and as a result displaying vectors takes 
> very long time).  What type of input data format I should choose from the 
> IDV's list to ingest I/O API MCIP output properly? 

I used the file type ""Grid files (netcdf/GRIB/OpeNDAP/GEMPAK)". However, there 
is one problem with the data file - the vertical coordinate "Lay" isn't 
properly formatted, so the 15 layers are assumed to be in order and are given 
evenly spaced coordinates between 0 and 1 with no unit. This can be fixed using 
NCML, but I'd need some more info about the structure of the vertical grid.

> I came across with the following reference to ingest I/O API netcdf formatted 
> files:
> http://www.cmaq-model.org/cmaqwiki/index.php?title=CMAQ_version_5.0_%28February_2010_release%29_OGD&CFID=3863765&CFTOKEN=92137774#Integrated_Data_Viewer_.28IDV.29
> (see section 12.8)
> However, this information doesn't help me in choosing the right format in IDV 
> to use MCIP output. Is it not available in IDV yet? If the proper format 
> available in IDV, what is the name?
> 2)      When I plot wind vectors near the surface using 3D variables u and v 
> from wrfout, the vectors over land is almost completely empty while they 
> exist off the coast. (See figure 
> feb_2_12Z_from_wrfout_u_v.jpg). This first suggest that terrain height might 
> be obscuring the wind vector over the land but sporadic appearance of wind 
> vectors over land suggests that something else is 
> going on. I look at the command window where IDV is launched to see if there 
> are any error messages, but I don't see any. IDV uses 1.2Gb of available 1.6 
> Gb of memory, so it should be enough; do you 
> agree? What  do you think is happening?

I see the same thing. I think this is an issue with terrain, because as you go 
to higher levels the 'gaps' begin to fill. However, I do have one question - 
did you destagger your wrf output before loading it into the IDV? It does not 
look like it, but I just wanted to be sure. If not, I would recommend that you 
do so - the performance of the IDV will definitely improve :-)

> 3)      When I plot the wind vector field from one data file and then plot 
> the another vector field from the other data file, the vector size in the 
> second one is plotted short, so the vectors are not visible. When 
> I increase the size of vectors from 4 to say 30 to see it better, the vector 
> size gets smaller in the first plot. When I go back to the first plot, this 
> time same situation happens in the second one. This goes 
> back and forth. I cannot keep the both fields' vector sizes at visible 
> ranges. How do I eliminate this?

This sounds like a potential bug - I'll have to dig into this more.

> 4)      I tried to find the graphics card information to help you to locate 
> the display problem, but I couldn't. Only information I have on my 
> workstation is it is an HP dual core with two 3 GHz processors (total 
> or 4 cpus) with 4 Gb of RAM. I didn't see an option to change the display 
> capability to OpenGL as the research to improve the results suggested. Also, 
> changing the display capability from 32bit to 16 bit 
> didn't help.

In order to change the java3d backend to openGL, you need to edit the 
runIDV.bat file in the IDV program folder. However, I think openGL is used by 
default (check the comments in the runIDV.bat file confirm this...I don't use 
Windows often, so I can't offer much help there - but I do know the information 
regarding openGL / Direct3D is in runIDV.bat.).



> I appreciate any help that you may give. Thank you very much in advance. With 
> regards,
> Kemal.

Ticket Details
Ticket ID: YZO-547503
Department: Support IDV
Priority: Normal
Status: Open

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.