Issue for calculation of qn, qf

[hamidrezaomidvar]

In order to get more familiar with WPS and the process, I am trying to run a case for Colombo, Sri Lanka. I changed all the variables accordingly, and was able to start the WRF run for this case (I reduced the resolution as well). However, It seems I am encountering a problem related to calculation of qn and qf for 3rd domain, which I suspect it is related to high resolution fact.

fatal error in SUEWS:Bad input for OHM/AnOHM storage heat flux calculation. Check qn, qn_Sn, qf for issues

@sunt05 can you please tell me more about these variables?

[hamidrezaomidvar]

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

[sunt05]

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?

[hamidrezaomidvar]

/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!

[sunt05]

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.

[sunt05]

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

[hamidrezaomidvar]

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

[sunt05]

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.

[hamidrezaomidvar]

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.

[sunt05]

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.

[hamidrezaomidvar]

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

[hamidrezaomidvar]

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

[sunt05]

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

[hamidrezaomidvar]

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):

[sunt05]

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.

[hamidrezaomidvar]

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):

[sunt05]

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?

[sunt05]

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

[hamidrezaomidvar]

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?

[sunt05]

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?

[suegrimmond]

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

Prof Sue Grimmond Dept. of Meteorology, University of Reading, Reading, RG6 6BB T: 44 118 378 6248 – messages get emailed to me O:Met Building (#58 on map) rm:1U14 E: c.s.grimmond@reading.ac.ukmailto:c.s.grimmond@reading.ac.uk W: http://micromet.reading.ac.uk/

From: Hamidreza Omidvar notifications@github.com Sent: 29 March 2019 11:31 To: Urban-Meteorology-Reading/WRF-SUEWS WRF-SUEWS@noreply.github.com Cc: Sue Grimmond c.s.grimmond@reading.ac.uk; Mention mention@noreply.github.com Subject: Re: [Urban-Meteorology-Reading/WRF-SUEWS] Issue for calculation of qn, qf (#29)

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?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Urban-Meteorology-Reading/WRF-SUEWS/issues/29#issuecomment-477965525, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATSs3ky3_Put25mNKyjbl9vDUCGBUDH1ks5vbflxgaJpZM4cOBLI.

[hamidrezaomidvar]

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

[hamidrezaomidvar]

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

[hamidrezaomidvar]

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

[sunt05]

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.

[sunt05]

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

[sunt05]

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

[hamidrezaomidvar]

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:

[hamidrezaomidvar]

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

[hamidrezaomidvar]

@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

[hamidrezaomidvar]

[hamidrezaomidvar]

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.

[hamidrezaomidvar]

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:

[sunt05]

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

[hamidrezaomidvar]

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

[sunt05]

Well done!