Possible bug regarding humidity and ice

[jaustin]

I'm working on using ROMS to look at interannual variability in Lake Superior. I'm using "realistic" meteorological forcing and am using the ice model.

Humidity is very oddly treated in ROMS. As I understand, ROMS looks at the size of the number in the humidity variable and uses this to determine whether it is specific or relative humidity (<2 is fractional relative humidity, >2 is specific humidity). (We'll put aside the fact that this could cause confusion with extremely cold, dry air). More importantly, when ICE_MODEL is defined, specific humidity is assumed. This becomes a problem when you try to input specific humidity from an outside forcing file, since ROMS automatically scales humidity by 100, to go from percentage to fractional relative humidity. If you input specific humidity instead, this results in air 100x drier than you intend, which causes unrealistically large (negative) latent fluxes.

I have kludged this for myself for the short term by changing the scaling value for humidity in varinfo.dat, since I know I am going to be using specific humidity with the ice model. However, perhaps it would be advisable in the future to have a cpp flag which allows the user to specify what sort of humidity they are using. This would remove any ambiguity.

jay-

[kate]

Hear, hear! We did the same, knowing our humidity is coming in as kg/kg.

[jaustin]

Kate-

Did you mean to say that you specify it in g/kg? Both bulk_flux and ice_bulk_flux assume that the humidity input is in g/kg if ICE_MODEL is defined, and both immediately divide by 1000 to get it into units of kg/kg.

I have done comparisons between ROMS outputs of bulk (sensible and latent) fluxes to the equivalent determined by a bulk-flux algorithm (TOGA-COARE) using the water temp, air temp, wind speeed, and humidity. This comparison works well for latent flux when the humidity in the forcing file is determined in g/kg, and the scaling for humidity in varinfo is set to 1.0.

Another very minor bug: If you output surface heat flux components in a stations file, the units are C/m, not W/m2 as the NetCDF file implies. You need to scale these outputs by rho*Cp in order to get them into units of W/m2.

jay-

[kate]

Hi Jay,

No, I meant kg/kg. Paul Budgell is the one using g/kg with his ice model.

Good catch on the stations - I haven't looked at those fluxes.

[arango]

The station data for all the heat fluxes are scaled to W/m2. So I don't know what are you talking about. In wrt_station.F we have:

Code: Select all

!
!  Write out surface net heat flux.
!
      IF (Sout(idTsur(itemp),ng)) THEN
        ifield=idTsur(itemp)
        scale=rho0*Cp
        CALL extract_sta2d (ng, iNLM, Cgrid, ifield, r2dvar,            &
     &                      LBi, UBi, LBj, UBj,                         &
     &                      scale, FORCES(ng)%stflx(:,:,itemp),         &
     &                      Nstation(ng), Xpos, Ypos, psta)
        CALL netcdf_put_fvar (ng, iNLM, STAname(ng),                    &
     &                        TRIM(Vname(1,ifield)), psta,              &
     &                        (/1,tSTAindx(ng)/), (/Nstation(ng),1/),   &
     &                        ncid = ncSTAid(ng),                       &
     &                        varid = staVid(ifield,ng))
        IF (exit_flag.ne.NoError) RETURN
      END IF

[jaustin]

When I read the surface heat flux fields (latent, sensible, lwrad, swrad, or shflux) from a station file, the values are all about rho*cp (~4x10^6) times smaller than would be expected. I don't have this problem with fluxes read from a history file.

I'm using 3.0- this may be the problem- I haven't updated in a while.

jay-

[Paul_Budgell]

Actually, now I use a SPECIFIC_HUMIDITY directive like Kate does and units are kg/kg. You also need to apply the modified humidity calculation in computing net solar radiation at the surface in ana_srflx.h, as well, if using ANA_SRFLX.

The way ROMS does it in the standard release fails over the very low humidity Arctic ice cover.

[wilkin]

Jay,

If this is indeed just a problem with versions, would you please compare the relevant lines of code that Hernan flagged so we don't go looking for bugs that are no longer there.

As a suggestion to users such as yourself who are reluctant to svn update regularly (I do understand this reluctance), remember that the build.bash script reads source code from the directory you instruct it to with the MY_ROMS_SRC variable.

So you can keep your working code in one directory, and also keep an up-to-date version from the myroms repository in another, and switch between them to test your compatibility with newer release without breaking what you have. Your build.bash will still pick up your customized Functionals (ana_*.h), cppdefs header file, ocean.in etc that you keep in the MY_PROJECT_DIR where you invoke build.bash.

If you have made modifications to some core ROMS routines (like bulk_fluxes.F) in your working directory, you would of course have to make these in the new directory that you are going to keep current with svn update, but recall that svn update preserves user customizations so long as it can reconcile diffs during the update step (and will warn if it can't). If you get a mess, you still have your working directory untainted.

The more users that do this switch and compare the more effective the community will be at reporting adverse impacts of recent updates, and hopefully foster less reticence to svn update.

John.