Error in N balance check while running CESM2.0.0

[fei1226h@126_com]

Hi all,I created a case with compset of I1PtClm50SpGS and single point resolution.At first, I made a surface data following the normal process illustrated in the clm5.0 user guide and the model spun up successfully.But I wanted to make a surface data with only one pft, so I used the command ./mksurfdata.pl -r usrspec -usr_gname $SITE -pft_frc 100 -pft_idx 17 -soil_cly .. -soil_snd..      to create a new surface data.Model always failed using this new surface data and the error is always the N balance.So is there something wrong with my new surface data?I noticed that there are two landunits, column and patches reported in the error log. Is it right ?It would be very greatful if anyone can help me solve the problem. Thanks!

 

[oleson]

I think the two landunits, two column, is fine.  In this configuration, a natural vegetation landunit and a crop landunit will always be created, even though it seems you are just running the managed crop type (17).That is a very large error (e17) to be getting suddenly.  It makes me suspect something in the forcing is bad (atmospheric, ndep, aerosols, etc.).  You might check those fields to see if they are reasonable.  It also seems to be happening early in the second year of the run, which is when the crop might start growing (crops don't start growing until year 2).  But I'm not sure why this would cause such a large N error.

 

[oleson]

I think the two landunits, two column, is fine.  In this configuration, a natural vegetation landunit and a crop landunit will always be created, even though it seems you are just running the managed crop type (17).That is a very large error (e17) to be getting suddenly.  It makes me suspect something in the forcing is bad (atmospheric, ndep, aerosols, etc.).  You might check those fields to see if they are reasonable.  It also seems to be happening early in the second year of the run, which is when the crop might start growing (crops don't start growing until year 2).  But I'm not sure why this would cause such a large N error.

 

[fei1226h@126_com]

I am very appreciated for your help!When I used the surface data without specifying the pft of 17, the spinup was okay.So I suspect the surface data has some problems.For the atmospheric forcing, I used CRUNCEPv7 from 2004 to 2014 year.For other forcing, I used the defaults.Can you help me to see if there is any problem with my setting or files?Thanks a lot!PS, the surface data of 181109 has only one pft, while 181026 has many pfts.

 

[fei1226h@126_com]

I am very appreciated for your help!When I used the surface data without specifying the pft of 17, the spinup was okay.So I suspect the surface data has some problems.For the atmospheric forcing, I used CRUNCEPv7 from 2004 to 2014 year.For other forcing, I used the defaults.Can you help me to see if there is any problem with my setting or files?Thanks a lot!PS, the surface data of 181109 has only one pft, while 181026 has many pfts.

 

[oleson]

I wonder if it's because you have "fill values" for CONST_FERTNITRO_CFT on your surface dataset (i.e., 9.99999961690316e+35).

 

[oleson]

I wonder if it's because you have "fill values" for CONST_FERTNITRO_CFT on your surface dataset (i.e., 9.99999961690316e+35).

 

[fei1226h@126_com]

Okay, I will check and try it again. Thank you so much !

 

[fei1226h@126_com]

Okay, I will check and try it again. Thank you so much !

 

[fei1226h@126_com]

It works! Thanks for your generous help!

 

[fei1226h@126_com]

It works! Thanks for your generous help!