Using SST update with moving inner domain

Hello,

I am trying to run a WRF simulation with a moving inner nest and with time-varying SST. Because the inner nest moves, I have input_from_file (namelist.input, &time_control) set to FALSE for it, so that the moving nest will update itself based on the parent grid. In this case, real.exe does not create a wrflowinp_d02 file for the inner moving nest. Because sst_update looks at wrflowinp_d02 for new SST values to update the inner nest, I get a 'file not found'-type error when running. Furthermore, it seems like it is not possible in principle to provide SST update fields for the inner nest because we do not know where it will be beforehand.

Is it possible to run sst_update with a moving inner nest? If so, what may I be overlooking?

Thanks very much,

Ben

Hi Ben,
Can you attach the namelist.input file you're using, along with the log file showing the error message? Can you also let me know which version of WRF you are using? Thanks!

Hi,

I'm very sorry for the late reply. Somehow I forgot to enable notifications for replies to the thread.

My namelist.input file is attached. I'm running a tropical cyclone simulation with two inner, vortex-following domains. Running real.exe creates wrfbdy_d01, wrffdda_d01, wrfinput_d01, and wrflowinp_d01 files, but nothing is created for d02 or d03.

The error that causes WRF to crash while running is here:


4 input_wrf: wrf_get_next_time current_date: 2018-10-08_06:00:00 Status = -10
d02 2018-10-08_06:00:00 ---- ERROR: Could not find matching time in input file
NOTE: 1 namelist vs input data inconsistencies found.
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 1159
NOTE: Please check and reset these options
-------------------------------------------


Based on this error, I think it's looking for wrflowinp_d02, but it can't find it. I'm running v3.9.

Thanks very much for your help, and sorry again for the late reply.

Ben

Ben,
I ran a test similar to yours (vortex-following, using sst_update, fdda, input_from_hires, and with V3.9), and I am not able to get it to fail. I also have input_from_file = .true., .false., and all other settings I think could potentially be related.

1) Can you attach the following files so that I can try with your exact case:
wrfbdy_d01
wrfinput_d01
wrffdda_d01
wrflowinp_d01
if the files are too large to attach, take a look at the home page of this forum for instructions to upload large files.

2) Will you please attach your full log file (e.g., rsl.error.0000 and rsl.out.0000 if running in dmpar mode)?

3) Have you made any modifications to your WRF code, or is it the pristine "out of the box" code?

Thanks!

Hi,

I've uploaded the requested wrf*d01 files and the rsl* log files into a single .tar file called bwbarr_sstupdate.tar. It should be in your Nextcloud now.

My WRF model is not "out of the box." It is the atmospheric component of a coupled atmosphere-wave-ocean model. Now that you mention it, it's possible that we didn't accommodate sst_update in the coupler. If you are able to run the model using my uploaded files, then chances are probably good that it's a problem with our coupler code, and I'll need to do a deep dive to debug.

Thanks very much,

Ben

Hi,
Thank you for sending that. Okay, I was actually able to find a way to repeat your case. I finally tracked the problem down to this line in your namelist.input file:

The problem is that you are setting an interval for d02, when you don't have a wrflowinp_d02 file. If you simply remove domains 2 and 3 from that variable:
then it runs okay, as the default value is just 0. Give that a try and let me know if that helps.

Hi,

I made the modification you suggested and the model was able to run. Thank you for digging into it and providing the suggestion. However, there appears to still be a problem with sst_update communication to the nests. For instance, see attached file "bwbarr_sstupdate_before.png", in which I compare sea surface temperature between a wrfout_d01 file (left) and wrflowinp_d01 (right) at a time just before SST is updated in wrflowinp_d01. You can see that the fields are identical, and everything is fine. The other attached file, "bwbarr_sstupdate_after.png", shows the same fields just after SST is updated in wrflowinp_d01. On the right (wrflowinp_d01), the SST field has been updated (see for example the stronger cold spot west of Florida). On the left, wrfout_d01 has updated correctly everywhere except in a rectangular region in the southeast Gulf of Mexico and northwest Caribbean Sea, which has retained the old values of SST. This is the region covered by the d02 nest.

So, it seems that sst_update is working, but that it is not being forced to the nests. I guess the new question is - have you seen this before in a WRF "out-of-the-box" simulation? As we discussed before, I'm using WRF as a component in a coupled model, and it is possible that WRF nest forcing/feedback with our coupler has not been set up to accommodate sst_update. If this behavior is a surprise to you, then all signs point to a problem with our coupler.

Thanks very much for your continued support!

Ben

Hi Ben,
I apologize for the delay. I was able to talk to a colleague who knows a bit more about the vortex-following case, and they confirmed that although the case will likely run without errors, unfortunately the sst_update option does not properly work with vortex-following. The reason is that the update is only modified by the wrflowinp file, and since you are unable to create that file for a vortex-following case, then there is no method to do this for the nest. There may be others out there who have been able to make code modifications to get this to work, but at this time, we do not have any code that can do this.

Hi,

Thank you very much for getting to the bottom of this. Your answer makes sense - since the nests are moving, there is no way to know their future position ahead of time, hence no wrflowinp files for nests, hence no SST update for nests. In the meantime, we have employed a painful workaround by writing 3-hourly restart files, manually replacing SST in these files with updated SST fields, and then restarting the model from the modified restart files (repeating the process every three hours). This should get us where we need to go.

Thanks again for all your work on this issue over the past month. I appreciate your support very much.

Ben

Ben,
You're very welcome. I'm sorry we didn't have a better solution, but I am glad to hear that you've been able to find a work-around, even if it's not ideal. Thank you for your patience!