Urban-Meteorology-Reading / WRF-SUEWS

WRF-SUEWS coupling project
https://wrf-suews.readthedocs.org
MIT License
5 stars 2 forks source link

Two-way Nesting #82

Closed hamidrezaomidvar closed 4 years ago

hamidrezaomidvar commented 4 years ago

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

sunt05 commented 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: image

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 .

hamidrezaomidvar commented 4 years ago

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

sunt05 commented 4 years ago

if you do a global search in the WRF repo, copy_fcnm seems to be subroutine name (similarly, there are other subroutine names).

hamidrezaomidvar commented 4 years ago

@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?

sunt05 commented 4 years ago

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 😢

hamidrezaomidvar commented 4 years ago

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.

hamidrezaomidvar commented 4 years ago

@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

sunt05 commented 4 years ago

Sorry to learn that: OK, let's see if the magic can happen!

hamidrezaomidvar commented 4 years ago

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!

sunt05 commented 4 years ago

It's a bit frustrating. Would the modified version still be running in one-way mode?

hamidrezaomidvar commented 4 years ago

I will check but I think it does.

sunt05 commented 4 years ago

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.

hamidrezaomidvar commented 4 years ago

Ok I will do it now. Let's have a quick chat tomorrow morning and discuss how to proceed!

sunt05 commented 4 years ago

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.

sunt05 commented 4 years ago

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.

hamidrezaomidvar commented 4 years ago

I see! Thanks for noticing this. Let me do a test with this option and see if it works.

sunt05 commented 4 years ago

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

hamidrezaomidvar commented 4 years ago

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)

suegrimmond commented 4 years ago

excellent you have found it

sunt05 commented 4 years ago

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.

sunt05 commented 4 years ago

Based on @hamidrezaomidvar's finding, it seems SWDNTC somehow becomes 0 when it's fedback to a parent domain.

https://github.com/Urban-Meteorology-Reading/WRF-SUEWS/blob/a26f13646c9610dfef3b41f75eded4ceccad6e9e/coupling-automator/module_sf_suews.F#L496-L501

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.

hamidrezaomidvar commented 4 years ago

@sunt05 SWDOWN and SWDNTC are coming to suewsdrv from WRF. Maybe we need to check what are their options in other registries?

hamidrezaomidvar commented 4 years ago

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.

suegrimmond commented 4 years ago

excellent - which period is being tested?

sunt05 commented 4 years ago

tested with the January case. Now running all four cases as done in the one-way nesting mode.

hamidrezaomidvar commented 4 years ago

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.