Issue running clm with modified forcing file

[tc_chakraborty@yale_edu]

I have been trying to run CLM with forcing files created from a CAM run. The CAM run was from 2001 to 2006 and my plan is to run CLM for the same time span. The forcing files are made by overwriting the default GSWP3 forcing files with the CAM results. When I try to run with the forcing data from 2003, I get an error:ERROR: One or more of the output from CLM to the coupler are NaN # of NaNs =            1 Which are NaNs =  F F F F F F T F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F FYou can see this in job id  6755821 and in the attached log fileHowever, if I switch to looping over the datm files from 2001 to 2002, the run completes successfully. It seems like there is something wrong with the forcing data after 2003, but I haven't been able to pinpoint what it could be. My custom forcing files are here: /gpfs/fs1/scratch/tchakra/MYUSRDAT/ I would be extremely grateful if someone could help me with this. 

 

[oleson]

I don't see the files you attached.  Can you try again?I also don't see any attributes associated with a couple of your variables (e.g., WIND, FSDSdir), not sure if that is causing your problem

 

[tc_chakraborty@yale_edu]

I am attaching the log file again. Note that the forcing data works for the first two years, but fails after that. They were created identically, by taking 3-hourly CAM history data and overwriting the default GSWP3 forcing files. I did create new variables for FSDSdir (and overwrote the FSDS data with FSDSdif after changing the variable name) for the solar stream and ZBOT for the meteorology stream. 

I guess a related question is if the attributes themselves are read in when running CLM in the land only mode or if it is only the variable name that matters. 

 

[tc_chakraborty@yale_edu]

Another thing to note is that I have no issue running the model if I only use the custom Meteorology and Precipitation streams and the default GSWP3 forcing for radiation. The issue is probably in the custom solar forcing files for 2003. 

 

[oleson]

The log file indicates that a field from CLM to the coupler is NaN.  The field appears to be temperature (Sl_t).  This is the radiative temperature in CLM, which is derived from upward longwave radiation.  

 

[tc_chakraborty@yale_edu]

Thank you, Keith. 

So I recreated the forcing files, this time making sure all the attributes are added to the newly created forcing variables (they can be found here: /gpfs/fs1/scratch/tchakra/MYUSRDAT_new/). Unfortunately, this does not seem to solve the problem. I know the issue is with the solar files (since forcing the model using the other datm streams works), and probably either the file for 2003-01 or 2003-02. I am attaching the new log files. Do you know why I am facing this issue and how I could solve it?  
One option is to just loop through the 2001 and 2002 forcing files since I am not that concerned about the temporal evolution of the history fields. However, knowing why the error is occurring would be helpful. 

 

[oleson]

I cloned your case.  I output FSDS for each time step of the model run.  I see FSDS in excess of 2000 W/m2 in, e.g., SW U.S.  I think the model might have a problem with that much solar radiation.  So I wonder if your diffuse/direct partitioning is correct everywhere.  Maybe you are double-counting?

 

[oleson]

I checked the sum of diffuse and direct and it seemed to be reasonable.The unrealistic values were occurring when the sun was below the horizon, probably just some 'feature' of the interpolation scheme.I'll keep looking...

 

[oleson]

Since the model startdate is 2001, I changed this:    to this:     The model ran successfully from 2001 through 2003.Not quite sure why your other configuration didn't work. 

 

[tc_chakraborty@yale_edu]

Thanks a lot. The forcing data at least do not have FSDS that high (I think the max is 1200 W m -2). Anyway, changing the year alignment seems to have fixed the issue. 

Sorry for the late reply. Could not test the new configuration earlier since Cheyenne was down.