Hi,
I am retrieving winds from KVNX and KICT using PyDDA. The magnitude of the vertical velocity maximizes right near the axis between the radars and decreases with distance in what seems to be an unphysical manner. Do you have any suggestions on what could be causing this or how to resolve it? I am using tensorflow and Co and Cm = 1; the resolution is 0.5 km vertically and horizontally. A plot of the vertical velocities at 4.5 km is shown below.
Thanks
Hannah
Are you using any background constraints? What constraints are you using?
I am using a sounding to initialize the domain. This is a case from 2011 so we donât have hrrr data. The case is in Oklahoma/Kansas.
Could you list all of your parameter values here? Including Cb?
Here is what I currently have. I have not included Cd.
grid, parameters = pydda.retrieval.get_dd_wind_field([VNXGrid, ICTGrid],
u_init, v_init, w_init,
u_back=u_back, v_back=v_back, z_back=z_back,
mask_outside_opt=True, mask_w_outside_opt=True, frz=4575,
filter_order=2, filter_window=3,
vel_name=âcorrected_velocityâ, refl_field=âDBZâ,
Co=1, Cm=1,
engine=âtensorflowâ)
By default, the background (Cb) will be set to 0. Can you add in a value for the Cb parameter (ex. Cb=1)
Sure.
The sounding I only has u and v winds. So the initialized winds are 0. When I include Cb=1, all the retrieved w = 0.
Would using the era-interim initialization or constraint option be better?
I would suggest trying the ERA-interim data
ECMWF has moved ERA-interim data behind a paywall. (Access ECMWF Public Datasets - ECMWF Web API - ECMWF Confluence Wiki)
Currently when I run pydda.constraints.make_constraint_from_era_interim I get an error that says âAPIException: 'ecmwf.API error 1: ERROR 170: This service has been phased out. For more information see Decommissioning of ECMWF Public Datasets Service - Data and Charts - ECMWF Confluence Wikiâ.
Will pydda.constraints.make_constraint_from_era_interim function if I download a complete ERA5 dataset and provide the file?
I think it could be done, but you have to make sure the variable names are the same as in the era_interim data
Iâve opened an issue in PyDDA for updating the ERA-Interim-related code to support ERA5 instead. Iâll likely have some time after AMS Radar to take a look at updating that portion of the code.
@rcjackson @mgrover1 There are some pre-operational HRRR runs for our case. The runs initialize hourly and run out 15 hrs. For retrieval purposes, I assume we would want HRRR runs that initialize closest to our time of interest. Is that correct?
Yes, I would use the runs that initialize closest to the time of interest. The HRRR assimilates NEXRAD observations into its initialization while the rest of the time periods would be prognosed from that initialization. Therefore, we would expect the initialization (0h) step to be most representative of the storm.
