SST values overwritten by real.exe despite sst_update=0 - preprocessing issue

[wagner]

I'm experiencing an issue where SST values injected into met_em files are being overwritten during the real.exe preprocessing step, making tropical precipitation simulations unreliable.

Problem Description:
• SST injection into met_em files (after metgrid.exe) fails - values are consistently overwritten by real.exe
• Original injected SST values: min=29°C, mean=30°C, max=30°C (302-303K)
• After real.exe processing: min=19°C, mean=27°C, max=29°C (up to 11°C reduction)
• The minimum values are reduced dramatically (~10°C), mean values by ~2°C, while maximum values remain unchanged
• Workaround: Direct injection into wrfinput_d0X files (after real.exe) successfully preserves intended SST values

This significant SST reduction severely impacts convective activity simulation over tropical waters.

Current namelist.input settings:
sst_update = 0,
sst_skin = 1,
surface_input_source = 1,

All attempts to modify other namelist parameters have been ineffective in preserving the injected SST values.

Technical Setup:
• WRF version: 4.6.1
• 3 nested domains covering tropical region including Andaman Sea
• SST source: OISST data properly interpolated to WRF grid
• SST injection method tested: Custom script with proper land masking using LANDMASK variable
• Injection timing: After metgrid.exe, before real.exe (unsuccessful)
• Current workaround: Direct injection into wrfinput_d0X after real.exe (successful)

Questions:
1. Why does real.exe overwrite explicitly provided SST values in met_em files when sst_update = 0?
2. Is direct injection into wrfinput files the recommended approach, or should SST injection in met_em files work as expected?
3. Should sst_update = 1 be used to preserve injected SST values, and what are the implications?
4. Are there other namelist parameters that could interfere with SST preservation during real.exe processing?
5. What is the standard workflow for incorporating external SST data in tropical simulations?

The current behavior makes it impossible to use custom SST data through the standard preprocessing chain, forcing the use of post-real.exe injection as a workaround.

Thank you for your assistance.
Staffan

 

[kwerner]

Hi Staffan,
First - many apologies for the long delay in response, and thank you for your patience.

3. Should sst_update = 1 be used to preserve injected SST values, and what are the implications?

Did you try testing this? If you are adding SST values to the files during WPS, then you will want to set sst_update=1. After you run real.exe, you should then have a wrflowinp* file, which should reflect the values of SST from the met_em* files. Try this out and see if the results are closer to what you expect.

When setting sst_update=1, make sure to set the following in the &time_control namelist record:

auxinput4_inname
auxinput4_interval
io_form_auxinput4