Bottom layer specific humidty sent from the atmosphere model is less than zero

[imuzic]

Hi,

I would appreciate your input on the following error.

I submitted WRF-CTSM run starting from the 1st of October, 2017 and the interruption occurred 11 days later with the error arising from CTSM/lnd_import_export_utils.F90:
ERROR: Bottom layer specific humidty sent from the atmosphere model is less than zero.

I checked the 2m specific humidity (Q2M) variable output from all produced ctsm_lilac.clm*.nc files, however, none of the time steps exhibit values less than zero.
Could you please let me know what may be causing the run to stop?

Thank you,
Iris

 

[oleson]

The error means that the specific humidity being passed from the atmospheric model (WRF) to CLM is negative, which is physically unrealistic. The corresponding variable in CTSM is QBOT, not Q2M (Q2M is diagnostic). Looking at QBOT might be useful but the model is likely crashing before the variable is written to the history file.

 

[imuzic]

Thank you. I could try setting QBOT as the daily output variable in user_nl_ctsm and check its output after running WRF-CTSM again.

 

[imuzic]

I could not find any negative value in the daily QBOT output. Could you please let me know if there may be something else I could check as well?

 

[oleson]

As I mentioned, the negative value is probably crashing the model before it is written out to history. You could try to bypass the call to shr_sys_abort and let the model run past that error and then check the history files to see what gridcell(s) have negative QBOT.

 

[imuzic]

Thank you for your input. It seems that the variable QBOT in our WRF-CTSM run shows some negative values during winter in the area of the Black Sea. Some variables indicate that the Black Sea is considered a special category. That is visible in e.g., pftmask (-9999 for sea, 1 for land and 0 for the Black Sea), SNOW_DEPTH and SNO_ICE variables, please see attached. I would appreciate hearing your view on the error and what could be done to treat the Black Sea like other seas.

 

[imuzic]

After including some additional print statements, I see that the error message arises from WRF (variable Q2 is negative) over some high latitude mountainous areas (in both inner and outer domains of my two-domain setup) when running WRF-CTSM. However, no error appears when running WRF Noah and WRF Noah-MP with the same namelist.input settings. I tested using MYNN and YSU PBL schemes in WRF-CTSM but they both showed the error (module_sf_mynn.F, module_sf_sfclay.F). In both schemes, the code says: “Q2 will be overwritten for land points in surface”.

Could you please let me know if the reason for CTSM failing is that Q2 over land is used in Noah(MP) but not in CTSM or maybe that Noah(MP) accepts negative Q2 values while CTSM does not?
I also noticed that the number of the rsl. file giving the error in WRF and in CTSM is different (120 and 15, respectively). Does this mean that the tiling is different in CTSM than in WRF?

Based on the findings above, it seems that this error does not arise from the area of the Black Sea. I am thus not certain if the fact that the Black Sea pftmask in CTSM output is different from other lakes (-9999 for sea, 1 for land and 0 for the Black Sea) should be considered as an issue.

I would appreciate hearing your thoughts on how to proceed with running WRF-CTSM.

 

[negins]

Hello @imuzic,
First, negative Q2 values from WRF is quiet strange while using positive definite or monotonic advection schemes. For example, please see this post in WRF forum: negative Q2 value - WRF & MPAS-A Support Forum

1) Can you please print out Q2 values from a NOAH-MP or NOAH run? Do they accept negative values? If so, we need to add some Fortran code in CTSM to zero out Q2 values from WRF. In CTSM we specifically check for negative Q2 values coming from the atmosphere and that is why you are receiving this error.

2) Can you please let me know how big is the negative Q2 values? This post kind of mention that even positive definite advection scheme does not get rid of round-off negative values. This again points us in the direction of zeroing Q2 values coming from the atmosphere (i.e. WRF here).

3) Can you please run real.exe to create wrfinput_d01 for NOAH-MP simulation for this domain (you might already have it). Next, use this wrfinput_d01 (from NOAH-MP) for your WRF-CTSM simulation and see if you are receiving this error? I have noticed an error from WRF side while creating wrfinput_d01 and want to rule out this is not causing the issue.

4) Can you please share your setup? How long are your simulations? I have noticed you are running WRF for multiple months (is that correct?). Please keep in mind that for longer simulations with WRF you need to either reinitialize your simulations every few days or use spectral nudging.
Without WRF re-initialization or sp nudging , it will diverge too much from the upper-level global meteorological fields which provide boundary conditions... If you are using re-inilization, 24 hour spin up should be enough and you run a few days at a time (for example 3-5 days). With spectral nudging, you can run long runs (for example one year, etc).


Please let us know about these points.
Thanks!
Negin

 

[imuzic]

Hi @negins,

Thank you for your message. Please see my replies below:

1. I tested using WRF Noah-MP and could see that it accepts negative Q2 values. It may be that Noah(-MP) uses the specific humidity at the surface (QSFC) rather than Q2. QSFC values were positive throughout the run. I also tested running WRF-CTSM with additional lines in module_sf_mynn.F that set negative Q2 to zero. This way, the WRF-CTSM run has not been disrupted.
2. The negative Q2 values range between about -1.0E-04 and -7.2E-09 kg/kg. Based on this paper, the annual mean 2 m specific humidity over the Greenland area (average over the period 1958–2008) ranges between around 0.5E-03 and 3.0E-03 kg/kg.
3. I received the same error when I used wrfinput_d01 from Noah-MP real.exe run.
4. I use spectral nudging. Please see my namelist.wps and namelist.input files enclosed.

 

[imuzic]

It seems that Noah-MP does not use Q2 values since the surface layer scheme code in module_sf_mynn.F states that Q2 will be overwritten for land points in the LSM. The issue has thus been resolved by zeroing out negative Q2 values in module_sf_mynn.F:

IF (Q2(I) .LT. 0.0) THEN
     print*,"DEBUG: NEGATIVE Q2 VALUE IN MYNN SFCLAYER",&
     I,J, "Q2: ",Q2(I)
     print*,"WARNING: NEGATIVE Q2 SET TO ZERO"
     Q2(I)=0.0
ENDIF