Surface heat flux. Double the count?

[d.kobashi]

Dear ROMS users/developers,

This may be a 101 question, but I have a question about surface heat flux for my ROMS modelling. I am studying internal tides and mixing in shallow coastal waters.

I saw some posts on myroms.org that the inclusion of surface heat flux from weather forecast/reanalysis outputs often leads to overheating in the surface boundary layer. I have also had that. I vaguely remember that Hernan suggests on a post to use outputs from ERA-interim to include surface heat flux into ROMS. I compared various forecast/reanalysis outputs and surface heat flux from ERA-interim seems to be lower than others. So I tried ERA-interim; however, SST(and temperature in the surface mixed layer) is still overestimated (too much heat penetration) and that makes the model unstable, too. I tried SOLAR_SOURCE and QCORRECTION to adjust heat flux (satellite-based SST). High SST/sub-surface temperature still persists. I am also testing how changes in Jwtype affect thermal stratification and mixing in shallow water. As I use COAWST with nesting/coupling, I may need to modify its code to specify Jwtype for each nested domain.

My model imposes OBC using OGCM outputs. My question is that many OGCM outputs (e.g. HYCOM, MOM-based forecast/reanalysis, etc) imposed along each boundary and for initial conditions already include surface heat flux for their modelling. I am not sure if I am correct, but is it appropriate to include surface heat flux as forcing with OBC from OGCM outputs on my ROMS simulation? Does that double the count (i.e. Does my model include twice as much heat for the model)? or am I confused?

Without surface heat flux, SST is underestimated and with the flux, SST is overestimated. At this point, I think my temporary solution so far is not to include surface heat flux; however, that will certainly affect thermal stratification and vertical mixing in shallow water.

Any comments would be appreciated.

Thanks in advance.

DJ

[kate]

When keeping the heat fluxes, one more thing to play with is the albedo. The ALBEDO option now only shows up in ana_srflux.h, but one could imagine reading srflx from a file and then applying an albedo to it in say bulk_flux.F. We are currently using MERRA for atmospheric forcing and they supply a daily albedo field.

[rduran]

If there is a river in your region of study you might want to contact Dr. Alexander Kurapov from Oregon State University. He has recent research showing the effect of a river on the sea surface temperature of a ROMS model off the Oregon and Washington coasts. It has to do with how deep radiation penetrates the water column.

[d.kobashi]

Dear Kate and Rduran,

Thanks for your comments. They are helpful.


Kate,
As far as I checked, ALBEDO cpp option is used in Bulk_flux.F and ana_srflux.h (I use COAWST which is based on ROMS 3.4). So if I need to include albedo, I also need to define BULK_FLUXES and ANA_SRFLUX. If that is correct, that may be a problem. I computed surface heat flux by the sum of net long-wave and shortwave radiation fluxes, sensible heat and latent heat provided by ERA-interim. So there is shflux in my forcing netcdf file. I had a problem using surface heat flux from bulk_flux (by defining BULK_FLUXES). The model became unstable and the model result showed some unrealistic upwelling near the boundaries with a certain OBC combination, which was pointed out by Hernan in a post before. His suggestion was not to use bulk_flux.F, so I have stopped using it until I figure out what went wrong (overdue. still on my ToDO list).
Actually ERA-interim provides ALBEDO. Is there any way I can include albedo without including BULK_FLUXES? Does ROMS take care of ALBEDO if it is included in ROMS forcing netcdf file? There is no albedo forcing field for a forcing file, though (may be cloud fraction which estimates albedo internally in ROMS?).

Also, Dr. John Wilkins mentioned in the post entitled "Which heat fluxes to input when using bulk formulation?" that atmospheric models include cloud effects and albedo for short wave radiation already. I need to check if this is applied for ERA-interim.

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.

Rduran,
Yes. there are rivers in my region (East Australia coasts); however, river discharge is considered insignificant at least for the targeted region of my interest (in nested domain) and the simulation period (based on streamflow records). Thus, I have not included freshwater runoffs yet. I will contact Dr. Alexander Kurapov and try to look at findings of his recent research (or simply search his name to find his paper(s)). It is an interesting topic.

