Automatically-moving nested domain appearing "stuck" at initial position (WRF vortex-following)

[beuraieon_a]

Hello everyone. I'm still a beginner in the WRF model, and I need your insights on how WRF's vortex-following mode actually works.

I recently tried running WRF with vortex-following for an intense Western North Pacific tropical cyclone. And I observed that while the automatically-moving nested domain did "automatically move" along with the cyclonic vortex, the nested domain remained stuck at its initial position when I visualized the WRF output using post-processing tools. I was expecting that the nested domain will "move across the map" along with the movement of the cyclonic vortex being tracked.

This is shown in the attached GIF animation of the WRF output for 10-meter wind speed and direction. I also attached my namelist files for your perusal. I opted to apply the default vortex-following settings, that's why their relevant variables (vortex_interval, max_vortex_speed, track_level etc.) are not present in the &domains section of my "namelist.input" file.

I tried simulating Typhoon Surigae (2021) around the time when it was at its peak intensity (simulation period: 12:00:00 UTC 2021 April 17 to 12:00:00 UTC 2021 April 18), using GFS analysis as input data. As you can see in the animation, the nested domain automatically moved along with Surigae's vortex, but it appears to be stuck at its initial position off the eastern coast of central Philippines. I thought that the nested domain will also appear to translate across the map or across its parent domain, in unison with Surigae's movement. Since Surigae was moving northwestward during the simulation period, the rough "outlines" of Eastern Visayas and Bicol Region can be observed near the end of the animation (in the southwest corner of the nested domain) when Surigae was at its closest approach towards the Philippines.

I used Panoply for the visualization in the attached GIF animation. I also tried visualizing the WRF output using GrADS, but I still observed the same behavior of the nested domain appearing stuck at initial position.

So I'm wondering: is this how WRF vortex-following really works? Or is there a tool, technique or strategy that can be applied so that the automatically-moving nested domain will also appear to automatically move or track across the map along with the vortex's movement?

Thank you very much in advance for your responses and recommendations.

 

[Ming Chen]

This is because the vortex center is not close enough to the boundary of the child domain. Once it is close enough to the boundary, the child domain will 'automatically' move so that the vortex center will be located to its center again.

There is nothing wrong with the moving nest option. If you run the case long enough, probably you can see how the child domain moves.

By the way, did you look at the simulated typhoon track? How did it look like?

 

[beuraieon_a]

Hello @Ming Chen, and thank you very much for the response.

This is because the vortex center is not close enough to the boundary of the child domain.

Does this mean that I have to make the child domain smaller? Preferably, how close to the vortex center should the child domain's boundary be so that it can actually move automatically across the map/across the parent domain along with the vortex?

By the way, did you look at the simulated typhoon track? How did it look like?

I have not inspected in full detail the vortex center position output indicated in the rsl.out file, but I suspect they indicate generally northwestward motion for the simulated typhoon during the simulation period. I'll look at them later when I get back home, and I'll inform you of my findings as soon as possible.

I also made the same simulation for Typhoon Surigae but with basic nesting only. In that simulation, the simulated typhoon track indicates that the vortex moved generally northwestward during the simulation period (almost similar to available best track data for Surigae coinciding with the simulation period).

 

[beuraieon_a]

By the way, did you look at the simulated typhoon track? How did it look like?

Hello @Ming Chen. I plotted the vortex center position output indicated in the rsl.out file, and indeed it showed that the simulated typhoon track had a generally northwestward path during the simulation period as shown in the screenshot below.

The output of "grep ATCF rsl.out.0000" command can be seen in the attached text file.

 

[Ming Chen]

Please see the attached plot that shows your model domains. This plot is based on options of your namelist.wps and namelist.input .

Please compare the plots and make sure whether the track shown in your figure is within the D02.

 

[beuraieon_a]

@Ming Chen, I cannot see the attachment.

 

[beuraieon_a]

By the way, I forgot to attach the "rsl.out.0000" file in this thread, and here it is. I hope this can help in figuring out the source of the problem.

Checking its contents, I noticed that the grid center of the child domain was unaltered throughout the model run.

grid center (in nest x and y): 33.5000000 33.5000000

 

[beuraieon_a]

Hello @Ming Chen. I tried doing another simulation of the same typhoon using the same input data source and still applying TC vortex-following. But this time, I changed the simulation period such that it is now extended to 48 hours (from 00:00 UTC April 16, 2021 to 00:00 UTC April 18, 2021), and the values of e_we and e_sn have been reduced from 67 to 40, thus making the child domain smaller. The "namelist.wps", "namelist.input" and "rsl.out.0000" file for this attempt are attached for your perusal.

Nevertheless, the child domain still exhibited the same behavior of following the TC vortex but remaining stuck in initial position (as shown in the attached GIF animations) despite the longer simulation period, longer distance traveled by the simulated typhoon (see attached screenshot and text file containing simulated TC track data) and the smaller size of the child domain. In the "rsl.out.0000" file, the grid center was also unchanged from the model run's start to finish.

grid center (in nest x and y): 20.0000000 20.0000000

In addition, I also observed that the "rsl.out.0000" file now contains a line that I have not seen before in the previous vortex-following run:

MOAD can not move. Cancelling nest move in X

This line appeared only 5 times within the "rsl.out.0000" file near the start of the model run.

Thank you very much in advance for your responses and recommendations.

 

[junius.Wang]

Hi，Dear Beuraieon​

I wonder if your problem is solved?Hope you have done your wish.

I am also a beginner. I want to use typhoons to do similar studies. I want to know if this case only needs to use the meteorological data and use the namelist you mentioned above to imitate the typhoon?

Looking forward to your reply.

Junius

 

[beuraieon_a]

Unfortunately, I received no response on the matter for almost 3 months. The same problem still persist until now. I'm still anticipating for your response on this matter, @Ming Chen @kwerner and others. Thank you very much in advance.

@junius.Wang Regarding your question about this case, I think other types of meteorological data may also be used (e.g. ERA5 reanalysis). And based on my understanding of the user manual, the namelist for vortex-following cases are similar with what is applied in the usual case, except for the specific variables to be added in the &domains section (e.g. vortex_interval, max_vortex_speed). Also, WRF must also be configured for vortex-following during the installation in order to be able to apply such case.

 

[junius.Wang]

Thank you so much~

 

[aurorrmok]

post-processing tool

May I ask what kind of tool you are using to create the GIF animation ? Thx

 

[beuraieon_a]

@aurorrmok Actually, I only used Panoply and GrADS to visualize the WRF output and render the slides, and I animated them using a video maker. Back then, I did not know yet how to write scripts for the usual programming languages like Python.