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

Customized surfdata does not work

Yi Yao

Yi Yao
Member
Dear, I tried to expand the surfdata_map data from 64 cfts to 128 cfts, so I customized my surfdata_map in matlab. Except the variables with 'cft' dimension, I copied other variables from the old one to the new one. However, when I did a I-compset test (288x192), I had this error:

Attempting to read GLACIER_REGION...
(GETFIL): attempting to find local file surfdata_0.9x1.25_hist_78pfts_CMIP6_simyr2000_c201126_cdf5.nc
(GETFIL): using /data/brussel/vo/000/bvo00012/vsc10154/surfdata_0.9x1.25_hist_78pfts_CMIP6_simyr2000_c201126_cdf5.nc
vsize1= 0 vsize2= 192 vsize= 4
ERROR: error in vsize1 and vsize2 computationERROR in /dodrio/scratch/users/vsc10154/source/cesm-2.2.0/components/clm/src/main/ncdio_pio.F90.in at line 2498

I checked the code. It seems that the size of data read by CESM is 4, but when I check the data I created, it is 288x192. May I ask if you had the same problem before?
Thanks in advance!

Cheers,
Yi
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
I don't think there is enough information here right now for me to offer some suggestions, sorry. Please include the information described here:


Attaching the log files would be particularly helpful.
Also, could you attach the output of ncdump -h /data/brussel/vo/000/bvo00012/vsc10154/surfdata_0.9x1.25_hist_78pfts_CMIP6_simyr2000_c201126_cdf5.nc. I'm wondering what the dimensions of the GLACIER_REGION variable are. Although I guess you checked and it is GLACIER_REGION(lsmlat, lsmlon) where lsmlat=192 and lsmlon=288?
 

Yi Yao

Yi Yao
Member
Dear Keith,

Thanks for your reply and sorry for not clarifying the problem. Here I attach the files needed.The ncdump.txt is the output from another netcdf file. Since the model does not read this file, so I used nccopy -cdf5 to transfer it to cdf5file, and ncdump does not work for this file. The main changes in source code are in pdfconMod.F90 and IrrigationMod.F90. What I did was expanding from 64cfts to 128cfts (rainfed + 3 irrigated columns), and this is why I created a new surface dataset. I also created landuse-timeseries data but the CESM does not read it yet.

Cheers,
Yi
 

Attachments

  • Log_files.zip
    118.9 KB · Views: 4
  • ncdump.txt
    10.7 KB · Views: 5
  • Source_code_change.zip
    134.9 KB · Views: 1
  • describe_version.txt
    6.3 KB · Views: 4

oleson

Keith Oleson
CSEG and Liaisons
Staff member
Thanks for all of that information. In the lnd log file I see that the model is reading in a domain file that is fv1.9x2.5 (144 longitude by 96 latitude), not 0.9x1.25. So I wonder if that is part of the problem.
 

Yi Yao

Yi Yao
Member
Thanks for all of that information. In the lnd log file I see that the model is reading in a domain file that is fv1.9x2.5 (144 longitude by 96 latitude), not 0.9x1.25. So I wonder if that is part of the problem.
Dear Keith,
Thanks for your reply. Yes indeed that I forgot to change the resolution when creating the case. I am so sorry for this mistake. I correct it and then the model could successfully read the GLACIER_REGION. However, when the model check the weights of pft, there is another error again (see the attached image). I guess it is due to the fact that in initial files the pft column number is not same as the one in my surface dataset? I change the COLD_START to true . The same error still occurs. May I ask if there is any solution to avoid this?
The way I changed the surface dataset is as:
For every CFT, I expanded from 2 columns (rainfed + irrigated) to 4 columns (rainfed + drip irrigated + sprinkler irrigated + flood irrigated). Considering that my simulation will be from 2010 to 2100 so the model will take the data from landuse time series data to replace the data here, what I did was (rained = rainfed; drip_irrigated = 0; sprinkler_irrigated = 0; flood irrigated = irrigated).
Thanks in advance!

Cheers,
Yi
 

Attachments

  • 1676448939959.png
    1676448939959.png
    97.4 KB · Views: 10

oleson

Keith Oleson
CSEG and Liaisons
Staff member
There is a description of what the check_weights subroutine is doing in src/main/subgridWeightsMod.F90:

!-----------------------------------------------------------------------
! !DESCRIPTION:
! Handles modifications, error-checks and diagnostics related to changing subgrid weights
!
! ----- Requirements for subgrid weights that are enforced here -----
!
! (These requirements are checked in check_weights/weights_okay)
!
! Note: in the following, 'active' refers to a pft, column, landunit or grid cell over
! which computations are performed, and 'inactive' refers to a pft, column or landunit
! where computations are NOT performed (grid cells are always active).
!
! (1) For all columns, landunits and grid cells, the sum of all subgrid weights of its
! children (or grandchildren, etc.) is equal to 1. For example:
! - For all columns, the sum of all patch weights on the column equals 1
! - For all landunits, the sum of all col weights on the landunit equals 1
! - For all grid cells, the sum of all patch weights on the grid cell equals 1
! - etc.
!
! (2) For all ACTIVE columns, landunits and grid cells, the sum of all subgrid weights of
! its ACTIVE children (or grandchildren, etc.) is equal to 1. For example:
! - For all active columns, the sum of all patch weights on the column equals 1 when
! just considering active pfts
! - For all active landunits, the sum of all col weights on the landunit equals 1 when
! just considering active cols
! - For ALL grid cells, the sum of all patch weights on the grid cell equals 1 when
! just considering active pfts -- note that all grid cells are considered active!
! - etc.
!
! (3) For all INACTIVE columns, landunits and grid cells, the sum of all subgrid weights of
! its ACTIVE children, grandchildren, etc. are equal to either 0 or 1. For example:
! - For all inactive columns, the sum of all patch weights on the column equals either 0
! or 1 when just considering active pfts
! - For all inactive landunits, the sum of all col weights on the landunit equals
! either 0 or 1 when just considering active cols
! - etc.
!
! Another way of stating (2) and (3) is that the sum of weights of all ACTIVE pfts, cols
! or landunits on their parent/grandparent/etc. is always equal to either 0 or 1 -- and
! must be equal to 1 if this parent/grandparent, etc. is itself active.
!
! Note that, together, conditions (1) and (2) imply that any pft, col or landunit whose
! weight on the grid cell is non-zero must be active. In addition, these conditions imply
! that any patch whose weight on the column is non-zero must be active if the column is
! active (and similarly for any patch on an active landunit, and any col on an active
! landunit).
!

It looks like the error is being triggered for at least landunits and gridcells. So you'll have to check your surface dataset to see why the sum of subgrid weights for landunits and gridcells are not adding up to 1. It may be useful to print out the subgrid weights of all the children/grandchildren for one gridcell where the error is triggered and proceed from there.
Sorry I can't be more specific than that, we haven't done this type of modification to the surface dataset before.
 

Yi Yao

Yi Yao
Member
Thank you, Keith! Just an update that the development is done. I really appreciate your help!
Cheers,
Yi
 
Top