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

How to do TC bogussing in WRF for two domains?

beuraieon_a

Member
Hello. I am a beginner in WRF (I'm currently using v.4.5.2), and recently I tried modelling a small hurricane that had rapid intensification. The input were GFS forecast data. I included sea-surface temperature (SST) data, applied two-way nesting, set a (parent) grid resolution of 15 km and a 1:5 ratio for the child domain relative to the parent domain. But the output grossly underestimated the rapid intensification. I was expecting the pressure to drop from 980 hPa (at the start of the simulation period) down to around ~890-900 hPa (24-27 hours later), but the lowest the modeled hurricane got was ~960 hPa.

That's why I thought maybe I can try out the TC bogus scheme, which I haven't tried before. I intended to add a bogus TC that mimics the hurricane's actual intensity (based on data from the NHC), hoping it would significantly improve the simulation.

But, as how I understand it, the TC bogus scheme can process only 1 domain, takes in only 1 met_em* file as input, and runs serially only. I read posts on similar concerns in the Forum and read the Users Guide, but there are things that I still don't understand. Thus, I would like to ask these questions:

1. Assuming I still want to retain the original setting (with two-way nesting) and the met_em* files are ready, is there a way that TC bogussing can be applied to both the parent and the child domain? The users guide says that "users with multiple domains should horizontally-interpolate the generated meteorological fields to the fine-grid domains," but how exactly is this done? What are the steps? Also, I've read somewhere that an alternative would be using the ndown.exe, but I really don't understand how it can be applied in this scenario and I'm wondering what's the exact procedure for this.

2. The users guide stipulated that "alternatively, users may run the tc.exe program on separate metgrid output files for different domains, though this is not recommended." I was planning on doing that approach, like running tc.exe for all met_em* file for both d01 and d02, since I still don't understand how to use ndown.exe in this specific situation. Why is such strategy not recommended? Would real.exe and wrf.exe work differently?

3. I've read somewhere that since tc.exe takes in only 1 met_em* file, it is recommended that TC bogussing be applied only for the initial time (the first met_em* file). I was thinking that maybe the model will still underestimate the hurricane if the TC bogus was only applied at the start of the simulation period (esp. if the bogus TC was set to be mimicking the actual conditions of the hurricane at that given time and the start time was the time right before the rapid intensification phase commenced). This is also why, as aforementioned, I thought of running tc.exe for all met_em* files, i.e. for both d01 and d02, and inclusive of all time periods, with the TC bogus parameters based on center location, MSW and RMW data from the NHC. Is that approach acceptable or plausible? What could be its possible ramifications to running real.exe and wrf.exe?

4. Since tc.exe takes in only 1 met_em* file, do I need to edit the &time_control section of namelist.input such that the run hours, start date, end date and other variables have to be edited so that they correspond to a single date-time? Aside from the variables in the &tc section, are there other variables that need to be edited in order to properly apply the TC bogus scheme without errors?

5. If I were to apply the TC bogus scheme on this situation, do I need to run tc.exe and remove the existing tropical cyclone in the input met_em* file, and then rerun tc.exe to add the bogus TC (based on NHC data)? Or do I just insert the bogus TC immediately? If it is the latter, what does the tc.exe program do to the already present TC in the file? Does it "overwrite" the already present TC vortex or make adjustments to it?

And lastly,

6. I'm running WRF on my laptop and it's really not that high-spec. That's why the model run that I described earlier in the first paragraph actually took 22 hours to finish, even when I used 2 processors to run it. Since tc.exe can only be run serially, is it correct to assume that redoing the task serially will take a very, very long time to finish, significantly exceeding the previous 22-hour runtime?

Thank you very much in advance for your responses and recommendations.
 
To apply TC bogussing with two-way nesting in WRF, you'll need to run tc.exe on the parent domain and then use ndown.exe to pass the information to the child domain. Running tc.exe on both domains isn’t recommended because it can lead to inconsistencies. Usually, applying the bogus TC at the start of the simulation is enough for WRF to evolve the storm correctly. tc.exe will automatically overwrite the existing storm in the file, so you don't have to worry about removing it manually.
 
1. Assuming I still want to retain the original setting (with two-way nesting) and the met_em* files are ready, is there a way that TC bogussing can be applied to both the parent and the child domain? The users guide says that "users with multiple domains should horizontally-interpolate the generated meteorological fields to the fine-grid domains," but how exactly is this done? What are the steps? Also, I've read somewhere that an alternative would be using the ndown.exe, but I really don't understand how it can be applied in this scenario and I'm wondering what's the exact procedure for this.
You can run tc bogusing on only one domain, but then when you actually run real and wrf, you can run 2 domains. The values from the parent domain will automatically be horizontally interpolated to the child domain when you do this.

2. The users guide stipulated that "alternatively, users may run the tc.exe program on separate metgrid output files for different domains, though this is not recommended." I was planning on doing that approach, like running tc.exe for all met_em* file for both d01 and d02, since I still don't understand how to use ndown.exe in this specific situation. Why is such strategy not recommended? Would real.exe and wrf.exe work differently?
I'm actually not sure what would happen if you do this. I haven't had a lot of experience with TC Bogusing, but perhaps you won't need to do this if you use the method I mentioned for your question (1).

3. I've read somewhere that since tc.exe takes in only 1 met_em* file, it is recommended that TC bogussing be applied only for the initial time (the first met_em* file). I was thinking that maybe the model will still underestimate the hurricane if the TC bogus was only applied at the start of the simulation period (esp. if the bogus TC was set to be mimicking the actual conditions of the hurricane at that given time and the start time was the time right before the rapid intensification phase commenced). This is also why, as aforementioned, I thought of running tc.exe for all met_em* files, i.e. for both d01 and d02, and inclusive of all time periods, with the TC bogus parameters based on center location, MSW and RMW data from the NHC. Is that approach acceptable or plausible? What could be its possible ramifications to running real.exe and wrf.exe?
Again, I'm not sure of the ramifications, but you can always test this out and see what happens! You don't have the run the full simulation - just through the time that would give you an idea of what would happen.

4. Since tc.exe takes in only 1 met_em* file, do I need to edit the &time_control section of namelist.input such that the run hours, start date, end date and other variables have to be edited so that they correspond to a single date-time? Aside from the variables in the &tc section, are there other variables that need to be edited in order to properly apply the TC bogus scheme without errors?
When you run tc.exe, you only need to set max_dom=1. Setting that tells the executables to ignore everything in additional columns.

5. If I were to apply the TC bogus scheme on this situation, do I need to run tc.exe and remove the existing tropical cyclone in the input met_em* file, and then rerun tc.exe to add the bogus TC (based on NHC data)? Or do I just insert the bogus TC immediately? If it is the latter, what does the tc.exe program do to the already present TC in the file? Does it "overwrite" the already present TC vortex or make adjustments to it?
That's a good question. I'm not sure if anyone has ever tried to specifically do what you're doing - using TC Bogus to improve the conditions of an existing TC. I would think you may need to remove the existing storm first, but again, this is something you can play around with.

6. I'm running WRF on my laptop and it's really not that high-spec. That's why the model run that I described earlier in the first paragraph actually took 22 hours to finish, even when I used 2 processors to run it. Since tc.exe can only be run serially, is it correct to assume that redoing the task serially will take a very, very long time to finish, significantly exceeding the previous 22-hour runtime?
I don't believe you'll have to run the wrf model serially - only tc.exe, so hopefully that won't be an issue for you.


As an alternative to all of this, I would possibly suggest trying to use a different type of input data and/or modifying some of your namelist settings (e.g., physics options) to try to get the TC to behave as is expected. There is likely some literature out there (or maybe even other posts on this forum) that describes some of the better options for TC simulations.

If you do decide to use TC Bogus, there is a known bug with it. See TC Bogus Seg-fault for additional information.
 
Top