urban-meteorology-reading / wrf-suews Goto Github PK

the code can be improved by enhancing modularity.

Not correct.
Then we should release this from being fixed.
Let's start another issue by listing those variables should have more "freedom".

Originally posted by @sunt05 in #31 (comment)

@sunt05 I just tried to run a very very simple case (just a simple homogeneous domain) for SCM of the coupled version, and it seems it is working! Although it is a very simple case, but it seems promising.

the current re-classification is fixed: we need a more flexible and adaptive one.

one solution is allow classification via namelist.

we need a documentation of namelist.suews.

todo:

• method
• coeff

done:

• landuse

These may be cross-referenced to the SUEWS documentation.

I am having a problem for initial compilation of WRF. I suspect that since we are using Intel compiler, but NetCDF uses PGI. Do you have any idea? Here is the error I get:

**The following indicate the compilers selected to build the WRF system
Serial Fortran compiler (mostly for tool generation):
which SFC
which: no pgf90 in (/apps/intel/2016.1/compilers_and_libraries/linux/mpi/intel64/bin:/apps/intel/2015.0.090/composer_xe_2015.0.090/bin/intel64:/apps/intel/2015.0.090/composer_xe_2015.0.090/debugger/gdb/intel64_mic/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/platform_mpi/bin:/apps/lsf/9.1/linux2.6-glibc2.3-x86_64/bin:/apps/lsf/9.1/linux2.6-glibc2.3-x86_64/etc:/home/users/homidvar/bin)
make: *** [configcheck] Error 1**

Note: this post is edit by TS to reorganise the issues

• Paper (WRF-SUEWS London/Swindon) --> in progress

• Licence --> transfer to SUEWS

• WRF-SUEWS for Reading? (simple Grass surface?) Maybe testing Reading with SUEWS offline by Shui (testing g1-6) --> transfer to Shui's MSc project

• Land cover fraction for Shanghai area

  • --> set up a Shanghai project
    --> new issue under Shanghai project

• Offline test of Shanghai (FX)- what kinds of crops? --> new issue under Shanghai project

• WRF-SUEWS London: comparing results with and without using landcover fraction (different time of the year)- To show we need a solution to get landcover fraction better (other places)

  --> Hamid'd proposal

• Pavement to building devision?? (maybe ask people in Sri Lanka) Tandem-X

  --> potentially related to the above one

• Write a paper about WRF-SUEWS Shanghai

  --> new issue under Shanghai project

The current land cover classification scheme is described here.

Please comment under this issue if any concerns.

@sunt05 I opened this issue to discuss about the problem we are having with new runs over London. I outputted the radiation components from SUEWS, and it is compiling now. I will run it , and will keep you posted here. If you get any new opinion what could be the source of problem (except Lup), please let me know

Great!
A sample bsub script bsub_run_wrf may look like the following:

#!/bin/bash 
#BSUB -q par-multi 
#BSUB -n 120
#BSUB -o %J.out 
#BSUB -e %J.err 
#BSUB -W 08:30

echo "Running WRF"
mpirun ./wrf.exe

then

bsub < bsub_run_wrf

Originally posted by @sunt05 in #23 (comment)

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

Originally posted by @hamidrezaomidvar in #29 (comment)

• what kinds of crops?

#46 (comment)

@hamidrezaomidvar,
I just got @zhenkunl safely landed on Jasmin 🎉
Can you give give him some orientation on how to use the compiled WRF-SUEWS and WPS to run his Shanghai case?
I know you have something for Shui, which might be useful for @zhenkunl as well.

Many thanks 🤝

@hamidrezaomidvar Have you modified the structure of namelist.suews in recent days? I meet the same problem as before when I run wrf.exe. I use the version you cloned for me.

ERROR reading sector coeff of namelist.suews

Originally posted by @zhenkunl in #37 (comment)

as the title. we need to decide. comment here and link references if any.

I think there are two major questions we need to answer: (1) Which direction SUEWS should move to: a full-function land surface model or a empirical/(or semi-empirical UCM model) ?

Then question (2) If the answer is the first one, what is the potential performance for SUEWS to simulate for different land covers (like bare soil, cropland, shrubs, forests), if the second one, what the benefits SUEWS has than other UCMs (currently we have Kusaka-Chen UCM, Martilli BEM and BEP, Oleson’s CLM-U and maybe in very near future the SSIB-urban) and how SUEWS should work with the specific LSMs

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?

add REGISTRY terms according to requirement of SuMin
design IO scheme for SuMin (namelist? SUEWS-compatible look-up tables?)
modify slab (or other scheme) to create a suitable container for SuMin

couldn't compile with system gcc.

I have run a 3-nested domain case for Shanghai. The domain configuration is as figure below.

@zhenkunl please finish the page here:
https://github.com/sunt05/WRF-SUEWS/wiki/message-passing-functions-in-WRF

Something that we have not fixed yet and I think it is essential to fix (or justify it) in this stage is the following:

• When changing wrfinputs for each specific area from the suitable parameters, we add SUEWS related parameters to all domains (1,2,3, or 4 in this case). For domains 3 and 4 there is no problem since we can modify them based on the specific city (London or Swindon). However, it is not clear what should we do for domain 1 and 2 and which parameters should be given to each grid in these domains.

• So far, for example for 3 domains run of London/Swindon, the same parameters as domain 3 would be added for domains 1 and 2, and for urban related parameters (e.g. population, building height etc..), the values are scaled based on the urban fraction.

• I know that it might not have lots of impacts on the final results as long as we put correct parameters in the smallest domain, and semi-correct ones in bigger ones, but how can we justify this is the best approach?

Originally posted by @hamidrezaomidvar in #37 (comment)

use SuPy as a prototype to construct the testing framework.

I am writing this issue to address a problem new users might encounter when running WRF on head nodes. If you see a Segmentation fault error after a short time of running wrf.exe, there is a possibility (not always) that there is an insufficient stack memory. A possible fix for this problem is ulimit -s unlimited command.

@hamidrezaomidvar
you can use this script for analysis:
https://github.com/Urban-Meteorology-Reading/WRF-SUEWS/blob/master/post-processor/WRF-SUEWS-ana.py

what land surface scheme should we use as container for SUEWS?
TS proposes the slab scheme.

#1

If I have high resolution land use categories data based on SUEWS (i.e. seven types), how can I put it into WRF-SUEWS without reclassification to the MODIS 21-category?

Originally posted by @zhenkunl in #45 (comment)

Great!
Now let's see the results of longer series.

And Let's open the abnormal first value Ldown as a separate issue to deal with later; but do plots excluding the first value of LW-related variables.

Originally posted by @sunt05 in #27 (comment)

Let's discuss here about what we want to focus on to show the ability of WRF-SUEWS in the paper.

I think we are able to now to have a run to compare various fluxes of the model and the data for London (and potentially for Swindon).
What else do we need to talk about in the paper?

Here are what should be done based on my last discussion with Ting to improve results of WRF-SUEWS as of here:

• Turn on Q_f in the runs. To do so, we need to correct the values of AHprofile in namelist.SUEWS.

• OHM coefficients need to be fixed, and more realistic coefficients need to be considered.

• We can impose better initial conditions for SUEWS by running it offline.

• We need to release some of the fixed parameters in SUEWS to put it in namelist.suews.

list the implemented and missing functionalities.
(I'll expand this gradually)

TODO:

• daylight saving scheme
• irrigation (partially done)
  ...

DONE:

• 7-class land cover classifier
  ...

currently, many coupling steps are done in a manual (and tedious and error-prone) way.

we should try to automate the procedures here when coupling SUEWS with WRFV4.

Shall we discuss SUWES-building integration here?

a wrapper-like subroutine of SUEWS

GRDFLX is not linked with SUEWS

determine the following variables on both sides:

• forcing variables
• initial conditions
• surface properties

related #1

what modules should be included in this SuMin 
OHM
LUMPS
QF/CO2
water balance?
advanced QE?
snow?

@sunt05 :
I am a bit confused about the variable we should use for the height of first grid point.
There is Z variable in surface_driver, which is explained [here](Which of the following elevation should we use for this:
https://www.openwfm.org/wiki/How_to_interpret_WRF_variables#Location)
z_at_w is not in surface driver, but it is just staggered version of Z where velocities are stored there. I tried to look at this variables (for the lowest grid), and they change with time, and also for different domains! a little bit confusing.
There is another variable which is dz8w which is dz of velocity grids which is seems is around 50m for our setup, and does not change between domains!

qn1_store_SUEWS and qn1_av_store_SUEWS need to be stored with values of previous periods.
This is not solved yet.

we should plan to support WRFV4 as it has been officially released.
maybe try to incorporate it as a submodule.

construct a suite of different testing cases:

1. simple case: can run fast to validate the code
2. medium case: to evaluate the physics

• different seasons.
• different background climate/cities.

#46 (comment)

I will list the methods that are available in WRF-SUEWS here. Later on we can transfer it to the Wiki page for later purposes.

For some of the parameters that are released on the grid level, we need to make sure that their value make sense for each specific grid. For example, Traffic rate cannot be same value for all the grids and should be valid for urban areas. Right now, same value goes to the wrfinputs and this leads to having a non-zero Qf everywhere in the domain. To fix this, I will implement a process that we will be able to mask urban areas and give suitable values for each grid level parameter

I am trying to use the high resolution data over London and population density data to run a case for London. This is to demonstrate the spatial variability of QF based on the population density variability. in the data, I can see that there are some parts of Central London with very high density such as 1400 per ha. Is this a normal value for that part?

multiple arithmetic issues have been noticed during online test and should be corrected at the SUEWS side.

Land cover fraction issue:
100 m resolution is too coarse that the vegetation are not captured on the site