Issue for calculation of qn, qf about wrf-suews HOT 35 CLOSED

The run for 4 domains were successfull for Colombo case. Here are some results of LH and HFX for the biggest and smallest domain (for two days):

from wrf-suews.

Also, I tried with sf_surface_physics=1, and it seems it runs fine.

from wrf-suews.

This is really a SUEWS thing.
It might be due to incorrect qf so the heat storage was not calculated correctly.
But I need to look into your configuration, where is it on JASMIN?

from wrf-suews.

/work/scratch/WRF-SUEWS-test/hamid/WPS

and

/work/scratch/WRF-SUEWS-test/hamid/WRF/test/em_real

Note that in this setting, I made the resolution of 3rd domain equal to 2nd domain to check if it is a resolution problem!

from wrf-suews.

There are several SUEWS specific input variables to put into wrfinput_dx (x is the domain number).
Have you done that? it looks some variables are missing when I check your wrfinput files.

from wrf-suews.

use this script to do so:
https://github.com/Urban-Meteorology-Reading/WRF-SUEWS/blob/master/mod-input-python/add-SUEWS-input.py

from wrf-suews.

I see! should this be done manually for the inputs always?
For the London runs (the ones that I, myself, generated the inputs via WPS, I did not add this variables). While I did not get any problem for those runs, I am suspecting it might affect the results. These variables are outputted in wrfoutput file though

from wrf-suews.

I see! should this be done manually for the inputs always?

Yes, always (practically for the time being as we didn't implement pre-processing procedures in WPS).

For the London runs (the ones that I, myself, generated the inputs via WPS, I did not add this variables). While I did not get any problem for those runs, I am suspecting it might affect the results. These variables are outputted in wrfoutput file though

It might have happened to pick up some physical values from the memory unintentionally.
Or, you happened to use the wrfinput files I gave you for London, which were manually initialised for SUEWS.

Anyway, make sure in the future to initialise it with physical values using that script.

from wrf-suews.

I changed them, but still same error. You can see it in the rsl.err.0000 in the same folder as above. I am wondering if initialization needs to be different for Colombo from London.

from wrf-suews.

I just noticed you had started another run with different errors appearing.
I'll be away for two hours then we can have a chat if this error persists.

from wrf-suews.

Yes, I am trying to run for the original resolution as London to start isolating the causing factors of this issue.

from wrf-suews.

@sunt05 : with the original domains and resolutions, it seems that it is running smoothly and with no problem.

from wrf-suews.

Good to know this.
Do we understand the reason for failure of WRF-SUEWS in Colombo?

from wrf-suews.

Not Yet. @suegrimmond suggested maybe we can add a 4th nest inside our original 3 domain of London in the case of Colombo to see how things will go. I first tried the fourth one with the factor of 3, which would give a dx=333.3333. this gave me an error of devision by zero at the beginning of the run. Then I tried the 4th nest with the factor of 2 which gives a dx=500. this is running well so far. So I am pretty sure that the errors we were getting before was the result of either bad nesting configuration or some incpompatibilies of SUEWS with high resolution domains. The 4 domains looks like this for Colombo (I will post some results here if the run goes well):

from wrf-suews.

Yes, a 4th domain is definitely necessary for such a small urban area like Colombo.
But let's keep an eye on the coupled system and see if anything we overlooked that may cause the system fail.

from wrf-suews.

Great!

A suggestion: for the plots, it would be good to fix the color bar scales across different frames.

Where is the working directory for these results?

from wrf-suews.

Do we now understand the reason for the qn/qf issue?

from wrf-suews.

Great!

A suggestion: for the plots, it would be good to fix the color bar scales across different frames.

Where is the working directory for these results?

It is the same as before. /work/scratch/WRF-SUEWS-test/hamid/WRF/test/em_real

Do we now understand the reason for the qn/qf issue?

Not yet. As I said, I suspect that before I had a nesting problem which would lead to the problem in calculating qn and qf. But not sure. Do you have any idea on this?

from wrf-suews.

Do we now understand the reason for the qn/qf issue?

Not yet. As I said, I suspect that before I had a nesting problem which would lead to the problem in calculating qn and qf. But not sure. Do you have any idea on this?

Do we still have hold of the configuration files that can reproduce the error?

from wrf-suews.

from wrf-suews.

Do we now understand the reason for the qn/qf issue?

Not yet. As I said, I suspect that before I had a nesting problem which would lead to the problem in calculating qn and qf. But not sure. Do you have any idea on this?

Do we still have hold of the configuration files that can reproduce the error?

I can reproduce them in new files and give you the directory address

from wrf-suews.

Great to see the new runs. Please can we have a look at Q* and QF maps as well

@suegrimmond I will work on these plots

from wrf-suews.

@sunt05 Q* and QF are the net radiation and moisture flux in the WRF outputs right?

from wrf-suews.

Do we now understand the reason for the qn/qf issue?

Not yet. As I said, I suspect that before I had a nesting problem which would lead to the problem in calculating qn and qf. But not sure. Do you have any idea on this?

Do we still have hold of the configuration files that can reproduce the error?

I can reproduce them in new files and give you the directory address

Let's have them in a separate directory and I'll have a look.

from wrf-suews.

@sunt05 Q* and QF are the net radiation and moisture flux in the WRF outputs right?

QN_SUEWS for Q* and AH_SUEWS for QF, anthropogenic heat.
I just checked these two: QF seems to be turned off or set with very low values in this run.

@hamidrezaomidvar would be good to get some plots of diurnal cycles of these variables.

from wrf-suews.

@sunt05 Q* and QF are the net radiation and moisture flux in the WRF outputs right?

QN_SUEWS for Q* and AH_SUEWS for QF, anthropogenic heat.
I just checked these two: QF seems to be turned off or set with very low values in this run.

Just checked: QF scheme was turned off so QF = 0 at all times.
There are other pieces to adjust in the namelist.suews.

But anyway, let's get assured first by resolving the issue causing system failure; the other settings are easy to play with.

from wrf-suews.

I see. Ok, I will let you know when I have the directory with the previous configuration. Here is the diurnal cycle for QN_SUEWS for a point in the urban section of Colombo. I think the time is in UTC so there is 5:30 hour shift between UTC and Colombo:

from wrf-suews.

@sunt05 here is the folder: you can see the error isn rsl.error.0001 files.
/work/scratch/WRF-SUEWS-test/debug_WRF_SUEWS/WRF/test/em_real
/work/scratch/WRF-SUEWS-test/debug_WRF_SUEWS/WPS

from wrf-suews.

@sunt05
It turns out that the problem is in the calculation of srf(is) at some point. Look at the output ins rsl.out.0003 at the end of file while srf values are super large. you can find the output files here:

https://www.dropbox.com/sh/5jomvq84awm3eps/AAALXSEqIihEVLNpCXbvDXnFa?dl=0

from wrf-suews.

from wrf-suews.

For record: apparently, for this configuration, WPS makes some abnormal value of LANDUSEF for two grids as you can see from the top figure.We need to check this in SUEWS to make sure correct value of LANDUSEF is feed to SUEWS for land categorization.

from wrf-suews.

I did a quick fix for this, and ran for some times. Here are some Qn_suews results for domain 1 and 3. Now we need to make SUEWS to check if WPS outputs are in correct format or not:

from wrf-suews.

Great! Let's move forward with the fixing.
May start it as a new issue related to land cover reclassification.

from wrf-suews.

Now the couple system should detect if LANDUSEF values from the WPS system are correct or not.

from wrf-suews.

Well done!

from wrf-suews.