Which heat fluxes to input when using bulk formulation?

[jabsy]

Now in the right section, sorry for double posting.

Dear ROMS users -

Could anyone, please, indicate which heat fluxes should I input to ROMS when using bulk formulation?

From the information in /Data/roms/CDL/fcr_bulk.cdl I couldn't understand what SWRAD (solar shortwave radiation) actually means, is it a net flux? If so why not mention it on its longname, and LWRAD, is it expected to be downward minus upward longwave surface radiation?

Thank you very much
Joao Marcelo Absy
INPE

[kate]

swflx is the shortwave flux, but it may or may not include the effects of albedo. The ice model computes its own albedo, so you'd want to have only the incoming shortwave radiation. You can investigate what the ALBEDO flag does in ROMS, but you might then have to include CLOUDS for ROMS to compute the albedo.

As for lwflx, you again have a choice, but you have to tell ROMS which choice you've made. If you provide the incoming longwave, then ROMS will compute the outgoing longwave (our preferred method). See cppdefs.h:

Code: Select all

**   There are three ways to provide longwave radiation in the atmospheric   **
**   boundary layer: (1) Compute the net longwave radiation internally using **
**   the Berliand (1952) equation (LONGWAVE) as function of air temperature, **
**   sea surface temperature, relative humidity, and cloud fraction;         **
**   (2) provide (read) longwave downwelling radiation only  and then add    **
**   outgoing longwave radiation (LONGWAVE_OUT) as a function of the model   **
**   sea surface temperature; (3) provide net longwave radiation (default).  **

[jabsy]

Dear Kate, thank you for the prompt reply and tips. I have been through set_data.F, bulk_flux.F,
cppdefs.h, ana_srflux.h and checkdefs.F, but I still have some doubts concerning srflx.

The atmospheric model I am trying to use as roms forcing provider gives me, among others:

CLOUD COVER
DOWNWARD LONG WAVE AT BOTTOM
UPWARD LONG WAVE AT BOTTOM
DOWNWARD SHORT WAVE AT GROUND
UPWARD SHORT WAVE AT GROUND
UPWARD SHORT WAVE AT TOP
SHORT WAVE ABSORBED AT GROUND

lrflx: With that I have no problems anymore. If I understood correctly, when BULK_FLUXES is on
I can either 1.input the net flux directly (downward-upward), 2. input the downward radiation only (must turn
on LONGWAVE_OUT) or 3. input nothing and let roms deal with it via LONGWAVE flag. I will make experiments with both the
net flux and the downward only and see which one remains closer to observations.

srflx: Following the same principle for lrflx if BULK_FLUXES is on, roms will expect srflx field. If I do not provide, roms can obtain it via ANA_SRFLUX flag with or without the ALBEDO flag. When the last is on, one should provide Hair, CLOUD and Tair. If I do provide srflx computed from averages of more than 24hs I have the option to turn on DIURNAL_SRFLUX to modulate the diurnal cycle... am I right so far? Still, since I do not have the ice model on so far, from the variables I listed above for shortwave radiation, which one(s) would roms ideally prefer with BULK_FLUXES option on?

Thanks once more,

Joao Marcelo Absy
INPE

[kate]

I don't think ROMS cares, one way or the other.

We are using an atmospheric field which provides daily downward shortwave, but not clouds. What I use is ALBEDO and the DIURNAL_SRFLUX. I don't have clouds, so have to come up with a kludge to make ALBEDO work, which is a latitude-dependent guess as to typical albedo for the Bering Sea.

[wilkin]

Joao,

Your summary of options regarding shortwave and longwave forcing is quite accurate.

If you have longwave data from an atmospheric model then that is almost certainly superior to using the Berliand parameterization. The choice to make is whether to have ROMS compute the outgoing flux, or specify the net. You'll have to be the judge of that.

You will want to calculate DOWNWARD SHORT WAVE AT GROUND minus UPWARD SHORT WAVE AT GROUND to get the NET, and give this as swrad. You then do not specify anything about clouds because cloudiness effects are already in SHORT WAVE from the atmosphere model. Nor do you specify albedo - it is effectively the ratio UPWARD/DOWNWARD.

Then also set SHORTWAVE so that the radiation is absorbed over some depth range set by the WTYPE options in ocean.in. These are described in the wiki.

If your shortwave is not well resolved in time (say only 6 hourly), then you might want to average to daily values, and then set DIURNAL_SRFLUX to capture the extremes of noon time heating. The ecosystem models can be sensitive to the diurnal mixed layer thickness and peak light available for photosynthesis.

John.

[jacopo]

Then also set SOLAR_SOURCE so that the radiation is absorbed over some depth range set by the WTYPE options in ocean.in.

[jabsy]

Thanks Kate, John and Jacopo. Great help!!

[leonjld]

If I am understanding correctly, ROMS will also calculate sensible and latent heat flux if BULK_FLUX is on. My question is: for latent heat flux, does that mean user must provide precipitation data (either by forcing file or analytical function)? and does ROMS calculate evaporation by itself or assume the precipitation provided is the net flux? Thanks!

