Two-way Nesting

[hamidrezaomidvar]

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 #81 (comment)

[sunt05]

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:

WRF-SUEWS/coupling-automator/registry.suews

Lines 9 to 13 in 59ddb96

	#<Table> <Type> <Sym> <Dims> <Use> <NumTLev> <Stagger> <IO> <DNAME> <DESCRIP> <UNITS>
	state real LAI_SUEWS i{nvegsurf}j misc 1 - irh "LAI_SUEWS" "LAI_SUEWS" "m2 m-2"
	state real albDecTr_SUEWS ij misc 1 - irh "albDecTr_SUEWS" "albDecTr_SUEWS" ""
	state real albEveTr_SUEWS ij misc 1 - irh "albEveTr_SUEWS" "albEveTr_SUEWS" ""
	state real albGrass_SUEWS ij misc 1 - irh "albGrass_SUEWS" "albGrass_SUEWS" ""

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 .

[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

[sunt05]

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

[hamidrezaomidvar]

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

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]

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]

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

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

[hamidrezaomidvar]

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]

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

[hamidrezaomidvar]

I will check but I think it does.

[sunt05]

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]

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

[sunt05]

I was just looking at your changes to registry.suews:

WRF-SUEWS/coupling-automator/registry.suews

Lines 9 to 13 in 457fc5f

	#<Table> <Type> <Sym> <Dims> <Use> <NumTLev> <Stagger> <IO> <DNAME> <DESCRIP> <UNITS>
	state real LAI_SUEWS i{nvegsurf}j misc 1 - irhdu=(copy_fcnm) "LAI_SUEWS" "LAI_SUEWS" "m2 m-2"
	state real albDecTr_SUEWS ij misc 1 - irhdu=(copy_fcnm) "albDecTr_SUEWS" "albDecTr_SUEWS" ""
	state real albEveTr_SUEWS ij misc 1 - irhdu=(copy_fcnm) "albEveTr_SUEWS" "albEveTr_SUEWS" ""
	state real albGrass_SUEWS ij misc 1 - irhdu=(copy_fcnm) "albGrass_SUEWS" "albGrass_SUEWS" ""

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]

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]

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

[sunt05]

one more reference just for record: https://www.climatescience.org.au/sites/default/files/werner_nesting.pdf

and got reply here: wrf-model/WRF#1282 (comment)

[hamidrezaomidvar]

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]

excellent you have found it

[sunt05]

Given the code here:

WRF-SUEWS/coupling-automator/module_sf_suews.F

Line 496 in a26f136

diff_trans=(SWDOWN(I,J)/SWDNTC(I,J))-transdiff_SUEWS(I,J)

we might need to print out SWDOWN, SWDNTC and transdiff_SUEWS to see what's going on there.

[sunt05]

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

WRF-SUEWS/coupling-automator/module_sf_suews.F

Lines 496 to 501 in a26f136

	diff_trans=(SWDOWN(I,J)/SWDNTC(I,J))-transdiff_SUEWS(I,J)
	if(diff_trans.GE.0) then !make sure the difference is greater than zero (assuming that simulation overestimate kdown)
	SWDOWN1D=SWDNTC(I,J)*(diff_trans)
	ELSE
	SWDOWN1D = SWDOWN(i,j)
	end if

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]

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

[hamidrezaomidvar]

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]

excellent - which period is being tested?

[sunt05]

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

[hamidrezaomidvar]

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.