Longwave down is zero or negative error: replaced default GSWP3 forcing with WRF forcing at hourly scale

[xiulingao]

Hi there,

I'm running a regional case with masked area and customized forcing data. The forcing data is downscaled to 9km spatial resolution and at hourly temporal resolution. I processed the forcing data given the instruction for how to prepare your own forcing data for CLM1PT mode (so time stamp is at the middle of each 1 hour window, all variables in one YYYY-MM.nc file). I ran CTSM (only the land component as I'm a FATES user) under GSWP3 datam mode with NUOPC driver. I did not change anything in datm.streams file except point to the customized forcing files (however, still did 3 separate stream files even all variables in one file) and changed mapalgo and meshfile to "none".

The first 5 years simulation went well, but model failed right after the first resubmit (STOP_N = 5, RESUBMIT=7, so failed at the very beginning of the resubmit) with the error message indicating it's the longeave down from atmosphere model is 0 or negative. I then checked the forcing data for the year where it failed by doing a one-year simulation with the forcing data for that specific year, and I did not get any complain about longwave radiation being negative or zero, so assume it is not a bad-data issue.

I searched through some old threads, my suspicion is that it might either 1) have something to do with the resubmit or 2) the temporal resolution of the data does not match the setup for GSWP3 data, which is at 3-hour resolution, and all these settings include tintalgo, dtlimit etc. are specific for GSWP3.

I attached my datm.stream file for your information.

Any suggestions are appreciated!

Thank you so much,

Xiulin

 

[xiulingao]

just an update on this: I tried to restart from a differnt year for the resubmit run and it failed with the same error right away, so can confirm that this is a restart issue. Is anyone familiar with tihis? Thanks!

 

[erik]

Hmmm. I looked at your streams and a couple of your files and FLDS seems to be positive. So it's not clear what's wrong here.

The restart files don't matter for DATM, it can reconstruct everything without them. So I'd suggest removing the DATM restart files and try running again.

 

[xiulingao]

Thanks Erik! I did try that and still getting the same error :(

 

[yifanc17]

Hi Xiulin, did you fix this issue? I encountered the same error when trying to replace default GSWP3 forcing with ERA5 hourly data, and there is no zero/negative values in the original forcing data while the regridding method is set to be 'bilinear', so I'm not sure where the 'Longwave down sent from the atmosphere model is negative or zero' comes from. Any suggestions would be appreciated!

 

[slevis]

@yifanc17
I searched the Forums for this error to look for other threads discussing it and found one that may be helpful:

ERROR: lnd_import ERROR: Longwave down sent from the atmosphere model is negative or zero

Hi everyone, I am trying to run a CLM5 simulation with ERA5 land-atmosphere forcing data at 01-degree spatial resolution. For these, I created a case using the compset below 2000_DATM%GSWP3v1_CLM50%SP_SICE_SOCN_MOSART_SGLC_SWAV_SIAC_SESP. However, my simulation fails after...

bb.cgd.ucar.edu

 

[oleson]

Hi Yifan, I agree with @slevis that the error is probably due to the datm trying to use a missing value in the forcing file. Is your plot of the mesh file indicating the variable elementMask in the mesh file (Energy conservation error downscaling longwave ERROR: replaced default GSWP3 forcing with ERA5 hourly data). If so, it seems to have 1s over the ocean and 0s over the land if I'm not mistaken. I would expect the opposite.

 

[yifanc17]

Thank you @slevis and @oleson for the feedbacks! Thanks for catching the error in the mesh file. I flipped the landmask and now it (elementMask) has 1s over the land and 0s over the ocean (please see figure attached below). However I'm still getting Energy conservation error downscaling longwaveERROR in atm2lndMod.F90. I have attached the cesm.log, atm.log, datm_in and datm.stream.xml files below.

I have also tried to change the model_maskfile and model_meshfile in datm_in to the 0.5x0.5° mesh file and it still failed with longwave error. However, to my understanding, although the input ERA5 forcing is 0.5x0.5°, based on the <meshfile> in datm.streams.xml (0.5x0.5°) and the specified resolution (in this case, 0.9x1.25°), the model will interpolate the forcing to needed resolution (the mapalgo is 'bilinear'). So I shouldn't be changing the model_maskfile and model_meshfile right? They should still be default at 0.9x1.25°? The ATM_NX, ATM_NY, ATM_DOMAIN_MESH should also stay the same as default 0.9x1.25° right? The only things I need to change are the <meshfile>, <datafile> and <datavars> for the Solar/Precip/TPQW streams in datm.streams.xml? Any suggestions would be appreciated!

 

[oleson]

Right, you shouldn't need to change anything else except your datm.streams.xml file. I would check to make sure that everywhere there is a 1 in the elementMask, that there is valid data in each of your datm forcing files. I do see now however that the lat/lon coordinates in your datm forcing files seem to be (i,j), not real lat/lons. E.g., your lats are:


lat = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55,
56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91,
92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107,
108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121,
122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135,
136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149,
150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163,
164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177,
178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191,
192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205,
206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219,
220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233,
234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247,
248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261,
262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275,
276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289,
290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 302, 303,
304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317,
318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331,
332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345,
346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359 ;

 

[yifanc17]

Right, you shouldn't need to change anything else except your datm.streams.xml file. I would check to make sure that everywhere there is a 1 in the elementMask, that there is valid data in each of your datm forcing files. I do see now however that the lat/lon coordinates in your datm forcing files seem to be (i,j), not real lat/lons. E.g., your lats are:


lat = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55,
56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91,
92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107,
108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121,
122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135,
136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149,
150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163,
164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177,
178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191,
192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205,
206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219,
220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233,
234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247,
248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261,
262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275,
276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289,
290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 302, 303,
304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317,
318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331,
332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345,
346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359 ;

Thanks for the clarification! I changed the lat/lon corrdinates of the forcing to be this since this is what the default GSWP3v1 forcing has (below figure is the FLDS from default forcing /glade/campaign/cesm/cesmdata/inputdata/atm/datm7/atm_forcing.datm7.GSWP3.0.5d.v1.c170516/TPHWL/clmforc.GSWP3.c2011.0.5x0.5.TPQWL.2005-01.nc). But thank you for reminding me of checking if there are land pixels without valid forcing data! I'll update here once I finished checking!

 

[oleson]

Oh, ok. I know there are coordinates on the GSWP3 files such as LATIXY and LONGXY which contain the actual coordinate information, but maybe those aren't used after all. lat and lon are dimensions on those files. I guess maybe the mesh file is the sole source of those coordinates.

 

[yifanc17]

Oh, ok. I know there are coordinates on the GSWP3 files such as LATIXY and LONGXY which contain the actual coordinate information, but maybe those aren't used after all. lat and lon are dimensions on those files. I guess maybe the mesh file is the sole source of those coordinates.

Yes I think the lat lon values come from the mesh file. It turned out that the land gridcells from forcing have mismatches with the land mask I generated with CESM grids so I re-generated compatible land mask and mesh file and it works now! Thank you so much for your help!