[wilkin]

If you define EMINUSP then the evaporation is computed proportional to the latent heat calculated in bulk_flux, and with an input precipitation (either analytical, or from a forcing netcdf input file) the net E-P is applied in the form of the appropriate equivalent salt flux.

[turuncu]

Hi,

It could be a basic question but i am little bit confused to calculate the net shortwave and longwave fluxes in forcing input. If i use the NCEP/NCAR as a forcing input, the surface upward and downward fluxes can be used to estimate the net fluxes.

For the shortwave flux this must be,

Code: Select all

swrad = dswrf-udwrf

so it is simply downward-upward. For longwave radiation the Roms_tools MATLAB package uses upward-downward to calculate net longwave fluxes.

Code: Select all

lwrad = ulwrf-dlwrf

but in this case the net longwave flux will be positive for whole year. Is this calculations correct? In the forcing file negative values indicates the cooling and positive ones heating. So, according to the definition in the the forcing file, net longwave radiation must be calculated in a same way with net shortwave. What do you think?

Thanks,

--ufuk

[wilkin]

I don't use the ROMS_tools code so can't speak to what sign conventions or conversion it might make.

But I do regularly download atmospheric forecasts from the opendap server at http://nomads.ncep.noaa.gov:9090/dods/nam which is the NCEP WRF model forcast system. From those data I compute NET longwave as dlwrfsfc minus ulwrfsfc.

For example, in a box encompassing the northeast US coastal region the daily min/max values of NAM net longwave are plotted here:
http://marine.rutgers.edu/~wilkin/wip/c ... lwrad.html
The result can have either sign depending on atmospheric water vapor, clouds, and ocean temperature.

For comparison, the range of downward longwave values in the same region are here:
http://marine.rutgers.edu/~wilkin/wip/c ... _down.html
These values are always positive meaning downward longwave from the atmosphere is warming the ocean.

The thing to do is check that the values that end up in your forcing file make sense oceanographically and follow the documented sign convention.

[turuncu]

Hi,

Thanks for your reply. I don't use the ROMS_Tools either. I wrote my own tool using NCL and i check the ROMS_Tools to be sure about calculation of the fluxes. If you suggest any other tools that can get inspiration, please let me know.

The region that i actually interested in Caspian Sea and the monthly net longwave radiation flux is always negative in this region. So, i think that i have to calculate the net longwave radiation as downward-upward but i have still no idea why the ROMS_Tools calculate the net longwave flux in this way. May be i could ask to them. Anyway, thanks for the clarification.

--ufuk

[kate]

Some of us provide the downward longwave flux from an atmospheric model and let ROMS compute the upward longwave flux because it is strongly dependent on the surface temperature of the ocean.

[jabsy]

Hi Ufuk,

In roms_tools they use upward-downward as you mentioned, but I think their sign conventions is inverted in relation to ROMS/TOMS'es.

roms/Data/ROMS/CDL/fcr_bulk.cdl, states:

float swrad(time, eta_rho, xi_rho) ;
swrad:long_name = "solar shortwave radiation" ;
swrad:units = "Watts meter-2" ;
swrad:positive_value = "downward flux, heating" ;
swrad:negative_value = "upward flux, cooling" ;
swrad:time = "time" ;
float lwrad(time, eta_rho, xi_rho) ;
lwrad:long_name = "net longwave radiation flux" ;
lwrad:units = "Watts meter-2" ;
lwrad:positive_value = "downward flux, heating" ;
lwrad:negative_value = "upward flux, cooling" ;
lwrad:time = "time" ;

while roms_tools/create_bulk.m:

nw{'radsw'} = ncdouble('bulk_time', 'eta_rho', 'xi_rho');
nw{'radsw'}.long_name = 'shortwave radiation';
nw{'radsw'}.units = 'Watts meter-2';
nw{'radsw'}.positive = 'downward flux, heating water';
%%
nw{'radlw'} = ncdouble('bulk_time', 'eta_rho', 'xi_rho');
nw{'radlw'}.long_name = 'net outgoing longwave radiation';
nw{'radlw'}.units = 'Watts meter-2';
nw{'radlw'}.positive = 'upward flux, cooling water';

I don't know how their ROMS works, but I hope this clarifies something! Also, I noticed that relative humidity, precipitation rate and atmospheric pressure differ from what ROMS/TOMS CDL file recommends!!!!

However, I use the same NCEP products as roms_tools for some of my experiments, and therefore I am also interested in understanding how they fit best to ROMS/TOMS:

http://nomad1.ncep.noaa.gov:9090/dods/r ... x/flx.info

In those, either upward or downward long wave flux fields are all positive values, with upward fields being generally greater (at least for the south-Atlantic). I assume this data are similar (in format, convention, units...) to those used by Wilkin, so, his procedures should apply to them as well, i.e. down-up to calculate net surface long wave flux. I did some tests and the resulting net flux calculated for my region was negative almost everywhere, anytime except for very specific regions associated to the low pressure systems advected by the westerlies at mid-latitudes in the south-Atlantic. The values fall in the same range as Wilkin's figure show, so I believe this is indeed the right path to go, just remember to set the sign convention properly.

