Ocean Modeling Discussion

ROMS/TOMS

Search for:
It is currently Thu Apr 19, 2018 1:36 pm




Post new topic Reply to topic  [ 9 posts ] 

All times are UTC

Author Message
PostPosted: Thu Jul 14, 2011 9:15 am 
Offline

Joined: Tue Feb 01, 2005 8:21 pm
Posts: 121
Location: Istanbul Technical University (ITU)
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:
'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


Top
 Profile  
Reply with quote  
PostPosted: Thu Jul 14, 2011 5:21 pm 
Offline
User avatar

Joined: Wed Jul 02, 2003 5:29 pm
Posts: 3357
Location: IMS/UAF, USA
If you look in bulk_flux.F, you will find this unsavory code:
Code:
!  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.


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 16, 2012 10:36 am 
Offline

Joined: Wed Mar 31, 2010 3:29 pm
Posts: 87
Location: SKLEC,ECNU,Shanghai,China
Okay, on this topic, Kate have mentioned in a earlier thread in 2008 https://www.myroms.org/forum/viewtopic.php?f=4&t=1032&hilit=RH, but it's remain unresolved. :?: :cry:

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:
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


Top
 Profile  
Reply with quote  
PostPosted: Sat Nov 17, 2012 7:30 am 
Offline

Joined: Tue Nov 29, 2011 3:51 pm
Posts: 30
Location: Hydrometcenter of Russia
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,


Top
 Profile  
Reply with quote  
PostPosted: Sun Nov 18, 2012 2:20 am 
Offline

Joined: Wed Mar 31, 2010 3:29 pm
Posts: 87
Location: SKLEC,ECNU,Shanghai,China
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:
'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:
!  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:
!  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


Top
 Profile  
Reply with quote  
PostPosted: Sun Nov 18, 2012 10:26 pm 
Offline

Joined: Tue Nov 29, 2011 3:51 pm
Posts: 30
Location: Hydrometcenter of Russia
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
Quote:
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


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 19, 2012 5:23 pm 
Offline
User avatar

Joined: Wed Jul 02, 2003 5:29 pm
Posts: 3357
Location: IMS/UAF, USA
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.


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 20, 2012 2:00 am 
Offline
User avatar

Joined: Mon Apr 28, 2003 5:44 pm
Posts: 439
Location: Rutgers University
Code:
!  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.

_________________
John Wilkin: IMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 20, 2012 2:10 pm 
Offline

Joined: Wed Mar 31, 2010 3:29 pm
Posts: 87
Location: SKLEC,ECNU,Shanghai,China
Thanks for all your reply

Yes, John, you are right. I have mentioned in my first post
Code:
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:
multiply it by 1,000 (2, g/kg)
, because in the bulk_flux.f, it says
Code:
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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group