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

About mksrf_all_pfts

Hello CLM users,
I'm trying to make a new fsurdat with different resolution. It works well with mksrf_allpfts=.false., but failed when using mksrf_allpfts=.true.. The error information is as followed:

Attempting to read surface boundary data .....
(GETFIL): attempting to find local file surface-data.360x180.nc
(GETFIL): using surface-data.360x180.nc in current working directory
MKRANK error: iv(1) = missing
ENDRUN: called without a message string

Could you please tell me what the problem is, and how to solve it?

Thanks very much.

Shirley
 

slevis

Moderator
Shirley,

Let's make sure I understand what you did:

1) Did you first set fsurdat=' ' and mksrf_allpfts=.true. to create the file surface-data.360x180.nc? Did you then set fsurdat='surface-data.360x180.nc' and this gave you the error?

2) In creating the file surface-data.360x180.nc, did you point to all the mksrf* files provided with clm or did you use your own? Did you look at the contents of surface-data.360x180.nc to confirm that everything looks good? You should compare this file to the equivalent file created with mksrf_allpfts=.false., which you say works fine. You should also compare it to one of the equivalent files created with mksrf_allpfts=.true. that are provided with clm. By the way, does your code work or fail with one of the latter files (the ones provided with clm)? This should probably be your first test. If it works, look for differences between your file and the one provided with clm (other than resolution). Also, if it works, you could try to reproduce that file (the one provided with clm) by setting fsurdat=' ' and pointing to all the same files that we pointed to to create the file. You should be able to reproduce the file with no more than roundoff level differences.

3) Are you running clm3.0 or clm3.5 (available at the clm3.0 and clm3.5 release web sites) or some other version of clm? Have you modified the code since you started working with it? What platform are you running on?

I ask all these questions because we tested the model extensively before releasing it to the public. So before suspecting a bug, I suspect that you may be running on a platform that the ccsm group doesn't support, or you may be running code and/or datasets with modifications (which also make your model unsupported). Hopefully my questions will lead you to the source of the problem. If you still have questions, let me know.

Thanks,
Sam Levis
 
Hi Sam Levis,
Thanks very much for your reply. The answers to your questions are:
(1) Yes, I set fsurdat=' ' and mksrf_allpfts=.true. to create the file surface-data.360x180.nc. And at the same time, in the script card, I set
nsrest = 0
nestep = 2
start_ymd = 19980101
dtime = 1800

It seams that the model should run with the atmosphere forcing, which is related with the error information. For it run sucessfully when I choose the mksrf_all_pfts=.false. And, I've tried to set the set fsurdat='surface-data.360x180.nc' and run the model, but same error appears.

(2) I'll check the data created, thanks for your advice. I use all the clm rawdata to creat the .nc data, such as the mksrf_navyoro_20min.nc as the fgrid data in directory inputdata/lnd/clm2/srfdata/.
By the way, I've got the reasonable results at T42 resolution with the rawdata, such as the fgrid.clms_64x128_UGSS_c030605.nc for fgrid data. It matchs mostly with the fsurdata provided with CLM. So I firstly doubt it is becase of the fgrid data.

(3) I'm running clm3.0 without making any modifications except some system cofigurations (with the help of the system supporters), because I'm a new user of the model system. I'm running the model on the IBM P690.

Finally, I'd also ask a question about the land type transation. If I want to use another vegetation classification (such as IGBP) to replace the current system, shall I need to modify the model system too much? Do you have any reference or suggestions for me?
Thanks again.

Shirley
 

slevis

Moderator
If you follow the instructions in the user's guide (which you seem to be doing), then the model should work (according to our testing). However, our testing may have missed problems that didn't get triggered in our standard supported model resolutions. So I can only suggest that you search for subroutine mkrank and put write statements near the error to find out what's going on. If it's not imperative that you use 1x1 resolution, then you could consider using the supported resolutions (eg T42 or T85).

To change the vegetation classification, I recommend that you become very familiar with all the input datasets. Then you will understand exactly what you will need to change. I think that you should be able to limit your changes to datasets, and you should be able to not modify the code.

As I tell all our users, I offer initial help and basic guidance in your work but not much more according the ccsm support policy. Good luck with your project.

Sam Levis
CLM Community Liaison
 
Top