Thanks both again for your comments.


DJ Kobashi
Griffith University

[rduran]

Yes, i found it very interesting, I'm not sure if there is a paper out yet because it seemed a very recent result, but he might have a poster or something like that. Turns out that the Columbia river output is very important to get SST right off the norther US West coast. But that is a very big river though.

[d.kobashi]

Dear Rduran,

Thanks for your comment. Not sure if you are aware of this, but after some search, I've just found his manuscript submitted to JGR (SST variability influenced by river plume).
You can download it from the following link.

http://ingria.coas.oregonstate.edu/pdf/ ... _08_06.pdf

Thanks go to Dr. Kurapov for sharing the manuscript.

Best regards,

DJ

[rduran]

Did not know that thanks to all for sharing.

[wilkin]

The ALBEDO option in ROMS is a bit of a misnomer because it is not really related to the albedo (reflectance) of the sea surface, but rather is used to activate an analytical formulation for the net solar radiation entering the ocean. The relevant code is in ana_srflux.h and includes references to the algorithm:

Code: Select all

!  ALBEDO option: Compute shortwave radiation flux using the Laevastu
!                 cloud correction to the Zillman equation for cloudless
!  radiation (Parkinson and Washington 1979, JGR, 84, 311-337).  Notice
!  that flux is scaled from W/m2 to degC m/s by dividing by (rho0*Cp).

If is therefore just one way of specifying an analytical shortwave radiation field. Reading further down in ana_srflux.h you will find other options, such as the very simple constant radiation in the UPWELLING example activated with ANA_SRFLUX.

As with all forcing fields in ROMS, if an analytical option is not active then the default is for the model to look in a forcing netcdf file for the data. Hence if neither ALBEDO nor ANA_SRFLUX are defined ROMS will go looking for swrad in a netcdf file.

