VEGFRA is not given

[Sherly Shelton]

Dear All,

I am currently working with the model, but I encountered an issue where the variable VEGFRA (likely vegetation fraction) could not be accessed from the NetCDF files. Upon reviewing all the available .nc files, I was unable to locate this variable in any of them.

Could you please provide guidance on the following:

1. Is the VEGFRA variable expected to be generated during a specific preprocessing step?
2. Could the absence of VEGFRA indicate an issue with input data or a particular configuration setting?
3. Are there alternative approaches or scripts available to derive this variable if it was not generated automatically?

This is the error:

MODULE_NOAHLSM_HRLDAS_INPUT: get_2d_netcdf_ruc:nf90_inq_varid VEGFRA

 ---

 FATAL ERROR! Program stopped. Recompile with environment variable HYDRO_D set t

 o 1 for enhanced debug information.

[aubrey]

Hi Sherly:

Are you running with FORC_TYP 3 or 7? It looks like these options expect the veg fraction to be included alongside the other met forcing variables in the wrfout files. I assume this field is available in your WRF outputs? If you do not have this variable in your forcings, you can try post-processing your forcing data to match one of the other formats (e.g., FORC_TYP 2). If for some reason the variable name has changed in the WRF outputs, we can adjust the read routine, though I confess to not have used WRF output directly in a long while.

Veg fraction can also be provided in the wrfinput file if you want to rely on climatology or a static maximum value. Noah-MP supports a few options here, but for whatever reason the WRF file read routine is expecting this variable to be there.

Let us know how it goes.

Thanks!

Aubrey

[Sherly Shelton]

Dear Aubrey,

Thank you for your prompt response to my earlier query. 

I wanted to update you on my recent work using the CONUS404 dataset from USGS. I downloaded selected variables from the dataset, noting that the VEGFRA variable was not available.

To proceed, I used FORC_TYP 1 and renamed the files following the yymmddhh.LDASIN_DOMAIN1 format. Additionally, I adjusted the variable names to align with the model's requirements, such as renaming U10 to U2D and T2 to T2D.

After these preparations, I successfully ran the model, and the process was completed without any issues.

Please let me know if you have any comments or suggestions for improvement.

Best regards,

Sherly Shelton

[aubrey]

Hi Sherly:

That process sounds consistent with how we have been forcing WRF-Hydro with CONUS404. We use the WRF-Hydro forcing engine to regrid between the CONUS404 4-km grid and our WRF-Hydro domain, and it translates into the proper variable names.

We have a 10-year CONUS dataset here:

https://www.sciencebase.gov/catalog/item/661039a6d34e6334665050f4

And a 40-year CONUS dataset to be released this spring.

Thanks!

Aubrey