ERROR: mismatch of input dimension 64 with expected value 2 for variable cft

[AdrienDams]

I am a new Fates user, I hope this is the right place to ask and not a repost.

I am trying to run CTSM with FATES on an unsupported computer (Levante). On a default grid it works fine, but I have a problem when I try to use my personal regional grid.

WARNING: New CFT-based format surface datasets should be run with 
 create_crop_landunit=T
 WARNING: When fates is on we allow new CFT based surface datasets 
 to be used with create_crop_land FALSE
 check_dim_size ERROR: mismatch of input dimension           64 
  with expected value            2  for variable cft
 ERROR: 
 ERROR in /work/aa0049/a271098/ctsm_levante/src/main/ncdio_pio.F90.in at line 40

I have tried another case with create_crop_landunit=.true. but it didn't solve the issue.

I have attached my parameter file.

&clm_inparm.txt

Also is there any documentation/tutorials on using FATES/CTSM with a regional grid available online?

[rgknox]

Thanks for checking in @AdrienDams , we've recently been working on this code. Prior to CTSM tag dev099 the user was required to use a surface dataset that had exactly 2 crop functional types (cfts). That tag introduced some flexibility, so you can have a different number of CFTs in the surface file. How many cfts are in your file? EDIT: I see the surface file your using has 78fts, which is 64 cfts+14 pfts right?

Currently, there is only one way to represent crops when FATES is active. When using in satellite phenology mode, use_fates_sp = .true. , fates will use the areas for the cfts defined in the surface file, and map that particular cft to a pft that is defined in the fates parameter file (a grass seems to be the best choice to start with).

But if you are not using this mode when fates is on, then the crops and their areas as ignored, and no crops are simulated.

[rgknox]

ok, I also see that you probably modified the surface file that is supported for non-fates runs, which has a cft size of 64. If you are using ctsm prior to dev099, then you will need to base your new surface file off of the 16pft datasets listed around line 1032 here:
https://github.com/ESCOMP/CTSM/blob/ctsm5.1.dev106/bld/namelist_files/namelist_defaults_ctsm.xml#L1032
cc'ing @ekluzek @glemieux

EDIT: If your building a regional grid, I'm betting you probably want to use the highest resolution global surface file to start with, maybe @ekluzek , can you point this one out?

[ekluzek]

Yes, currently you have to use on of the 16-PFT surface datasets rather than the 64 PFT versions. We have some issues where we want to change this. For example...

ESCOMP/CTSM#1505

The highest resolution dataset under inputdata is this one at 8th degree

lnd/clm2/surfdata_map/release-clm5.0.24/surfdata_0.125x0.125_hist_16pfts_Irrig_CMIP6_simyr2005_c190613.nc

[AdrienDams]

thanks @rgknox and @ekluzek, I am not sure why I would need a global surface file? Because I have made one for my domain:

surfdata_57_DOM02_hist_78pfts_CMIP6_simyr2000_c220330_mod.nc

Don't I just need to recreate one with only 16 pfts?

[ekluzek]

Yes, you just need a 16PFT version for your domain. So creating a 16pft version of the above file would work.

The reason we gave you a global 8th degree one is if it made sense to subset your domain area from it, as it's the highest resolution we have available. That may not apply to your case, but in case it did.

[AdrienDams]

@ekluzek I couldn't create a new 16 pft version due to a segmentationf fault. I guess it's a memory issue with the supercomputer I am using? Can you help me here or you think I should ask help from the supercomputer support team?

surfdata.log.txt

[ekluzek]

@AdrienDams according to your log look at line 563 of /work/aa0049/a271098/CTSM_old_versions/CTSM_pio2/tools/mksurfdata_map/src/mkpftMod.F90, and see why you might have a seg-fault there.

You should also try creating the file without the "-hires_pft" option and see if that works. You might also try using a more recent version of mksurfdata_map. If you can running this on cheyenne would be good to see if it's a machine specific thing.

It could be something unique with your machine that you can get advice from your SC support ream.

The other thing to do, would be to use subset_data rather than mksurfdata_map to create your regional dataset (if there is a global resolution that's close to what you need your regional resolution to be at). Most likely subset_data is going to work if that works for your application. If you absolutely need gridcells to be on a specific grid, that wouldn't work for you. But, it is going to be a more robust method to do this. You might try doing this just to show you can get a grid to work.

[AdrienDams]

I fixed the surfdata issue by just doing ulimit -s unlimited!

Now the model seems to work fine with the 16 PFTs data file, thanks again!