Closed hamidrezaomidvar closed 4 years ago
After reflection on the way two-way nesting is passing in and out variables and looking into the registry, I may get the reason for failure of SUEWS in this mode: https://github.com/Urban-Meteorology-Reading/WRF-SUEWS/blob/59ddb96946e1f68fd8c7c733e607fd7b4372cf4b/coupling-automator/registry.suews#L9-L13
As shown above, the IO
section doesn't involve anything related to nesting as instructed here:
ref: https://www.climatescience.org.au/sites/default/files/WRF_gill_registry.pdf
So I think we can similarly add u
and d
to the IO
section of these SUEWS variables.
Let's try this out when you are back from holiday @hamidrezaomidvar .
I will do a test adding u
and d
, and see how it works. I am also searching about copy_fcnm
option that we see in noah
based on out talk although it seems there is no definition yet
if you do a global search in the WRF repo, copy_fcnm
seems to be subroutine name (similarly, there are other subroutine names).
@sunt05 I see. Thanks for the info. quick question. When we change the registry.suews
, we have to generate wrfinput
from the beginning to be consistent with the new registry right?
I don't think the wrfinput.nc
will be affected: based on my understanding of mechanism of registry, the actual code used for compiling WRF-SUEWS will be changed.
So, we don't have to regenerate wrfinput.nc
again.
But, bear with me if anything would blow up 😢
Makes sense. I am compiling the new version and first I will do a test with old wrfinput.nc
to see if it is consistent. I will let you know how it goes.
@sunt05 I did a test with new registry (rhud
, without other options) and using the old wrfinput. It seems that the issue still persist and the run stops after some time (similar time as before). I am going to do two more tests: 1 using new wrfinputs and one adding the options to rhud
as NOAH to see if we will have same problems
Sorry to learn that: OK, let's see if the magic can happen!
I did the other two tests and they failed with the same situation. So it seems that the problem is something that we still don't know or have ignored!
It's a bit frustrating. Would the modified version still be running in one-way mode?
I will check but I think it does.
Hopefully this won't cause any regression in the functionality. Please push your progress today and I'll have a look at your changes later.
Ok I will do it now. Let's have a quick chat tomorrow morning and discuss how to proceed!
I was just looking at your changes to registry.suews
:
https://github.com/Urban-Meteorology-Reading/WRF-SUEWS/blob/457fc5ff8ff8b33db1be26e18854f3785a4b4bfa/coupling-automator/registry.suews#L9-L13
and comparing them to settings in https://github.com/wrf-model/WRF/blob/f311cd5e136631ebf3ebaa02b4b7be3816ed171f/Registry/Registry.EM_COMMON#L844-L850, it seems the d
section is not filled up.
I don't if it's the cause; but we can explore this more tomorrow.
also looked at setting in the CLM file, where most variables use this:
d=(interp_mask_field:lu_index,iswater)u=(copy_fcnm)
Given the similarity in model structure between CLM and SUEWS, I think we may want to use this for SUEWS registry.
I see! Thanks for noticing this. Let me do a test with this option and see if it works.
one more reference just for record: https://www.climatescience.org.au/sites/default/files/werner_nesting.pdf
and got reply here: https://github.com/wrf-model/WRF/issues/1282#issuecomment-689091204
For record: after multiple tests, we found out the problem we are getting here. It is related to the part of SUEWS1D
code where the transmissivity is corrected. commenting out this part will make the run pass the previous crashing point, but a full run is needed to make sure. Will follow up how to fix the problem in this part of the code. @sunt05 please let me know if you get any clue about the potential problem of the code (first direction can be about SWDNT
)
excellent you have found it
Given the code here: https://github.com/Urban-Meteorology-Reading/WRF-SUEWS/blob/a26f13646c9610dfef3b41f75eded4ceccad6e9e/coupling-automator/module_sf_suews.F#L496
we might need to print out SWDOWN
, SWDNTC
and transdiff_SUEWS
to see what's going on there.
Based on @hamidrezaomidvar's finding, it seems SWDNTC
somehow becomes 0 when it's fedback to a parent domain.
Following my comment above, I checked the ud
properties of SWDOWN
, SWDNTC
and transdiff_SUEWS
in registry: all should be passed across child/parent domains using the default interpolation/merge functions.
So we need to make sure which term among the three is causing the NAN
issue.
@sunt05 SWDOWN
and SWDNTC
are coming to suewsdrv
from WRF. Maybe we need to check what are their options in other registries?
The issue was because of SWDNTC
when it is zero. This is fixed now, and a 4 domains run is under going. I will close this issue for now.
excellent - which period is being tested?
tested with the January case. Now running all four cases as done in the one-way nesting mode.
Yes, that is the plan. I have submitted jobs but Jasmin has been recently very slow in letting the jobs to go to run state.
It seems that enabling Two-way nesting for WRF-SUEWS needs a detail investigation of how the domain variables are interpolated to their parents and what are the variables from SUEWS needs to be added to this interpolation.
feedback =1
is where this happens but the subroutine under this method seem complicated to me. I will try to find some documentation for this part, but at the moment, we can make it as TODO in WRF-SUEWS to fix it.Originally posted by @hamidrezaomidvar in https://github.com/Urban-Meteorology-Reading/WRF-SUEWS/issues/81#issuecomment-682721894