units of specific humidity

[turuncu]

Hi,

I prepare the forcing file using NCPE/NCAR data and the specific humidity unit is kg/kg in it. So, based on the bulk_flux.F file i think that i have to modify the varinfo.dat file as,

Code: Select all

'Qair'                                             ! Input
  'surface air specific humidity'                  !  relative    or  specific
  'g/kg'                                           ! [percentage  or  g/kg    ]
  'Qair, scalar, series'
  'qair_time'
  'idQair'
  'r2dvar'                                         ! relative        specific
  1.0d3

In this case specific humidity must be multiplied by 1000 to convert g/kg. Is this correct? I just want to be sure about that.

Regards,

--ufuk

[kate]

If you look in bulk_flux.F, you will find this unsavory code:

Code: Select all

!  Compute specific humidity, Q (kg/kg).
!
          IF (RH.lt.2.0_r8) THEN                       !RH fraction
            cff=cff*RH                                 !Vapor pres (mb)
            Q(i)=0.62197_r8*(cff/(PairM-0.378_r8*cff)) !Spec hum (kg/kg)
          ELSE          !RH input was actually specific humidity in g/kg
            Q(i)=RH/1000.0_r8                          !Spec Hum (kg/kg)
          END IF

Some of us believe that ROMS should be looking for humidity in kg/kg, being the MKS units for it.

[tony1230]

Okay, on this topic, Kate have mentioned in a earlier thread in 2008 viewtopic.php?f=4&t=1032&hilit=RH, but it's remain unresolved.

I have been looking into this (bluk_flux.F) the couple days and still confused with the terms, say RH,Qair,Hair,Q and their units.

Specificly, i wanna know, what kind of humidity dose the roms want? Relative(RH) or specific(SH)? If SH, there is no need to transform from RH since they were there in the file download from NECP/NCAR, otherwise we just to transform to RH by a matlab scrip. I dont know why so unsavory code as Kate mentioned remained in roms?

As for

Code: Select all

IF (RH.lt.2.0_r8) THEN
... 
ELSE  ! RH input was actually specific humidity in g/kg
Q(i) = RH/1000.0_r8

I dont understand why take 2.0 as the boundary? I have simply got the SH from NECP file in unit kg/kg and have seen values both LT and GT 2.0(g/kg). Is is possible that roms compute a term using two formulars under different conditions?

Thanks

- Shou

[Pysh]

As I understand it is correct to take humidity SH but as a percentage, i.e., multiply the NECP/NCAR specific humidity by 100. In my experiments I do not multiply NECP/NCAR specific humidity by 100 (1, kg/kg) and multiply it by 1,000 (2, g/kg). Coincidence of computing the of latent heat flux in the ROMS algorithm (ccsm_bulk) with the latent heat flux in the data NECP/NCAR data is good enough only when NECP/NCAR humidity is multiplied by 100 (3, kg/kg in %). I'm not able yet to find confirmation of this in the ROMS code.

Regards,

[tony1230]

Yes,i think you are right that roms needs SH for calculate the other term, but roms wants RH from input in uint % (am i right?). And i dont

follow why you did that for multiply the sh from NECP by 1000 to transform into g/kg unit. That dose not make any
sense.

I think so as follows.

1、As i can learn from the code that roms needs relative humidity.

Code: Select all

'Qair'                                             ! Input
  'surface air [color=#FF0000]relative humidity[/color]'                 !  relative    or  specific
  'percentage'                                    ! [percentage  or  g/kg    ]
  'Qair, scalar, series'
  'qair_time'
  'idQair'
  'r2dvar'                                        ! relative        specific
  1.0d0                                           ! 1/100      or   1.0

I want to believe it's not a typo here and its unit should be percentage.

2、We can see the data type and unit in file from NECP indicates specific humidity(sh) and kg/kg.So there ought to be

a transformation from SH to RH.

Code: Select all

!  Compute specific humidity, Q (kg/kg).
!
          IF (RH.lt.2.0_r8) THEN                       !RH fraction
            cff=cff*RH                                 !Vapor pres (mb)
            Q(i)=0.62197_r8*(cff/(PairM-0.378_r8*cff)) !Spec hum (kg/kg)
          ELSE          !RH input was actually specific humidity in g/kg
            Q(i)=RH/1000.0_r8                          !Spec Hum (kg/kg)
          END IF

From here and after, i know that roms needs Q(i), that is SH, through i dont konw why a IF...ELSE loop there. Here Q(i) needs air vapor
pressure from RH and Saturation air vapor pressure. Later one can calculate from Tair and Pair, but RH should be inputted.

