Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

Energy conservation error downscaling longwave ERROR: replaced default GSWP3 forcing with ERA5 hourly data

Status
Not open for further replies.

yifanc17

Yifan Cheng
New Member
Hi all,

I'm trying to run CTSM (ctsm5.2.004) with customized ERA5 forcing and encountered several issues. Any suggestions would be appreciated!

I tested the ERA5 hourly data (bias corrected version) at 0.5x0.5° spatial resolution (Copernicus Climate Data Store | Copernicus Climate Data Store) with DATM_MODE set as GSWP3, and I got the error of Energy conservation error downscaling longwaveERROR and consequently urban net longwave radiation balance error. I checked the original forcing file, and longwave radiation doesn't have any abnormal values. The 0.5x0.5° mesh file (with land mask) I generated also looks normal (please see the figures attached).

I have attached the atm.log, cesm.log, datm.streams.xml used in this case for reference.

I have also tried to compile all the forcing variables into a single file and run CTSM under ERA5 DATM_MODE, and I got the error in NUOPC Invalid argument - Sa_q2m is not a StandardName in the NUOPC_FieldDictionary! However, there is no Sa_q2m in my datm.streams.xml. I have attached the PET0000.ESMF_LogFile as well.

Thanks,
Yifan
 

Attachments

  • atm.log.4613044.desched1.240527-104129.txt
    19.2 KB · Views: 1
  • datm.streams.txt
    5.8 KB · Views: 1
  • PET0000.ESMF_LogFile.txt
    1.5 KB · Views: 1
  • LWdown_2005_01.png
    LWdown_2005_01.png
    482.4 KB · Views: 2
  • mesh.png
    mesh.png
    130.4 KB · Views: 3

yifanc17

Yifan Cheng
New Member
*A minor correction, I labeled the lat and lon wrong in the mesh.png (there is nothing wrong with the mesh file itself). I also tried to make the coordinates of the forcing to be consistent with the mesh file (i.e., spanning from 0 to len(lons) or len(lats) instead of values of lats and lons) and it didn't work. The mesh file refers to the <meshfile> used in datm.streams.xml. I have attached the corrected mesh and LWdown below.
 

Attachments

  • mesh.png
    mesh.png
    130.4 KB · Views: 3
  • LWdown.png
    LWdown.png
    473.8 KB · Views: 3
Status
Not open for further replies.
Top