Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

observation nudging with dropsonde data

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.


New member

I am trying to use the observation nudging scheme in WRF with some dropsonde observations we have over the Arctic. I tested with a single sounding in a single domain with WRF3.8.1. The sounding data was read in by WRF successfully (such as lat/lon, number of levels) but no nudging is done in the WRF run (by comparing runs with obs_nudge_opt=1 vs 0). I did some more modification to the subroutine errob in phys/module_fddaobs_rtffda.F and the nudging seems to work properly for my case (multiple sounding as well) but there are still issues on communication between processors that might cause troubles for other RTFDDA cases. I guess this is a bug report but I don't have a perfect solution yet. I'd appreciate any advice on how to fix this bug. Some more details from my tests are listed below.

I tested on the phys/module_fddaobs_rtffda.F and found out the issue might be related to the values of rko and errf(9,:). The variable rko is not calculated and set to zero together with errf(9,:) in the subroutine errob. On the processor that is handling the gridboxes including the location of the dropsonde, there are still several tiles (but I guess the CPUs on my cluster treats these tiles sequentially). In my case, the location of the dropsonde is not on the first tile, so MP_LOCAL_DUMMASK(N) is set to .False. in the first tile and rko is not computed. At the end of errob, rko is set to 0, the value of errf(9,:). When the second tile is computed, although MP_LOCAL_DUMMASK(N) is .True., but the check for abs(rko(n)+99).lt.1 failed, so rko is still not calculated. That's why rko and errf(9,:) are all zeros and no actual nudging is done in nudob.

I have to add the following changes to errob to have the nudging active:
(1) change the check for rko(n) from
if( abs(rko(n)+99).lt.1. .or. abs(rko(n)).lt.1. )
(2) Set MP_LOCAL_DUMMASK(N) to .True. instead of using TILE_MASK.
I know the second change is not right because the resulting rko are garbage (over 8e5) on tiles that do not include the location of the sounding ( when TILE_MASK(IOB, JOB, its, ite, jts, jte) returns .False. ). But the rko and errf(9,:) are still 0 if MP_LOCAL_DUMMASK is not set true. I guess there are still some value communication issue between processors and tile handling. But I am not sure how to do it properly.

This post has been moved to the "Special Running Options," as it is more relevant here. Someone will respond to your post soon.
Hi, Zheng,
My colleague forwarded your post to me. Honestly I don't know exactly what is wrong in your case, but I don't think there is a bug in the code.
If you run with jobs nudging, there are many output information in rsl files. These information may give you hints whether the soundings are read into the model, whether they are accepted or rejected.
One simply way to check is that, you can plot profiles of model output at your sounding locations, and compare with soundings themselves. If big differences exist, it is possible that the sounding information are rejected by the model, leading to same results with and without the nudging.
I attach a new version of obsgrid file just in case you want to try. The problem is in WRF itself, but possibly be traced back to OBSGRID.


  • obsgrid.tar
    2.4 MB · Views: 74
Thanks for the reply and the suggestions. Several things I should make clear about the issue:

(1) I used the perl script ( provided by NCAR to convert the sounding from little R to the format used by WRF. I didn't use obsgrid at all. But I don't think it is related to the input of the sounding to WRF. If I edit the code (phys/module_fddaobs_rtffda.F) following what I mentioned in the original post, I DID get the expected nudging effects: the WRF simulated soundings are indeed nudged toward observations within a given radius. But without these edits, no nudging. That is why I thought there is a bug here instead of issues with obsgrid, or sounding input, or the input sounding being too different from WRF soundings. My concern is that this bug may need more than my "fix" , which might not be suitable for other applications.
In addition, the rsl files are very informative and helped me a lot to figure out this temporary "fix". More details on how I tracked down this issue are given below.

(2) The output information in the rsl files show that the vertical indices of the sounding data to be 0 and that is what got me to check the phys/module_fddaobs_rtffda.F file. I added some calls to wrf_message to print out to rsl files and found that the flow of the code never went past the checks (IF ( MP_LOCAL_DUMMASK(N) ) THEN) to calculate the vertical indices and the default 0 values were kept in the "errob" subroutine. Also, I checked that the sounding data were read in correctly but not used by the "nudob" subroutine in rtfdda because of the 0 vertical indices.
My "fix" was to turn off these checks and force every tile to calculate the rko and errf(9,:). This does get the WRF to assimilate my sounding and produce expected results.

(3) My thoughts on why this happens. Please correct me if I am wrong here. The MP_LOCAL_DUMMASK check is related to tiles of the model domain assigned to the same CPU. OPENMP is supposed to process these tiles simultaneously and one of the threads is supposed to pass the MP_LOCAL_DUMMASK check and calculate the vertical indices for the sounding (the variable rko and errf(9,:)) and OPENMP is supposed to get the correct vertical indices from that tile. But when WRF is compiled without OPENMP, the different tiles are processed sequentially and messed up the values of rko and errf(9,:).

I understand that my questions here might be too specific about the details in this module. If it does not fit in the scope of this forum, could you please refer me to someone who is in charge of this module or the RTFDDA component in general?

Hi Zheng, did you find a solution to this? I have crashes with >1 MPI processes, but the run completes successfully with only one process.
This behaviour is only present with obs nudging a nest.
The temporary solution I listed above is the only way I can get around this issue and I compiled a special version of WRF with this "fix". I haven't got any update on this issue since my last post. Hopefully, more reports of this issue will bump it up the priority list.