In this situation you must provide the NET (downward minus upward) solar radiation. My earlier comments about this were to reinforce that you need to preprocess your data accordingly depending on the source. In the case of ECMWF ERA Interim there is an option to obtain net solar directly. For other products - especially analysis fields from WRF model output (e.g. NCEP NAM and NARR) - you need to compute the net from the up and down. Activating the ALBEDO option WILL NOT do this for you (hence it's not the best name for the option, but remains for legacy reasons).

In most implementations of WRF that we have worked with, a constant value has been assumed for the sea surface albedo that is independent of wind speed or sea state (two factors that in reality affect ocean albedo). If you know this constant factor you could actually fool ROMS into making the adjustment by using downward solar radiation and applying the appropriate scale factor in varinfo.dat. But this is risky if you have poor practices for tracking tricks like this in your personal metadata. If you do this you might also rename "swrad" in varinfo.dat to be some other variable name - like "swrad_down" - that you use in your netcdf file to guard against copying your varinfo.dat for another application and forgetting that you fiddled with net solar.

[kate]

Perhaps you can see from this that (a) there's more than one way to do it, and (b) it's important to your solution to get it "right".

Those of us with sea ice in our model prefer to keep swrad as incoming swrad and let the albedo send back some of it. How much depends on what's at the surface.

ROMS as distributed has one option for bulk_flux.F. Not everyone believes that that uses the best algorithm for computing the bulk fluxes. We have started using that found in CESM instead. In either case, I'm a believer in computing it yourself based on the model's SST instead of relying on a computation using some other SST.

[wilkin]

Outgoing shortwave doesn't depend on SST, and in fact depends very little on anything that ROMS is computing unless you have modeled the sea ice.

The albedo of the ocean surface depends principally on solar zenith angle (the geometry of the illumination and subsequent reflection), the wind speed (through roughness, and sea state), and chlorophyll and other optically active dissolved or particulate matter (because if a satellite can see something in the visible band then it has affected the shortwave reflectance i.e. albedo).

Look-up tables for ocean albedo are provided by Jin et al. (2004) and subsequent articles that have cited the work:

Jin, Z., T. P. Charlock, W. L. Smith Jr., and K. Rutledge, 2004: A parameterization of ocean surface albedo. Geophys. Res. Lett., 31, L22301, doi:10.1029/2004GL021180

One could certainly make a case for us adding something like Jin's algorithm to compute net swrad from downward (like we compute outgoing longwave from SST with the LONGWAVE_OUT option). This could suffice for wind speed and solar zenith, but would only be a very approximate treatment of the optical activity of chlorophyll.

A problem we have struck in applications with shallow optically clear water is that the shortwave that reaches the seafloor is absorbed there (in ROMS) which can cause unrealistic heating. In reality the seafloor has an albedo and can return shortwave to the surface, and out of the ocean, that does not contribute to heating. In any part of the ocean where bedforms are visible from the sea surface, this situation exists (because you only see bedforms if visible light has gotten back to the surface).

[d.kobashi]

Thanks for your comments, Kate and John,

I learned a lot about what ROMS does on ALBEDO thanks to your comments.
Reading a comment from John, I am a bit confused about how ROMS reads forcing files.

As with all forcing fields in ROMS, if an analytical option is not active then the default is for the model to look in a forcing netcdf file for the data. Hence if neither ALBEDO nor ANA_SRFLUX are defined ROMS will go looking for swrad in a netcdf file.

I understand that if we don't define whatever ANA_????, ROMS searches for actual forcing parameters in a forcing netcdf file as John said. But if I don't use BULK_FLUXES, I thought we need to pre-process shflux (net surface heat flux) by summing latent heat, sensible heat and net longwave and shortwave radiations. That's what I usually do(I have not used BULK_FLUXES recently). If that's the correct way, what is the purpose to include shortwave radiation in a forcing netcdf file except for KPP parametrization? Does ROMS compute surface heat flux inside ROMS if I provide those four parameters separately in a netcdf forcing file? I am checking ROMS source code.

Sounds like if I want to tweak incoming solar radiation, I need to use NOAA's products not ECMWF's, which only provides net radiations (I already have pre-processing scripts to create forcing files based on NOAA's GFS/CFSR so I am ok with that).

As Kate said, there would be more than one way to do. I will look into the matter in more detail, try some and see what I get. I read the Jin's paper John mentioned. It is an interesting paper. I will dig more to find detailed algorithm mentioned in the paper if any.


Thanks again for your comments.

Best regards,

DJ Kobashi, Griffith University

[wilkin]

If you #define SOLAR_SOURCE then the specified net shortwave radiation is propagated vertically into the water column and absorbed internally according to a double exponential profile set by the Jerlov water type option WTYPE in ocean.in.

This step is handled by routine lmd_swfrac even if the KPP (LMD) mixing closure scheme is not being used, i.e. this can be used in conjunction with GLS mixing too.

So one can specify both net heat flux and separately specify the net shortwave solar heating. It makes sense if you think it through.

If you don't specify SOLAR_SOURCE then all the net heat flux will go in to the surface most cell of the model. If you do, then some of the shortwave escapes out the bottom of the top cell to the cell below (and so on) so the rate of SST heating is generally diminished.

You cannot provide sensible, latent, longwave and shortwave as inputs in the forcing netcdf file and expect ROMS to add those up for you - you do it yourself.

If your net solar shortwave is only a daily average you might consider using the DIURNAL_SRFLUX to impose the diurnal heating cycle with the equivalent daily average.

You can obtain net shortwave solar heating from either NCEP or ECMWF, or other sources. But ROMS shortwave must be NET shortwave, so from a WRF model (like NCEP NAM or NARR) you need to take the difference of downward shortwave at surface dswrfsfc and upward shortwave at surface uswrfsfc. I don't know how the WRF model determines the upward, i.e. what it assumes for ocean albedo. But you must subtract uswrfsfc from dswrfsfc or you will be overestimating the heating.

[mengqingjun]

Hi d.kobashi~

I tried SOLAR_SOURCE and QCORRECTION to adjust heat flux (satellite-based SST). High SST/sub-surface temperature still persists.

I am wondering how you gave the values of dQdSST to ROMS ?
I meet a similar problem like yours. Without BULK_FLUXS,ROMS need only sstr,svstr,shflux,swflux,swrad.But like yours,

Without surface heat flux, SST is underestimated and with the flux, SST is overestimated.

I am thinking is it the reason I didn't give the value of dQdSST ? Absolutly it is better to apply shflux to ROMS ,but is the shflux we get from the ERA-interim accurate ?
Thank you for some suggestions

[d.kobashi]

Hi John, Many thanks for your comment. Sorry for the late response. I've just come back from an oversea trip.
I have now a better understanding of heat flux on ROMS.

I did some test about surface heat flux and got the result which I attach as a figure.

Three cases were tested.
(1) No surface heat flux
(2) Surface heat flux without SOLAR_SOURCE and QCORRECTION
(3) Surface heat flux with SOLAR_SOURCE and QCORRECTION

Surface heat flux was obtained from ERA-interim (as the sum of net LW/SW rad flux, sensible and latent heat).
dQdSST was estimated based on climatology data and Barnier et al (1995).
Spatially varying Jwtype was included for the case (3).

Summary of the results is as follow.
(1) Simulated SST (second row in the figure) was closest to obs SST (red) when heat flux was NOT included (blue).
(2) Simulated SST without SOLAR_SOURCE and QCORRECTION (black) was overestimated.
(3) Simulated SST with SOLAR_SOURCE and QCORRECTION (green) was still overesimated by approximately 1.5 degC, but the degree of the overestimation reduced compared to the case (2). It also captured daily SST variability better than the test (1) (no heat flux case).
(4) Simulated bottom temperature (third row) performed the best when SOLAR_SOURCE and QCORRECTION were included.

This test needs more work, but the result reminds me of my original question.
What I am trying to do now is to change dQdSST a bit more aggressively and adjust SST. I am not sure if that is legitimate though... If this kludge works, I think that's what matters.


Thanks,

DJ Kobashi

[d.kobashi]

Hi mengqingjun

First, you can check the post I just submitted.

I am wondering how you gave the values of dQdSST to ROMS ?
I meet a similar problem like yours. Without BULK_FLUXS,ROMS need only sstr,svstr,shflux,swflux,swrad.But like yours,

I followed what Dr. Mark Hadfield did. Check the following post.
viewtopic.php?f=1&t=1308

Like he said, I also used COARDS climatological data and estimated dQdSST based on Barnier et al (1995). I thought ROMS tools developed by French scientists have a matlab script to calculate dQdSST.
I just averaged dQdSST spatially and temporarily. Mine was close to the Mark's estimated dQdSST value as two locations are geographically close.

Barnier, B., Siefridt, L., & Marchesiello, P. (1995). Thermal forcing for a global ocean circulation model using a three-year climatology of ECMWF analyses. Journal of Marine Systems, 6(4), 363–380. doi:10.1016/0924-7963(94)00034-9

is the shflux we get from the ERA-interim accurate ?

I initially used GFS/CFSR, but SW rad appeared to be high. Hernan suggested ERA interim (viewtopic.php?f=30&t=3003); therefore, I gave a shot. SW flux was indeed lower for ERA interim. It is difficult to say if surface heat flux from GFS or ERA interim is quite accurate or not (winds, MSLP etc were fine, though) as I don't have in-situ data to validate heat flux. Both capture daily variation, but an important thing is min/max value. That's a reason why I tried to nudge SST toward satellite-based SST to adjust heat flux.

Good luck

Thanks,

DJ Kobashi

[arango]

Recently, I was playing with the surface heat flux correction in the Gulf of Mexico (GOM). I even added an analytical functional ana_dqdsst.h in ROMS to set up the net heat flux sensitivity to SST, d(Q)/d(SST). However, I didn't have the stamina to code Barnier et al. (1995) equation. Notice that additional atmospheric fields are needed to compute this formula (see their equation 6b). If anybody is using this heat flux correction, you must read this nice paper first It shows the complete derivation and explains the physical rational and interpretation.

I was also having a warming in the summer with temperatures reaching 41C at the GOM surface. I used the monthly SST data from NOAA CoastWatch OpenDAP server, see product SST, Blended, Global, EXPERIMENTAL (BA/ssta/mday). I got SST monthly data from 2005-2012. I also used the ECMWF ERA products to force the model. I looked at that COADS climatology for d(Q)/d(SST) in the Gulf of Mexico and it is always negative and pretty much uniform. I used a constant value of d(Q)/d(SST)=-60 W/m2/Celsius. This worked very well for me and my warming trend disappeared

Notice that d(Q)/d(SST) can be positive or negative. It changes sign across the Gulf Stream, for instance. There is not need to use daily SST for this correction. Monthly SST work just fine and it is a better product than 3day, 8day, and 14day composites. The monthly SST is less biased. Of course, this is application dependent.

[mengqingjun]

If you #define SOLAR_SOURCE then the specified net shortwave radiation is propagated vertically into the water column and absorbed internally according to a double exponential profile set by the Jerlov water type option WTYPE in ocean.in.

This step is handled by routine lmd_swfrac even if the KPP (LMD) mixing closure scheme is not being used, i.e. this can be used in conjunction with GLS mixing too.

So one can specify both net heat flux and separately specify the net shortwave solar heating. It makes sense if you think it through.

If you don't specify SOLAR_SOURCE then all the net heat flux will go in to the surface most cell of the model. If you do, then some of the shortwave escapes out the bottom of the top cell to the cell below (and so on) so the rate of SST heating is generally diminished.

You cannot provide sensible, latent, longwave and shortwave as inputs in the forcing netcdf file and expect ROMS to add those up for you - you do it yourself.

If your net solar shortwave is only a daily average you might consider using the DIURNAL_SRFLUX to impose the diurnal heating cycle with the equivalent daily average.

You can obtain net shortwave solar heating from either NCEP or ECMWF, or other sources. But ROMS shortwave must be NET shortwave, so from a WRF model (like NCEP NAM or NARR) you need to take the difference of downward shortwave at surface dswrfsfc and upward shortwave at surface uswrfsfc. I don't know how the WRF model determines the upward, i.e. what it assumes for ocean albedo. But you must subtract uswrfsfc from dswrfsfc or you will be overestimating the heating.

I am using the Mellor-Yamada close shcemes, neither the KPP nor the GLS, the model can run even I didn't define SOLAR_SOURCE, is it OK? Do I need to define SOLAR_SOURCE ?Thank you for reply!

[wilkin]

I am using the Mellor-Yamada close shcemes, neither the KPP nor the GLS, the model can run even I didn't define SOLAR_SOURCE, is it OK? Do I need to define SOLAR_SOURCE ?Thank you for reply!

Yes, all my comments you quoted apply equally for the MY25_MIXING option.

Whether you NEED to #define SOLAR_SOURCE is up to you to decide as an oceanographer.

The key things are:

With SOLAR_SOURCE defined you must provide as inputs both the net shortwave radiation into the ocean AND the net heat flux. (Yes, the shortwave heating is already included in the net heat flux values, but the SOLAR_SOURCE option modifies how that portion of the heating enters the water column). With this option and prescribed net heat flux (i.e BULK_FLUXES not defined) the difference will simply be slightly less heating of the surface-most cell and slightly more direct heating below. The net does not alter.

Without SOLAR_SOURCE defined you can run the model giving only the net heat flux as input. All that heating goes into the surface-most cell of the model. If you have some very shallow water and therefore very thin surface cells, and not a lot of mixing, then you might get some unrealistically warm sea surface temperatures. But the net heating will still be as given in your forcing data.

If you use the BULK_FLUXES option you need to provide net shortwave. ROMS calculates the rest from the bulk formulae using the surface meteorology you provide. The net heat flux is not set independently.

[mengqingjun]

Ok,thank you wilkin for your replies! I am modeling the sea over shallow sea shelf.I didn't define BULK_FLUXS,I have very shallow water and therefore very thin surface cells.So I need to define SOLAR_SOURCE option as your advives, no matter whether I use MY25_MIXING nor other vertival mixing schemes. I will have a try and thank you again! Happy modeling!