-
Notifications
You must be signed in to change notification settings - Fork 150
Fix Tsnice calculation #542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| if ((hslyr+hilyr) > puny) then | ||
| if (hslyr > puny) then | ||
| Tsnice = (hslyr*zTsn(nslyr) + hilyr*zTin(1)) / (hslyr+hilyr) | ||
| Tsnice = Tsnice + aicen*((hslyr*zTsn(nslyr) + hilyr*zTin(1)) / (hslyr+hilyr)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can I check that I understand? Does this aicen factor get "canceled" in ice_history in:
! Only average for timesteps when ice present
if (avail_hist_fields(n)%avg_ice_present) then
do j = jlo, jhi
do i = ilo, ihi
if (tmask(i,j,iblk)) then
a2D(i,j,n,iblk) = &
a2D(i,j,n,iblk)*avgct(ns)*ravgip(i,j)
endif
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is aggregating the category Tsnice into the grid cell Tsnice. The time averaging in ice_history.F90 will come in a CICE PR!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Then isn't a Tsnice = Tsnice/sum(aicen) factor missing? For example, for single category aicen almost puny
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry this is so confusing. I should really call this:
Tsnice = sum(aicen(n)*Tsnicen(n)) for n=1,5
this is done for every point in space within icepack. The history averaging in CICE is then:
sum(aice(t)*Tsnice(t)) / sum(aice(t)), for t over the averaging period. The CICE changes are coming in a future PR!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also confused :)
Tsnice = sum(aicen(n)*Tsnicen(n)) for n=1,5
sum(aicen(n)) is not 1, so Tsnice ends up weighted by aice here right ?
... The history averaging in CICE is then:
sum(aice(t)*Tsnice(t)) / sum(aice(t)), for t over the averaging period. The CICE changes are coming in a future PR!
Doesn't this mean its weighted by aice twice ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh - maybe this line would be correct now:
worka(i,j) = aice(i,j,iblk)*(Tsnice(i,j,iblk)/aice_init(i,j,iblk)+Tffresh)
the divide by aice_init corrects it for the aice weighting applied during thermo vertical
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is aggregating the category Tsnice into the grid cell Tsnice.
This is true only if Tsnice=0 for the open water area. Assuming that, then the grid cell average Tavg = sum(aicen(n)*Tsnice(n))/sum(aicen(n)) =sum(aicen(n)*Tsnice(n))/1 where the sums are for n=0,ncat mathematically but only need to be taken for n=1,ncat in the code. Confusing, yes, but possibly okay here. (Explicit code comments to this effect would be helpful.) A better assumption for Tsnice for open water might be the ocean temperature. On the other hand, if the data request is for Tsnice only over the ice-covered area, then it had better be
sum(aicen(n)*Tsnice(n))/sum(aicen(n)) for n=1,ncat, where aicen might actually be aicen_init at this point in the code.
I'm generally suspicious of any 'mixed' ice area scaling using both aice and aice_init. Those will need to be considered on a case-by-case basis, in my opinion.
|
Is this ready for review and merge? Are there any test results verifying bit-for-bit (except for the diagnostic)? |
I posted the test results in the comments above. |
where? |
I guess I forgot to save it earlier. Now in the first comment. |
| einter = einter + hilyr * zqin(k) | ||
| enddo ! k | ||
|
|
||
| Tsnice = c0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this Tsnice = c0 is in the wrong location.
thermo_vertical is called for once for each thickness category, which means Tsnice=0 gets reset every time and the result would be just the temperature for the ncat = 5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. Fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tsnice is now initialized in icedrv_flux.F90 and ice_flux.F90.
|
As part of these updates, it makes sense to me to do some manual checks of the updated diagnostic output. Maybe run the model for a day, write out a bunch of data either in history or via stdout, and verify that the new diagnostics are generating results consistent with the raw data. If we do that, these errors should get caught, and we'll have more confidence in the results as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs further review
|
@anton-seaice @eclare108213 @NickSzapiro-NOAA Have I addressed all of your concerns here? I know Nick is not able to look at this right now. |
|
Thanks @dabail10 ! fyi, EMC contract and federal staff are still working. Great to hear! I have a friend, Todd Arbetter who is a contractor working on UFS now. More in the hurricane group. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've looked at this code (the PRs in both Icepack and CICE) fairly closely and I think it is okay. I'll approve both.
Generally speaking, the history code is VERY confusing because the averaging calculations are spread between Icepack and CICE and also among CICE history subroutines. I'm not 100% convinced that it's outputting what we think it is for every field (not just those in this PR).
Some additional comment statements to explain what's happening when would be helpful. E.g. I think this comment
! Only average for timesteps when ice present
ought to be
! Only average when/where ice is present
because the multiplication by ravgip divides by both time and area, whereas avgct is only for time (and ravgip is not defined in the declaration comments!).
I'll suggest some unit tests in a new issue, which should impart a bit more confidence in general.
|
Should we merge this? Or do we want to wait for the CICE PR to be ready too? |
|
I have one more question for the others. To get the snow-ice interface temperature I am doing a thickness weighted average: So, this assumes a straight line from the bottom snow level to the top ice level. However, I am values above 0C in my history variable. I tried using both aice_init and aice in the averaging, but this did not help. I don't think my weighted average could be generating values above 0C, but I wonder if I should use ksno and kice here? Or is it possible that the mushy physics is generating temperatures above 0C? Dave |
|
So, for example, say zTsn=-10C and zTin = -1C and hslyr=0.1 and hilyr=0.25. Then this formula is: Whereas a conductivity based thing would be something like this? ksno * (zTsn - Tsnice) / hslyr = kice * (Tsnice - zTin) / hilyr In case you were curious, with the numbers above this comes out around -3.5C. |
|
Also, I did a search again in case there was already an interface temperature. There is iTin in the icepack_brine.F90 module, but I couldn't find one otherwise. |
|
@dabail10 I don't think your thickness-weighted temperature formula gives you the temperature at the interface. That is probably the average temperature over the two layers, which isn't the same thing as the interface temperature. Setting up a grid with temperature on the y axis and distance on the x axis (i.e. the snow-ice column lying sideways), I get the interface temperature as -7.42857C in your example above with -10C, 0.1 m snow and -1C, 0.25 m ice layers. |
|
I agree. I had naively assumed it was a weighted average of the two layers. Instead maybe the straight line fit of: T = (Tice - Tsno) / 0.5 *(hslyr + hilyr) * x + Tsno So, when x = 0, T = Tsno. when x = 0.5*(hslyr+hilyr), T=Tice. With this in mind, x = 0.5*hslyr is the snow-ice interface and T = (Tice-Tsno)*hslyr / (hilyr+hslyr) + Tsno. Using Tsno = -10 and Tice = -1, hslyr=0.1, hilyr=0.25, this gives -7.429 as you found. |
reduces to
Same number of flops but the interpolant is a little easier to recognize. |
Which is funny, because I was wondering if I was doing the weighted average correctly. This expression weights the snow temperature with hilyr, whereas my version was weighting it with hslyr. |
|
Ok. Fixed the computation of Tsnice here. This should be ready to go. |
|
Should I merge, do we need to wait for the CICE PR to also be ready? If we merge this, can we pull this into CICE even if the corresponding CICE PR isn't ready? |
|
I guess strictly speaking this does not change the icepack_step_therm1 interface and should still work with CICE main. |



For detailed information about submitting Pull Requests (PRs) to the CICE-Consortium,
please refer to: https://github.com/CICE-Consortium/About-Us/wiki/Resource-Index#information-for-developers
PR checklist
Bug fix for Tsnice computation. Addresses part of CICE Issue aice vs. aice/aice_init factor in ice_history CICE#1033. More coming in CICE PR.
dabail10 (D. Bailey)
https://github.com/CICE-Consortium/Test-Results/wiki/icepack_by_hash_forks#e9d626f0e5b743e143a2e87248a1aa22ee4f3751
This should be a bfb change for the model. This will change the output of the CICE history variable f_sitempsnic.