Best,
Joao Marcelo Absy

[turuncu]

Hi,

Thanks for the clarification. Now, it is much more clear for me. I also did some tests using NCEP/NCAR Reanalysis after fixing the calculation of the net fluxes but the model is still cold in almost each season after 10 year simulation. In this case, the same forcing is applied perpetually. You can see from the attached plot. Now i will try to use different datasets such as NNRP2, ERA40 and ERA Interim to compare the results. I saw a paper for same region that the flux variable are multiplied by 1.05 to get realistic results from their ocean model (HYCOM).

[jabsy]

Have you tried as Kate proposed? You could use only downward flux instead of net, for that you just need to insert flag LONGWAVE_OUT on your cppdefs file. Would be interesting to see how it compares to the run you just showed.

[turuncu]

Yes. I have already done that test. Actually this results belong to it. The lake is much more warmer than this when i used the net longwave and net shortwave (without LONGWAVE_OUT) but i don't know why it is colder in this case.

--ufuk

[jabsy]

My results also show abnormal cooling in the southern ocean, but I am hoping to fix that with the ice model, which I am trying as we speak. I am not sure if it applies to your region, but maybe adding the sea-ice module might help too!?
Other than that, good luck with the other forcing data-sets.

[turuncu]

Thanks for your suggestions and help !!!

I am also planing to use the version that has ice model but first of all i need to be sure that model simulates the climatological behavior of the lake. The main thing is that the northern part of the lake is covered by ice in the winter season but the surface temperature looks much more realistic in winter (without ice model). So, i think that the problem is not related with ice. Now, i try to test the model with different mixing and viscosity parameters. May be it helps.

[xkhmyx]

I want use NCEP NARR model results as atmosphere inputs for ROMS.
I prefer that atmosphere parameters are all from NARR, rather than calculated by ROMS (not sure if this is tne best solution).
Thus I want undefine LONGWAVE and LONGWAVE_OUT

If I define BULK_FLUXES, I need winds, rain, air temperature, humidity and pressure, and NET longwave and shortwave radiation. What else (cloud, SST, evaporation) do I need?

How should I define these flags in the head file?
Below is modified after Wilkin's suggestion.

Thanks!

Kevin Xu, Coastal Carolina University
~~~~~~~~~~~~~~~~~~~~~~~~~

# define BULK_FLUXES
#ifdef BULK_FLUXES
# define ANA_WINDS
# define ANA_SRFLUX
# define ANA_TAIR
# define ANA_HUMIDITY
# define ANA_PAIR
# undefine LONGWAVE
# undefine LONGWAVE_OUT
#endif

[kate]

I assume you are reading the NARR fields from a file? If so, you don't want any of the ANA_XX values defined. Checking in globaldefs.h, it looks like ROMS wants Pair, Tair, Qair, rain, winds, shortwave and longwave fluxes.

[xkhmyx]

Dear Kate,

Below was how I defined the flags in the head file.

#define BULK_FLUXES
#undef LONGWAVE
#undef LONGWAVE_OUT

#define ANA_BSFLUX
#define ANA_BTFLUX
#define ANA_BPFLUX
#define ANA_SPFLUX

In the NC input file, I added Uwind, Vwind, swrad, lwrad, Pair, Tair, Qair and rain.
When I ran the model, however, it asked SST and dQdSST.
GET_2DFLD - unable to find requested variable: SST
GET_2DFLD - unable to find requested variable: dQdSST
We only need dQdSST when we define LONGWAVE, right?

I checked Adriatic Sea and Bio_Toy examples,
both BULK_FLUXES and LONGWAVE were defined.

Can anyone help me define the flags?
I want use NCEP NARR data as direct Netcdf inputs for ROMS,
and use option (3) described above, "provide net longwave radiation (default)".

Thanks!
Kevin Xu

[kate]

Do you have QCORRECTION turned on? That's what uses dQdSST.

[xkhmyx]

Kate, thanks for your reply.

Yes, QCORRECTION is on.
I will turn that off and see if it works.

Below are some flags I used:

#define ANA_M2OBC
#define ANA_FSOBC

#define QCORRECTION

#undef GLS_MIXING
#define MY25_MIXING
#define N2S2_HORAVG

#define BULK_FLUXES
#undef LONGWAVE
#undef LONGWAVE_OUT

#define ANA_BSFLUX
#define ANA_BTFLUX
#define ANA_BPFLUX
#define ANA_SPFLUX

Let me know if any flags are not right.

Kevin

[kate]

#undef GLS_MIXING
#define MY25_MIXING
#define N2S2_HORAVG

Let me know if any flags are not right.

Kevin

There are people who would pick the MY25 within GLS_MIXING rather than doing it this way. You could start a whole conversation about vertical mixing schemes...