were coded longtime ago when we were testing the EcoSim
bio-optical model in the late 90's. It was like twenty years ago. So I don't remember the details. At that time, both routines were intended for idealized toy problems for debugging purposes. The EcoSim
model is quite complex and may have up to 60 spectral bands, and we needed surface solar downwelling spectral irradiance. One needs to be very precise in the terminology when dealing with bio-optical models.
In practical applications, we get the shortwave, and longwave radiation fluxes from atmospheric models and the data need to resolve the daily cycle. The turbulent boundary layer between atmosphere and ocean is complicated with various spatial and temporal scales (see CBLAST
cartoon below), and the upward and downward fluxes depend if you are looking in terms of the atmosphere or the ocean. It is due to the monotonic ascending (atmosphere) or descending (ocean) discretized vertical coordinate.
I want to be very clear about the nomenclature in the ocean (ROMS) about surface fluxes:
Heat Flux: Downward Flux = heating (positive); Upward Flux = cooling (negative)
E - P Flux: Downward Flux = salting (positive); Upward Flux = freshening (negative)
The heat flux in the atmosphere is reversed
and the moisture flux is actually P-E
. I imagine lots of ROMS users processing the atmospheric forcing incorrectly. It will take a long time in the simulation to feel the wrong direction of the flux. Recall that these fluxes are applied as surface conditions to the vertical diffusion equations, and its kinematic values are small (around E-05).
I highly recommend
using the downward fluxes for shortwave and longwave radiation
and make the corrections to the shortwave
due to the mean absorption in the cool-skin layer, and removing the outgoing infrared radiation from the longwave
due to the sea surface temperature (-emiss*StBolt*SST^4
; where the SST is in Kelvin). Now, the surface fluxes get more complicated when we have sea ice. It is tricky, if not impossible, for ROMS to check these fluxes and figure out what the user provided. It will require a rigorous metadata model, which most everybody ignores. Recall that the user controls the metadata that goes into ROMS via the customizable input file varinfo.dat
Now, ROMS clock was reworked recently (see trac ticket 724
). The time in ROMS is always with respect to the Greenwich Mean Time
), also known as Coordinated Universal Time
). If you are using any other time zone, you will likely get into trouble when dealing with atmospheric forcing, tidal forcing, coupled Earth Modeling Systems (ESMs), analysis against observations, data assimilation, and any other application with forcing sensitive to the time clock.
Therefore, I haven't reread the literature about the shortwave to check if we have a bug or not. But one needs to be aware of the time clock and default GMT
time zone in ROMS. It will be insane using any other time zone in a ROMS application.