-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to "borrow" (unused) NUDAPT variables in SLUCM for other purposes? #6
Comments
The interesting exploration by @DanLi-BU does reminds me of the coupling work we did a while ago for WRF-SUEWS.
And it's right - the custom variables in So we will need to tweak the related part in |
This is the modified wrfinput_d04. I changed |
This comment was marked as resolved.
This comment was marked as resolved.
Please upload all input files so I can run this case at my side. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This is the code I used to modify the wrfinputs |
Now we've resolved an issue with the 🔍 Initial Search & Dead Ends
💡 Breakthrough with Compilation Files
🛠️ Debugging Steps Taken Implemented some debug lines using the existing code structure: WRITE ( message , FMT = '("processing wrfinput file (stream 0) for domain ",I8)' ) grid%id
CALL wrf_debug ( 100 , message ) Remember to adjust the Added checks right after reading the NetCDF file revealed unexpected all-zero values for 🕵️♂️ Comparing Variables ✅ Solution Identified |
Below is the core part of the zipped Click to expand!This is the content that will be hidden until the section is expanded. You can include text, images, code, etc. import xarray as xr
import pandas as pd
import matplotlib.pyplot as plt
import numpy as np
# List of file names to modify
file_names = ['d01', 'd02', 'd03', 'd04']
# Base path for the files
base_path = "wrfinput_"
# Iterate over each file, modify, and save
for file_name in file_names:
# Open the dataset
ds_path = base_path + file_name
ds = xr.open_dataset(ds_path)
# Your existing code for modifying stdh_urb2d and hgt_urb2d
stdh_urb2d = ds['STDH_URB2D']
hgt_urb2d = ds['MH_URB2D']
frc_urb2d = ds['FRC_URB2D']
lu_index = ds['LU_INDEX']
# Define the condition for LU_INDEX
lu_condition = lu_index.isin([23, 24, 25, 26])
# Update values based on the conditions
stdh_urb2d1 = xr.where((frc_urb2d > 0) & lu_condition, -4.5, stdh_urb2d)
hgt_urb2d = xr.where((frc_urb2d > 0) & lu_condition, 15, hgt_urb2d)
# Assign the modified variables back to the dataset
ds['STDH_URB2D'] = stdh_urb2d1
ds['MH_URB2D'] = hgt_urb2d
# Save the modified dataset to a new file
modified_ds_path = base_path + file_name + "_mod.nc"
ds.to_netcdf(modified_ds_path)
print(f"Saved modified dataset to {modified_ds_path}") Updated version: Click to expand!# List of file names to modify
file_names = ["d01", "d02", "d03", "d04"]
# Base path for the files
base_path = "wrfinput_"
# Iterate over each file, modify, and save
for file_name in file_names:
# Open the dataset
ds_path = base_path + file_name
ds = xr.open_dataset(ds_path)
# Auxiliary variables
frc_urb2d = ds["FRC_URB2D"]
lu_index = ds["LU_INDEX"]
# Define the dictionary of variables with their new values
dict_var_mod = {
"STDH_URB2D": -4.5,
"MH_URB2D": 15,
}
# Define the condition for LU_INDEX
lu_condition = lu_index.isin([23, 24, 25, 26])
# Update values based on the conditions
for var, val in dict_var_mod.items():
ds[var] = ds[var].where((frc_urb2d > 0) & lu_condition, val)
# Save the modified dataset to a new file
modified_ds_path = base_path + file_name + "_mod.nc"
ds.to_netcdf(modified_ds_path)
print(f"Saved modified dataset to {modified_ds_path}") |
The following is drafted by @DanLi-BU with light edits by @sunt05
OK, now at least I think I can elaborate my questions clearly. Here they are:
wrfinput_d04
(attached), there is a variable calledBUILD_HEIGHT
, which corresponds toHGT_URB2D
in the WRF code according to this line inRegistry.EM_COMMON
:WRF/Registry/Registry.EM_COMMON
Line 813 in 3dd1546
HGT_URB2D
/BUILD_HEIGHT
is one of the key variables in NUDAPT. IfHGT_URB2D
is larger than 0, it will trigger using NUDAPT, see https://ral.ucar.edu/sites/default/files/public/product-tool/NUDAPT_44_Documentation.pdfThis is also corroborated by looking at the function
urban_var_init
inmodule_sf_urban.F
Here is the question. If I manually modified
BUILD_HEIGHT
inwrfinput_d04
, say make it 10 m everywhere, and save it asBUILD_HEIGHT
inwrfinput_d04
. This has NO effect on my WRF results. Well, now that I think about it more, I start to understand why, because WRF actually never has a variable calledBUILD_HEIGHT
(or never reads in a variable calledBUILD_HEIGHT
fromwrfinput_d0x
). The variable name in the code isHGT_URB2D
, even thoughBUILD_HEIGHT
is the variable name inwrfinput_d04
.Similarly (but also not exactly), there is a variable called
STDH_URB2D
inwrfinput_d04
(again see attached), which is also called STDH_URB2D in the WRF code.WRF/Registry/Registry.EM_COMMON
Line 815 in 3dd1546
But when I modified it, there was again no effect on the WRF outputs.
STDH_URB2D
in all.F
files and here is what I got:My understanding is that
STDH_URB2D
is created after run real.exe (the line of code highlighted earlier, also see here, but there was never a place where the WRF model "reads in" the variableSTDH_URB2D
fromwrfinput_d04
. So it makes sense that modifying it does not affect the simulation results.But then when there is indeed valid NUDAPT data (as we did in previous weeks), how does
real.exe
"pass"STDH_URB2D
, as well asHGT_URB2D
, to wrf.exe throughwrfinput_d0x
? Does this have anything to do with thisgrid%
? Interesting...The text was updated successfully, but these errors were encountered: