I’m looking at the sublimation snow/ice output variable from my JULES run. In some of my simulations, the sublimation is negative. Any idea what this means? The only explanation that I can come up with is that this output variable accounts for both sublimation and deposition and the negative value is indicative of deposition-dominated environment?
I’m using Version 6.0 of JULES. Suite ID: u-cu886.
How high are values? Nothing out of the ordinary (I don’t think) – see attached histogram: note, I’m only outputting monthly means, so I’m not sure what the hourly outputs look like. Also, units here are equivalent to kg m-2 d-1.
I remember that for some work I was doing with JULES, frost would form in some grid cells. Maybe frost is included in the sublimation output. For debugging, I ended up turning the frost process off, by hacking the FORTRAN code. I know that frost is normally included in the snowfall thickness, so you could look at that, too.
OK, any way I could get a definitive answer on this without me having to re-run my simulations? i.e. is there someone who would know? It’s quite important for the work I’m doing.
Given that sublimation might include deposition, does that mean that the snow melt output also includes freezing?
I will look through the FORTRAN code as soon as I can, to trace if frost deposition is included in the sublimation rate. I am pretty sure it is included, though. But I will try to confirm that as soon as possible.
Thanks Patrick - really appreciate this!
I guess if it is, the sublimation output variable will need to be renamed?
Could you also check if freezing is included in the snow melt output variable please?
Some more interesting findings that might also help/raise more questions!.. here I’ve attached a plot which shows a ~120 year simulation of snow mass changes at a single tile in my model.
The top plot shows the monthly snow mass balance derived from the raw snow_mass model output variable (blue) and the same calculated from by taking the snowfall and subtracting the sublimation and melt (snowfall, ei_gb and snow_melt output variables respectively) (orange).
They’re different. The bottom plot shows the cumulative effect which is actually quite substantial!
So am I missing something? It seems like in the latter I’m missing a positive term. I thought it might be refreezing, but I’ve got the snowliqcap set to zero, so there shouldn’t be any refreezing I don’t think.
Yes, definitely the
ei_surft variable for sublimation is negative when frost is forming. This assumes that
FALSE, which is the default.
The code below is from line 575 of
!------------------------------------------------------------------------- ! Add snowfall and frost as layer 0. !------------------------------------------------------------------------- sice0(i) = snowfall(i) IF ( .NOT. cansnowtile ) THEN sice0(i) = snowfall(i) - MIN(ei_surft(i), 0.0) * timestep END IF
So, if the sublimation variable
ei_surft < 0, and if
cansnowtile==FALSE, then frost accumulates.
Maybe you can create a ticket with the JULES developers to have the variable renamed or the documentation improved, if this is your wish?
I looked at:
and I don’t see any reason
melt_surft should be restricted to being positive. So,
melt_surft could be negative, and this would signify that the melt water from the snow is freezing again.
One question which would take more effort to answer is whether the magnitude of the frost accumulation in your run is realistic or not. I found in other non-trunk experimental JULES runs that frost was accumulating at unexpected times of the day or year. And sorting this out meant making sure that the driving data and the JULES settings were appropriate for the task at hand. And it also meant doing a lot of experimental runs with extra output variables, to make sure everything was making sense.
You sent the plots from an hour ago while I was writing my response from 26 minutes ago.
If the snow mass balance doesn’t close in your calculations, I would suggest that you look at the JULES FORTRAN source code to see if there are any extra terms that you’re not including.
Firstly, thanks for investigating the sublimation issue. Yep, I’ve definitely got frosting going on. Not an issue except that it means I can’t really assess how much sublimation is going on in the model as this will all be averaged out over a monthly period. But not to worry. At least I know the net affect of sublimation/deposition is small according to the model.
“One question which would take more effort to answer is whether the magnitude of the frost accumulation in your run is realistic or not” - agreed - difficult to constrain this without any comparison to field data that can provide some numbers on this I think.
“sf_melt_jls.F90: I don’t see any reason
melt_surft should be restricted to being positive. So,
melt_surft could be negative, and this would signify that the melt water from the snow is freezing again.”
Agree, although I hope refreezing isn’t included in melt_surft as this makes the output variables related to melt almost meaningless! I’ll explain why (and this is also following on from your suggestion to look at the FORTRAN CODE - specifically snowpack_mod.F90):
Note, I have cansnowtile and l_snow_infilt switched off, nsnow (number of snow layers) = 10 and snowliqcap (snow liquid water holding capacity) is zero.
Line 314: melt_surft (surface melt) is added to the snow surface as a heat flux, g_snow_surf.
Line 428: g_snow_surf is then added to the top layer of the snow.
So, assuming you’re right and melt_surft, can be positive or negative (i.e. it can include melt and refreezing), then the surface component of the snow_melt output at least is the net effect of melting and refreezing.
But! When we then go into the snow layers…
Lines 461-475 (melt): Here, melting only happens when the snow temp is greater than freezing point. Note here, that the sliq variable (liquid water content of snow layer) accumulates the snow melt per snow layer and sice (ice content of snow) accumulates the equivalent mass loss of solid water. So, no refreezing here so far…
Lines 501-553 (melt and refreezing): OK, starts to get interesting. If you follow this through, you’ll see that, initially, win (I guess this is short for “water into snowpack”) is set to zero (line 508), but eventually get’s set to the melt (sliq, line 536) So now, win=melt and then sliq=0 (line 537) because the water holding capacity of the snow is set to zero. This, then, effectively prevents any refreezing from happening over lines 540-550 because sliq=0.
Lines 563: melt_surft is then set to win (i.e. melt only). I guess this is what is used as the output variable for snow_melt?
Lines 481-498 (sublimation): Here, it’s accounting for sublimation only, as it only takes ei_surft if it’s positive (line 482).
Lines 578-583 (frosting): But here, as you point out, it also takes negative sublimation (frosting).
Line 592: Snow mass takes into account changes in sliq (which are zero as pointed out) and sice (which, as far as I can tell, only includes melt, sublimation and frosting).
Soooo, in summary:
- It seems the snow_melt output could potentially surface refreezing, but not refreezing in the snow layers.
- the snow_mass would includes any refreezing in the snow layers, but because I have snowliqcap=0, there isn’t any.
So going back to my original query, it doesn’t explain why the monthly snow mass balance derived from the raw snow_mass model output variable and the same calculated from by taking the snowfall and subtracting the sublimation and melt (snowfall, ei_gb and snow_melt output variables respectively) are different.
Any ideas? Do you agree with my interpretation of the code?
Some more investigation into the discrepancy between two methods for calculating the snow mass balance:
- Take the changes in the raw snow_mass model output variable
- Subtract the sublimation and melt from snowfall (ei_gb, snow_melt and snowfall output variables respectively).
Originally, I thought this was because I was missing a term/process (e.g. refreezing) from method 2, but then on looking at snow_model.F90, where it calculates the changes in snow_mass, I noticed that just above (line 743) it gives a warning on floating-point rounding errors on packs with high mass and small rates of change:
! Calculate surface mass balance diagnostics
! Large packs can have a high mass (kg) with small rates of change (/s)
! - beware floating-point precision rounding errors
I indeed have a very large snow pack (10000 m) because I’m using the snow pack to simulate glaciers.
So I did an experiment, calculating the snow mass balance using methods 1 and 2 for the snow pack set to 10000 and 100 m thick respectively. My hypothesis is that, assuming rounding errors are the issue, methods 1 and 2 should be closer together for the 100 m thick snow pack.
Attached are the resulting cumulative mass balance over a ~5 year period at a single tile in my JULES model.
So, for the 10000 m thick snow pack, see how Methods 1 and 2 (orange and blue lines) diverge quite a lot. For the 100 m thick snow pack, (green and red lines), the lines sit directly on top of each other. I’ve looked at the numbers and there are some very small differences, but negligible. So, my hypothesis appears to be correct.
Note also that, Method 2 for the 10000 m and 100 m thick snow pack returns simulations that are very close to each other. So it appears, method 2 is the best way to estimate snow pack mass balance as the internal method in JULES is subject to rounding errors.
That sounds great! I am glad you were able to sort out the snow mass balance!
Do you need help with anything else?
No thanks, all sorted now. Appreciate your help with this.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.