-
Notifications
You must be signed in to change notification settings - Fork 693
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
Wrong TSK output when nest starts #1947
Comments
Additional notes : -Air temperature and soil temperature are not impacted by this issue. -As for issue #1927, it is probably related to the call : -I can't say for sure which part of the start_domain can have an impact on TSK but the use of the variable "first_trip_for_this_domain" seems a bit dangerous in start_em.F Mathieu |
We will try to repeat this problem. |
Thank you. I performed few more tests with a shorter simulation and there are evidences that the problem is related to the radiation scheme and more precisely the GLW variable. Here is the namelist I used : For the following figures : TSK ( Skin temperature here in °C): T_C (1st mesh air temperature in °C) : SH_FLX (Sensible heat flux) : GLW (DOWNWARD LONG WAVE FLUX AT GROUND SURFACE) : Other variables : What I understand from that : A Possible solution then :
` Mathieu |
Nice work. SWDOWN may not show up because swint_opt will force a new value every time step. Without swint_opt it might have the same problem. I think your suggestion will work, so I suggest testing it to confirm. Having feedback = 0 reveals this problem. |
I confirm that the problem is the same without swint_opt. |
Is there an additional problem with SWDOWN without swint_opt? |
TSK could also be added to the list. |
Dudhia, |
We probably could but have not used time series output yet. Feedback also
needs to be off.
I am thinking start_domain is here just filling in parent values for when
there is no feedback.
…On Wed, Dec 13, 2023 at 9:51 AM mathieulandreau ***@***.***> wrote:
Dudhia,
I don't see any additional problem with SWDOWN.
Did you reproduce the bug ?
And what is the point of calling start_domain(parent) ?
—
Reply to this email directly, view it on GitHub
<#1947 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEIZ77ALTGGAWAKJL65RNHDYJHMKPAVCNFSM6AAAAABALHBGYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJUGMZTEMJSG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Dudhia, |
I think TSK, SWDOWN and GLW would be the main ones as inputs to some physics. These seem to need allocating and deallocating too like the others. |
Ok, I will try this tomorrow. |
Hi again, I tested every 2D variable and 1st level of every 3D variable from my wrfout file. Here is the result : Directly affected variables : albedo, canwat, emiss, hfx, glw, pblh, tke_pbl (from MYJ), u10e, ust, v10e Discussion : I might save all the directly affected variables. However, these are only the history variables. I can't say if some internal variables are also affected by the bug. Is it possible that my first guess is right (2nd message of this thread). Is it really necessary to call phy_init subroutine for the parent start_domain ? Here is the code I mentioned in start_em.F lines 230-239 : A first test is performed based on the timestep but then the timestep is reset to 0 IF ( grid%itimestep .EQ. 0 ) THEN
first_trip_for_this_domain = .TRUE.
ELSE
first_trip_for_this_domain = .FALSE.
END IF
IF ( .not. ( config_flags%restart .or. grid%moved ) ) THEN
grid%itimestep=0
ENDIF lines 316-321 : The same test is performed but since the timestep had earlier been reset to 0 it might be wrong ? IF ( grid%itimestep .EQ. 0 ) THEN
first_trip_for_this_domain = .TRUE.
ELSE
first_trip_for_this_domain = .FALSE.
END IF lines 898-900 : The call of phy_init depends on this second test. IF ( first_trip_for_this_domain ) THEN
CALL wrf_debug ( 100 , 'start_domain_em: Before call to phy_init' ) |
Did you try all those tests you listed? I am interested to know what happened, because it is possible we have some unnecessary initializations for this case of nests starting later and no feedback. |
For the moment I tested : 1- without swint_opt I didn't try to avoid the call of phy_init or to avoid the call of start_domain(parent) Mathieu |
I would suggest adding SWDOWN when swint_opt is not used as it has a similar role to GLW and will not get recomputed until the next radiation call. |
Oh yes I forgot SWDOWN and TSK in my 4th test description but I also saved them : save_glw = parent%glw !ML Issue #1947
save_hfx = parent%hfx !ML Issue #1947
save_qfx = parent%qfx !ML Issue #1947
save_tsk = parent%tsk !ML Issue #1947
save_swdown = parent%swdown !ML Issue #1947
save_albedo = parent%albedo !ML Issue #1947
save_canwat = parent%canwat !ML Issue #1947
save_emiss = parent%emiss !ML Issue #1947
save_pblh = parent%pblh !ML Issue #1947
save_tke_pbl = parent%tke_pbl !ML Issue #1947
save_u10e = parent%u10e !ML Issue #1947
save_ust = parent%ust !ML Issue #1947
save_v10e = parent%v10e !ML Issue #1947 Also tests 2, 3 and 4 are computed using swint_opt However, as I mentioned, I cannot know if some "not-in-history" variables are also affected. And the variables might depend on the physical schemes selected. |
Describe the bug
I ran a 5 nested domains simulation, each domain starting later than its parent. I notice that at time when d03 starts, d02 output an unrealistically low TSK value. Same with d03 when d04 starts and with d04 when d05 starts.
It seems to apply only on land.
I have, at first sight, no problem on d01 when d02 starts.
To Reproduce
Steps to reproduce the behavior:
Screenshots
I join a plot of the evolution of TSK over time at a random location in land (the bug doesn't apply on sea apparently) for each domain.
I also join a video of TSK in d02 on 17 May 2020 between 15h and 22h. d03 starts at 20h, we can clearly see a drop on land.
Attachments
namelist_12_07.txt
The text was updated successfully, but these errors were encountered: