search

Urban-Meteorology-Reading / WRF-SUEWS

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

Releasing necessary fixed variables from SuMin #32

Closed hamidrezaomidvar closed 5 years ago

hamidrezaomidvar commented 5 years ago

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 https://github.com/Urban-Meteorology-Reading/WRF-SUEWS/issues/31#issuecomment-482544946

hamidrezaomidvar commented 5 years ago

Here are the variables we need to release (to be completed):

sunt05 commented 5 years ago

Great! Then we need to decide if they go to namelist or wrfinput.

hamidrezaomidvar commented 5 years ago

I think namelist would be a better option because of the followings: 1- It would be specific to SUEWS 2- We don't have to manipulate wrfinput every time we produce new inputs, or decide to change a variable 3- I think it makes more sense to put the variables that are either time dependent or indicate more general methods (such as land surface model, radiation scheme etc.) in wrfinput. What are your thoughts?

sunt05 commented 5 years ago

I think the following should go to wrfinput as they are grid specific

The OHM-related ones are arguable as they may be invariant as we run WRF-SUEWS at the regional scale.

hamidrezaomidvar commented 5 years ago

For record: the process of releasing a variable: 1- Adding it to registry.suews 2- Changing changelist.json and mimicing similar variables 3- Editing module_sf_suews.F to pass the variable to SuMin 4- Editing suews_ctrl_sumin.f95 in SUEWS source code accordingly (editing SuMin submodule according to number 3) 5- Adding it to wrfinput using the python script

hamidrezaomidvar commented 5 years ago

Now all the variables are released to either namelist or wrfinput. Below is the list of released variables. In addition, I changed the way we add variables to wrfinput to be read from a json file. You can see it in the script and also SUEWS_variables.json. For some of them, we can later decided if we want put it back to SUEWS since they might not be very useful for users. @sunt05 Should we talk tomorrow to decide from where to start changing variables for better results?

Variables released in wrfinput (also can be seen in registry.suews):

LAI_SUEWS                 
albDecTr_SUEWS            
albEveTr_SUEWS            
albGrass_SUEWS            
NumCapita_SUEWS           
BaseT_SUEWS               
BaseTe_SUEWS              
GDDFull_SUEWS             
SDDFull_SUEWS             
LaiMin_SUEWS              
LaiMax_SUEWS              
MaxConductance_SUEWS      
FAIbldg_SUEWS             
FAIEveTree_SUEWS          
FAIDecTree_SUEWS          
bldgH_SUEWS               
EveTreeH_SUEWS            
DecTreeH_SUEWS            
AH_MIN_SUEWS              
AH_SLOPE_Cooling_SUEWS    
AH_SLOPE_Heating_SUEWS    
QF0_BEU_SUEWS             
Qf_A_SUEWS                
Qf_B_SUEWS                
Qf_C_SUEWS                
T_CRITIC_Cooling_SUEWS    
T_CRITIC_Heating_SUEWS    
TrafficRate_SUEWS         
surf_attr_MinStorCap_SUEWS
surf_attr_DrainEquat_SUEWS
surf_attr_DrainCoef1_SUEWS
surf_attr_DrainCoef2_SUEWS
surf_attr_MaxStorCap_SUEWS
SoilStoreCap_SUEWS        
SoilDepth_SUEWS           
SatHydraulicConduct_SUEWS 
AlbMin_DecTr_SUEWS        
AlbMax_DecTr_SUEWS        
AlbMin_EveTr_SUEWS        
AlbMax_EveTr_SUEWS        
AlbMin_Grass_SUEWS        
AlbMax_Grass_SUEWS        
CapMin_dec_SUEWS          
CapMax_dec_SUEWS          
PorMin_dec_SUEWS          
PorMax_dec_SUEWS          
DRAINRT_SUEWS             
RAINCOVER_SUEWS           
RAINMAXRES_SUEWS          
FlowChange_SUEWS          
PipeCapacity_SUEWS        
RunoffToWater_SUEWS       
StateLimit_SUEWS          
WetThresh_SUEWS           
BaseTHDD_SUEWS            
PopDensDaytime_SUEWS      
PopDensNighttime_SUEWS    
DecidCap_SUEWS            
porosity_SUEWS            
GDD_SUEWS                 
HDD_SUEWS                 
state_SUEWS               
soilmoist_SUEWS           
surf_var_SUEWS            
landusef_SUEWS            
alb_SUEWS                 
emis_SUEWS                
QN_SUEWS                  
AH_SUEWS                  
qn1_av_SUEWS              
qn1_s_SUEWS               
dqndt_SUEWS               
dqnsdt_SUEWS              
MeltWaterStore_SUEWS      
SnowAlb_SUEWS             
WUDay_SUEWS               
z0m_in_SUEWS              
zdm_in_SUEWS

variables that are released in namelist:

OHM_threshSW
OHM_threshWD
LAIType
LaiPower
th
tj
Kmax
g1
g2
g3
g4
g5
g6
s1
s2
sunt05 commented 5 years ago

@hamidrezaomidvar Good job! Yes, re: meeting.

Also, have a look at SuPy so we can easily extract proper values from existing SuPy/SUEWS runs. https://supy.readthedocs.io/en/latest/tutorial/quick-start.html

hamidrezaomidvar commented 5 years ago

Sounds good!

hamidrezaomidvar commented 5 years ago

@sunt05 : I was running a test case with similar variables we had run for London before (now for the released variables version). It seems that after 5 hours running, it stops and give the previous error that we had which is bad input for OHM/AnOHM storage heat flux calculation. Since I am using similar values as before, I suspect I have either givinen wrong variables from the json file or namelist. Would you please take a look at the new namelist.suews and SUEWS_variables.json file to see if there is any abnormal variable might cause the problem? you can look at the updated files in GitHub

sunt05 commented 5 years ago

OK, I will do this after we discuss the values and other related stuffs.

hamidrezaomidvar commented 5 years ago

@sunt05 : I was running a test case with similar variables we had run for London before (now for the released variables version). It seems that after 5 hours running, it stops and give the previous error that we had which is bad input for OHM/AnOHM storage heat flux calculation. Since I am using similar values as before, I suspect I have either givinen wrong variables from the json file or namelist. Would you please take a look at the new namelist.suews and SUEWS_variables.json file to see if there is any abnormal variable might cause the problem? you can look at the updated files in GitHub

Update: It turns out that the problem that I was getting here was because of the precision of the variables that I released in the namelist.suews. While WRF needs single precision, SUEWS uses double precision, so I needed to convert them at some point.

sunt05 commented 5 years ago

Good spot! But this is a bit surprising 😮

hamidrezaomidvar commented 5 years ago

Refere to here:


!NOTE: All the real type namelist variables are double precision, but only single precision
!      real variables have WORDSIZE in WRF, so if the following lines needed, we shoulde redefine
!      them in single precision and modify the interface in SUEWS1D.
       CALL wrf_dm_bcast_bytes (OHM_coef_s, 8 * 4 * 3  * RWORDSIZE)
       CALL wrf_dm_bcast_bytes (WaterDist_s, 8 * 6 * RWORDSIZE)
       CALL wrf_dm_bcast_bytes (AHProf_24hr, 24 * 2 * RWORDSIZE)
       CALL wrf_dm_bcast_bytes (HumActivity_24hr, 24 * 2 * RWORDSIZE)
       CALL wrf_dm_bcast_bytes (PopProf_24hr, 24 * 2 * RWORDSIZE)
       CALL wrf_dm_bcast_bytes (TraffProf_24hr, 24 * 2 * RWORDSIZE)
       CALL wrf_dm_bcast_bytes (WUProfA_24hr, 24 * 2 * RWORDSIZE)
       CALL wrf_dm_bcast_bytes (WUProfM_24hr, 24 * 2 * RWORDSIZE)
       CALL wrf_dm_bcast_bytes (snowUse, IWORDSIZE)
       CALL wrf_dm_bcast_bytes (RoughLenHeatMethod, IWORDSIZE)
       CALL wrf_dm_bcast_bytes (RoughLenMomMethod, IWORDSIZE)
       CALL wrf_dm_bcast_bytes (EmissionsMethod, IWORDSIZE)
       CALL wrf_dm_bcast_bytes (NetRadiationMethod, IWORDSIZE)
       CALL wrf_dm_bcast_bytes (StorageHeatMethod, IWORDSIZE)
       CALL wrf_dm_bcast_bytes (OHMIncQF, IWORDSIZE)
       CALL wrf_dm_bcast_bytes (AerodynamicResistanceMethod, IWORDSIZE)
       CALL wrf_dm_bcast_bytes (LAIType, 3 * 1 * IWORDSIZE)
       CALL wrf_dm_bcast_bytes (OHM_threshSW, 8 * 1 * RWORDSIZE)
       CALL wrf_dm_bcast_bytes (OHM_threshWD, 8 * 1 * RWORDSIZE)
       CALL wrf_dm_bcast_bytes (th, RWORDSIZE)
       CALL wrf_dm_bcast_bytes (tl, RWORDSIZE)
       CALL wrf_dm_bcast_bytes (Kmax, RWORDSIZE)
       CALL wrf_dm_bcast_bytes (g1, RWORDSIZE)
       CALL wrf_dm_bcast_bytes (g2, RWORDSIZE)
       CALL wrf_dm_bcast_bytes (g3, RWORDSIZE)
       CALL wrf_dm_bcast_bytes (g4, RWORDSIZE)
       CALL wrf_dm_bcast_bytes (g5, RWORDSIZE)
       CALL wrf_dm_bcast_bytes (g6, RWORDSIZE)
       CALL wrf_dm_bcast_bytes (s1, RWORDSIZE)
       CALL wrf_dm_bcast_bytes (s2, RWORDSIZE)
       CALL wrf_dm_bcast_bytes (LaiPower, 4 * 3 * RWORDSIZE)
       CALL wrf_dm_bcast_bytes (suews_cat_ind, 8 * 10 * IWORDSIZE)
       CALL wrf_dm_bcast_bytes (suews_cat_frac, 8 * 10 * RWORDSIZE)

    END IF
hamidrezaomidvar commented 5 years ago

I implemented this: we can now extract better values for SUEWS parameters from SuPy, and put it in namelist.suews, and wrfinput files. It is here

sunt05 commented 5 years ago

Good job! It would be good to change the code below: https://github.com/Urban-Meteorology-Reading/WRF-SUEWS/blob/97cf7c83b37196bdbae7baeb3d14a98354edc5fa/wrfinput-processor/param_extractor_SuPy/getting_SUEWS_params.py#L10-L11

We don't have to load df_state_init this way, as we can use sp.load_SampleData() to load the sample data shipped with SuPy; so we can have better consistency in the loaded data.

hamidrezaomidvar commented 5 years ago

Got it! I will fix it!