3、We have Pair,Tair,sh from NECP, so the RH can be received by a formular RH=sh/SH. sh directly get from NECP and SH be from 0.622*(P(H2O)/(Pair-P(H2O)).


Anyway, it's mine understanding on this point. Frankly, i dont have a thorough grasp of some terms and units, e.g.

Code: Select all

!  Compute air saturation vapor pressure (mb), using Teten formula.
!
          cff=(1.0007_r8+3.46E-6_r8*PairM)*6.1121_r8*                   &
     &        EXP(17.502_r8*TairC(i)/(240.97_r8+TairC(i)))

Here cff is the air saturation vapor pressure and i have never seen the trem (1.0007_r8+3.46E-6_r8*PairM) before. Is it saying that if we omit this term, cff is the actual air vapor pressure at a given Tair?


Any recommendation/comment would be appreciated, thanks.

- Shou

[Pysh]

I use the module ccsm_bulk (not bulk_flux). I'm not sure, but in this algorithm is not provided for by entering RH, only SH in kg/kg. Coefficient which transform the input variable is governed by the parameters of the Qair in file varinfo.dat By default, this is, as I understand, 0.01 (for RH in percentage). Correctly in my case (ccsm_bulk and NCEP/NCAR input specific humidity in kg/kg) to change these settings on the 'specific' and coefficient on 1.0. If you do not change the settings in the file varinfo.dat, the input field SH should be multiplied by 100. Confirmation of this is a coincidence of values of latent heat flux in the output of the ROMS and the data of NCEP/NCAR
As for

i have never seen the trem (1.0007_r8+3.46E-6_r8*PairM) before.

look, for example http://en.wikipedia.org/wiki/Relative_humidity

Regards

[kate]

If you don't like the trunk roms code, submit a bug report in Trac.

In my branch, I make a cppflag which ought to be renamed MKS_HUMIDITY or some such, when ROMS is being provided with humidity in kg/kg (the bulk flux code converts to that if you give it something else).

We also have the bulk flux option from CCSM, which only expects humidity as kg/kg.

[wilkin]

Code: Select all

!  Compute specific humidity, Q (kg/kg).
!
          IF (RH.lt.2.0_r8) THEN                       !RH fraction
            cff=cff*RH                                 !Vapor pres (mb)
            Q(i)=0.62197_r8*(cff/(PairM-0.378_r8*cff)) !Spec hum (kg/kg)
          ELSE          !RH input was actually specific humidity in g/kg
            Q(i)=RH/1000.0_r8                          !Spec Hum (kg/kg)
          END IF

This is legacy code from very old versions of ROMS, and potentially precursors to ROMS. It was designed to catch the case where the input was unwittingly provided as specific humidity rather than relative humidity in percent. There is no way RH in percent could be less than 2%, so it must be Specific Humidity.

These days, with more rigorous metadata practices and far more flexible I/O code for ROMS, we would never write code this way. But it is difficult to remove old code from ROMS without risking breaking someone's ancient version. So these things live on.

That said, we are receptive to users who carefully review code like bulk_fluxes.F and are alert to long-standing bugs. It happens. Bulk_fluxes.F is rather straightforward code to read if ones bothers to read the papers that describe the science that underpins it.

[tony1230]

Thanks for all your reply

Yes, John, you are right. I have mentioned in my first post

Code: Select all

I have simply got the SH from NECP file in unit kg/kg and have seen values both LT and GT 2.0(g/kg).

, but i neglected to take RH(values in percentage) into account. The RH in % could never less that 2(2%). In this case, RH is actually the SH. In fact, i have done the case just inputting the sh to the ROMS directly from NECP before i saw your's replies and the model result(especially water temperature) represents much the same as that of transformation case.Also i do understand what Pysh said

Code: Select all

multiply it by 1,000 (2, g/kg)

, because in the bulk_flux.f, it says

Code: Select all

Q(i)=RH/1000.0_r8                          !Spec Hum (kg/kg)

,here RH divired by 1000.0. But if this is the case, i think it's otiose for *1000 then /1000. And it's not a bug to ROMS, it's a tricky.

Satisfactory on this discussion. Thanks.

- Shou

[likerice]

I have been setting up an application with bulk fluxes and think I understand what is going on in the unsavory code:

Code: Select all

!  Compute specific humidity, Q (kg/kg).
!
          IF (RH.lt.2.0_r8) THEN                       !RH fraction
            cff=cff*RH                                 !Vapor pres (mb)
            Q(i)=0.62197_r8*(cff/(PairM-0.378_r8*cff)) !Spec hum (kg/kg)
          ELSE          !RH input was actually specific humidity in g/kg
            Q(i)=RH/1000.0_r8                          !Spec Hum (kg/kg)
          END IF

I disagree with what Dr. Wilkin says above; what I think is going on here is that the code executes the IF block when the user provides relative humidity, which is multiplied by the scale factor (.01) to obtain "RH fraction."

The ELSE block is meant for the case where the user provides specific humidity in g/kg, in which case one simply divides by 1000 to convert units to kg/kg.

I think the cutoff of 2.0 is because specific humidities are rarely below 2.0 g/kg over the ocean. I attached a plot of surface specific humidity from NCEP to illustrate this; the q=2 g/kg contour is highlighted in white.

Thus the purpose of the if/else block is not to catch a user error, but rather to distinguish whether the user provides relative humidity or specific humidity. The user should be careful that they specify the correct scale factor in varinfo.dat, depending on whether they provide relative (.01) or specific (1.0) humidity.

[arango]

Indeed, I believe that unsavory piece of code was in the original COARE code. It is quite clever if you ask me. I recall putting enough comments in the code when I did some research about this threshold value many years ago.

There is not a standardized unit for specific humidity in the atmospheric data sets. It can be a fraction, percentage, unitless, nondimensional, or no unit attribute at all. One could test for the units for specific humidity (g/kg; kg/kg) to decide if input data is relative or specific. The only concern is that some users don't pay much attention to metadata in the NetCDF files. The kludge in bulk_flux.F to differentiate between relative and specific is quite robust.