freshwater flux and cloud in bulk flux

[hseo]

Hi all,
I have two questions about using bulk_flux.F in ROMS.
To use bulk_flux.F, we have to provide swflux(E-P) among other lower meteorological variables.
How do you guys calculate swflux? I've been using very a simple relation to do it from latent heat flux and precipitation rate (+ constant Latent heat of vaporization) from my atmospheric model.
But in fact, this could be easily and more corretly computed in bulk_flux.F, since latent heat flux is calculated in there internally, and rain rate is also prescribed as a forcing.
Latent heat of vaporization is also taken to be a function of SST, which is better than just assuming that it is constant.
I did some test runs and noticed that there is some, if not significant, change in swflux between (mostly increase of swflux in my case).
Also since in most cases, the ocean model grid is relatively finer than that of the atmospheric model, swflux that computed in finer grid in ROMS presumably better represents the ocean state.
So the simple minded guess is that I could add a small part of calculating swflux in bulk_flux.F and do not provide swflux in the bulk forcing function. And I wonder if this sounds reasonable.

Second thing is that if you "undefine" LONGWAVE while "define" BULK_FLUX, I see some error message while compiling the codes, such as "cloud is not a member of this RECORD (bulk_flux.f90)".
So I thought I add "#ifdefined LONGWAVE" and "#endif" at every apperance of "cloud" in bulk_flux.F.
I wonder if this is ok or not.

Thanks
Hyodae

[wilkin]

You are correct that the evaporation rate can be computed within bulk_flux from the latent heat term by adding additional code in the manner you describe. This evaporation needs to be subtracted from a specified rain rate and saved as a net freshwater flux. Then when specifying the surface boundary condition for salinity you must convert the freshwater flux to an equivalent salt flux using the surface salinity and thickness of the upper layer.

In this case an imposed swflux(isalt) is not used, but you need to provide rain rate data in a forcing netcdf file (or use ANA_RAIN to set it).
This is not really a very well-posed way to handle freshwater fluxes but ROMS is cast as a constant volume rather than constant salt model (like most primitive equation models of it's type).

We have implemented code like this is our most recent versions and we are presently testing it in a couple of applications. To do this sensibly for a practical application one needs to save both the net e-p and the implied surface salt flux in order to be able to do post-processing bugets of salt tracer. This changes the way the swflux on output is defined, so we have amended that code too. The next major release of the model will include these additions when we are confident they are correct.

John.

[wilkin]

Second thing is that if you "undefine" LONGWAVE while "define" BULK_FLUX, I see some error message while compiling the codes, such as "cloud is not a member of this RECORD (bulk_flux.f90)".
So I thought I add "#ifdefined LONGWAVE" and "#endif" at every apperance of "cloud" in bulk_flux.F.
I wonder if this is ok or not.

#define LONGWAVE implies you wish to compute net longwave internally from the air amd surface marine conditions using the Berliand formula.

If you #undef LONGWAVE this implies you intend to read net longwave from a forcing netcdf file.

If you are getting an error related to the CLOUD option then this must be due to something else in your configuration. The Berliand formula needs cloud data so it must be provided either from analytical of a forcing netcdf file.

John.