-
Notifications
You must be signed in to change notification settings - Fork 135
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
Atmospheric boundary layer loop convergence on ustar. #249
Comments
Is the Mahrt and Sun option applied instead of the Jordan option that tries to address the same issue? If so, then maybe the option should be generalized. If not and it's applied on top, well, maybe we should rethink that. |
It is applied on top of the Jordan et al. option and only in regions where the temperature difference between the surface and the lower atmosphere is above a particular threshold. |
Please assign me to this issue. I will be testing it in E3SM. |
Hi Dave, Please can you point us to some documentation on this change. Has it been written up in a paper as part of CESM V2? This change will affect other coupled models, and it needs to be consistent with their boundary layers, too, so will most likely need to be implemented as a CESM option. As Elizabeth points out, it needs to be consistent with what is already in the boundary layer for CICE, hence the need for me to read up on the change. I've looked at the Mahrt and Sun paper, but I'm not seeing consistency with the existing CICE boundary layer method, probably due to a lack of intelligence on my part. - Andrew |
As I said before, this is switchable via the namelist. It is not documented aside from the Mahrt and Sun paper. |
I see that use_coldair_outbreak_mod switches on one line or not, but that doesn't necessarily make it consistent with the rest of the boundary layer parameterization. Perhaps you are referring to a discussion with Elizabeth not on this issues page? |
I don't understand. We need it as a part of our CMIP runs. It is switchable and would be off in the default CICE model. So, no other groups have to use it. I am trying to keep our version up to date with the Consortium version. |
Andrew and I talked about this offline, briefly. We agree that it makes sense to incorporate it into our code base with an on/off flag, especially since CESM needs it. The option will need to be documented along with a description of what the new physics is and how it interacts with the existing physics in the boundary layer parameterization. That's the part that is not clear to Andrew and me. If we find it questionable, then my recommendation is to include an explicit statement in the documentation that there is a question about the physical consistency, in hopes that someone out in the community (or one of us) will address that issue in a scientific study or at least explain it in the docs. (That's how the Consortium is supposed to work, after all, and we have this kind of thing already, for the albedo.) |
I guess I was thinking that I had to demonstrate scientific results/publications with this modification before it was acceptable. I am certainly happy to add documentation. Not sure if and when anyone will ever do a paper on results with and without this. |
See #315. |
I agree that "flux convergence" is not quite right. Then main thing is to allow for reduced number of loop iterations for natmiter. The logic was implemented was to do nothing in the loop if ustar is converged. It doesn't explicitly exit the loop early. |
Title suggestion for this PR: atmo boundary layer loop convergence for ustar |
Merged in both Icepack and CICE: |
We have added some code based on Mahrt and Sun, 1995, MWR to increase the wind speed in very stable boundary layer regimes. This has a namelist flag, use_coldair_outbreak_mod and only affects icepack_atmo.F90 (atmo_boundary_layer).
We also have code that will stop the iteration when ustar is changing less than a specified convergence tolerance. This could potentially reduce the number of iterations in icepack_atmo.F90 (atmo_boundary_layer). This can be turned off and the fixed value of iterations is used.
We also have some code to only print the diagnostic message about high frequency RASM coupling once.
The text was updated successfully, but these errors were encountered: