I have a few questions about the Hedstrom code, perhaps someone can help me. Apologies if I missed something obvious:
1) It seems that ice does not affect the skin heating (SRad). Why not?
2) It seems that the ice/snow albedo is used to correct the shortwave entering the ice, but not the shortwave entering the water (srflx) after passing through the ice. In my Hedstrom code from last year, srflx is only corrected for water albedo and ice attenuation, not the ice albedo. However I see that in the latest Hedstrom code on Github, it looks like srflx is only corrected for ice attenuation if ICE_BIO is defined, otherwise there is a new variable "SW_thru_ice" that is corrected for ice albedo and ice attenuation. But don't we need to correct srflx for (ice albedo + ice attenuation + water albedo) when using it in heat budgets and (if applicable) for biological models?
3) It seems that the cloudiness/sun angle corrected water albedo (cawdir) is only available if ALBEDO_CLOUD is activated. This seems a shame because I understand that such corrections can be the difference between 6% (low latitudes and/or cloudy sky) and up to 20% for a sunny day at low sun angle (Mobley and Boss, 2012). Maybe the direct/diffuse model used in cawdir_eval.F can account for that (I hope). The effect in ALBEDO_CURVE seems far too weak to account for non-cloudy days at high latitudes. But I don't necessarily want to resort to astronomical formula + empirical cloud correction to set the surface downwelling shortwave (ANA_SRFLUX + ALBEDO_CLOUD). For that I would prefer a reanalysis product, averaged over 1 day, with a diurnal cycle imposed (DIURNAL_SRFLUX). But in that case, I can't use cawdir because it requires ALBEDO_CLOUD. A dilemma.
Cheers
Phil
srflx in bulk_flux.F
Re: srflx in bulk_flux.F
A few years ago I did a big clean-up of the thermal ice code. Since I don't use bulk_flux.F (using ccsm_flux.F instead), it is possible that I missed a few things. I see that SRad is in bulk_flux.F and not the other.
ICE_BIO is a part of a biology package for which I have nowhere near the latest code. I should strip all that out, but there are people still working on those biology packages within ancient ROMS versions.
There are many albedo options for different cases. Feel free to add still more cases. The atmospheric fields I currently use do not include cloud fraction, so ALBEDO_CLOUD is not an option for me. I gather you have the same problem? The cawdir code came from Paul Budgell, but I don't know what atmospheric products he was using with it.
ICE_BIO is a part of a biology package for which I have nowhere near the latest code. I should strip all that out, but there are people still working on those biology packages within ancient ROMS versions.
There are many albedo options for different cases. Feel free to add still more cases. The atmospheric fields I currently use do not include cloud fraction, so ALBEDO_CLOUD is not an option for me. I gather you have the same problem? The cawdir code came from Paul Budgell, but I don't know what atmospheric products he was using with it.
Re: srflx in bulk_flux.F
Hi Kate
I checked ccsm_flux.F in your latest code and it seems that issues (2) and (3) still apply. (2) is the primary concern: srflx is apparently not corrected for ice/snow albedo (variable albedo_ice). The radiative heating of the ice (qswi) is corrected for albedo_ice, and therefore so are qi_o_n and SW_thru_ice, but it seems that nowhere in the code is srflx corrected for ice/snow albedo (I did grep -r on "srflx" and "albedo_ice"). Now I am wondering if this could explain why we are seeing far too much summertime ice loss in our simulations...
I also had another look at albedo.F and found one other concern: If ICE_ALB_EC92 is defined and ice thickness (thki_n) is at its capped minimum value of 0.00001, then line 236:
albi=0.082409_r8*LOG(thki_n)+0.485472_r8
would give a negative albedo (albi = -0.46). It seems this may result in negative albedo_ice values which are not further corrected (unless ALBEDO_HACK is defined).
Cheers
Phil
I checked ccsm_flux.F in your latest code and it seems that issues (2) and (3) still apply. (2) is the primary concern: srflx is apparently not corrected for ice/snow albedo (variable albedo_ice). The radiative heating of the ice (qswi) is corrected for albedo_ice, and therefore so are qi_o_n and SW_thru_ice, but it seems that nowhere in the code is srflx corrected for ice/snow albedo (I did grep -r on "srflx" and "albedo_ice"). Now I am wondering if this could explain why we are seeing far too much summertime ice loss in our simulations...
I also had another look at albedo.F and found one other concern: If ICE_ALB_EC92 is defined and ice thickness (thki_n) is at its capped minimum value of 0.00001, then line 236:
albi=0.082409_r8*LOG(thki_n)+0.485472_r8
would give a negative albedo (albi = -0.46). It seems this may result in negative albedo_ice values which are not further corrected (unless ALBEDO_HACK is defined).
Cheers
Phil
Re: srflx in bulk_flux.F
I believe this is done correctly where srflx gets a new value based on SW_thru_ice in ice_mk.h.pwallhead wrote:I checked ccsm_flux.F in your latest code and it seems that issues (2) and (3) still apply. (2) is the primary concern: srflx is apparently not corrected for ice/snow albedo (variable albedo_ice). The radiative heating of the ice (qswi) is corrected for albedo_ice, and therefore so are qi_o_n and SW_thru_ice, but it seems that nowhere in the code is srflx corrected for ice/snow albedo (I did grep -r on "srflx" and "albedo_ice"). Now I am wondering if this could explain why we are seeing far too much summertime ice loss in our simulations...
Thanks, this could be a problem! I should delete ALBEDO_HACK... that was just a temporary hack.I also had another look at albedo.F and found one other concern: If ICE_ALB_EC92 is defined and ice thickness (thki_n) is at its capped minimum value of 0.00001, then line 236:
albi=0.082409_r8*LOG(thki_n)+0.485472_r8
would give a negative albedo (albi = -0.46). It seems this may result in negative albedo_ice values which are not further corrected (unless ALBEDO_HACK is defined).
Cheers
Phil