surfrd_get_data ERROR: sum of wt_lunit not 1.0

[Hemraj]

Hi,
I am running CESM2.1.3 with FMOZ compset, trying to see the impact of landcover change. I keep on changing "PCT_NAT_PFT", "PCT_NAT_PFT+PCT_CFT" and "PCT_NAT_PFT+PCT_CFT+PCT_CROP". Making change on the first two runs well, but when I change PCT_CROP along with PCT_NAT_PFT & PCT_CFT, there is an error which looks like:
[8] surfrd_get_data ERROR: sum of wt_lunit not 1.0 at nl= 10883
[8] sum is: 1.00120781905990
[8] ENDRUN:
[10] surfrd_get_data ERROR: sum of wt_lunit not 1.0 at nl= 13510
[10] sum is: 1.24869315673030
[10] ENDRUN:
[11] surfrd_get_data ERROR: sum of wt_lunit not 1.0 at nl= 14824
[11] sum is: 1.00535551873313
[11] ENDRUN:
.........

A similar question was asked in this forum before (ERROR in surfrdUtilsMod.F90 running CESM2.1.1), but there was no response at all.

The problem is related to PCT_CROP land unit, but I have no idea how can I resolve it. I am really looking forward to the appropriate suggestion.

Many thanks.

 

[oleson]

I don't see any mention of PCT_NATVEG, the natural vegetated landunit. If you change PCT_CROP, then you'll need to change PCT_NATVEG, or one of the other landunits, so that they add up to 1.

 

[Hemraj]

Thank you @oleson for your kind reply.

My intention is to make the model read the future "landuse.timeseries" data (for different SSPs) instead of "surfdata". So, what I did is replace the data inside surfdata file with landuse.timeseries (i.e. make model read modified surfdata .nc file). The problem is all the PCT_... variables inside surfdata are not available in landuse.timeseries. For instance, PCT_CROP is available in both, but another combination of PCT_CROP, as you said PCT_NATVEG, is only available in surfdata but not in landuse.timeseries, which means I have no future PCT_NATVEG. Actually, I want to change PCT_NAT_PFT and CROP. I am not sure if just changing PCT_NAT_PFT and PCT_CFT will work for it. I am also not very clear about what actual difference between PCT_CROP and PCT_CFT. PCT_CFT has 2 variables in it, which sums to 1, I guess they are irrigated and unirrigated crops. But, how is it different from PCT_CROP, is PCT_CROP irrigated or unirrigated?

One of my major concerns is if I want to change future crop area, do I need to change PCT_CFT and PCT_CROP both or just changing PCT_CFT is ok (no need to change PCT_CROP)?

Many thanks.

# landuse.timeseries variables


# surfdata variables

 

[oleson]

Ok, I think I see what you are doing.
Let me know if any of my assumptions are wrong.
Based on previous posts you've modified the FMOZ compset to use CLM5 instead of CLM4.
You are changing the surface dataset pointed to by the fsurdat namelist item in lnd_in.
You aren't running transient landcover, you are simply using the information contained within the transient landcover dataset to make changes to the surface dataset file.

The existing surface dataset (in my FMOZ case this is surfdata_0.9x1.25_hist_16pfts_Irrig_CMIP6_simyr2000_c190214.nc) has these fields on it:

PCT_CROP
PCT_NATVEG
PCT_LAKE
PCT_WETLAND
PCT_GLACIER
PCT_URBAN

The sum of these has to equal 100% at each gridcell. Note that unlike other landunits, there are up to three urban landunits per gridcell.

If you change PCT_CROP then you'll have to change one or more of the other landunits to ensure that they all add up to 100%.

Also on the surface dataset is:

PCT_CFT

The sum of the two crops types (15 - C3 Unmanaged Rainfed Crop and 16 - C3 Unmanaged Irrigated Crop) must equal 100%, even for gridcells where PCT_CROP is zero (in this case crop type 15 is set to 100% and crop type 16 is set to 0%). These two crop types represent the non-irrigated/irrigated fractions on the crop landunit given by PCT_CROP.

Also on the surface dataset is:

PCT_NAT_PFT

The sum of these must equal 100%. They represent the fractions of pfts on the natural vegetated landunit given by PCT_NATVEG.

The reason that the PCT_NATVEG variable doesn't appear on the transient landuse file is because it is assumed that any changes in PCT_CROP are compensated by changes in PCT_NATVEG. This is done in the code.

 

[Hemraj]

Thank you @oleson
You understand correctly what I am planning to do.
As you asked to change other landunit when I change PCT_CROP

"If you change PCT_CROP then you'll have to change one or more of the other landunits to ensure that they all add up to 100%."

BUT we just have PCT_CROP in landuse.timeseries data (landuse.timeseries_0.9x1.25_SSP1-2.6_16pfts_Irrig_CMIP6_simyr1850-2100_c190214.nc).

I am sorry, but I still didn't get my answer how can I sum them to be 1 when five out of six variables are not available (green colored available, red not available).

PCT_CROP
PCT_NATVEG
PCT_LAKE
PCT_WETLAND
PCT_GLACIER
PCT_URBAN

 

[oleson]

They are available on the fsurdat file you are trying to change.
If you want to change PCT_CROP on the fsurdat file (e.g, increase it by 10% in a gridcell), then you'll need to change PCT_NATVEG on the fsurdat file (e.g., decrease it by 10% in a gridcell).

 

[Hemraj]

Many thanks. I got it

 

[AnuNTNU]

Does it mean that you cannot change the PCT_CROP in the landuse.timeseries data ? and is only possible to chnage PCT_CROP in fsurfdat?

 

[oleson]

Note that the user above wasn't running transient landcover, they were simply using the information contained within the transient landcover dataset to make changes to the surface dataset file. You can change PCT_CROP on the landuse file. As stated above, the reason that the PCT_NATVEG variable doesn't appear on the transient landuse file is because it is assumed that any changes in PCT_CROP are compensated by changes in PCT_NATVEG. This is done in the code.

 

[AnuNTNU]

Thanks. Can you correct me here for more clarification? I want to preserve the crop areas used for food in 2015 for the rest of the series in the landuse.timeseries data and I need to add some new crops in the increased crop area after 2015. I choose PCT_CROP for this purpose and then how can i translate the change in PCT_CROP to PCT_CFT? How do i assign the crop area increase after 2015 (PCT_CROP(eachyear)-PCT_CROP(2015)) to a particular crop using PCT_CFT ?

 

[slevis]

Hi @AnuNTNU,

I think that we do not offer recommendations for how to accomplish what you are asking. This means that you will need to make these choices yourself.

Sam Levis

 

[CGL]

They are available on the fsurdat file you are trying to change.
If you want to change PCT_CROP on the fsurdat file (e.g, increase it by 10% in a gridcell), then you'll need to change PCT_NATVEG on the fsurdat file (e.g., decrease it by 10% in a gridcell).

That's good advice. My problem will be solved.

Ok, I think I see what you are doing.
Let me know if any of my assumptions are wrong.
Based on previous posts you've modified the FMOZ compset to use CLM5 instead of CLM4.
You are changing the surface dataset pointed to by the fsurdat namelist item in lnd_in.
You aren't running transient landcover, you are simply using the information contained within the transient landcover dataset to make changes to the surface dataset file.

The existing surface dataset (in my FMOZ case this is surfdata_0.9x1.25_hist_16pfts_Irrig_CMIP6_simyr2000_c190214.nc) has these fields on it:

PCT_CROP
PCT_NATVEG
PCT_LAKE
PCT_WETLAND
PCT_GLACIER
PCT_URBAN

The sum of these has to equal 100% at each gridcell. Note that unlike other landunits, there are up to three urban landunits per gridcell.

If you change PCT_CROP then you'll have to change one or more of the other landunits to ensure that they all add up to 100%.

Also on the surface dataset is:

PCT_CFT

The sum of the two crops types (15 - C3 Unmanaged Rainfed Crop and 16 - C3 Unmanaged Irrigated Crop) must equal 100%, even for gridcells where PCT_CROP is zero (in this case crop type 15 is set to 100% and crop type 16 is set to 0%). These two crop types represent the non-irrigated/irrigated fractions on the crop landunit given by PCT_CROP.

Also on the surface dataset is:

PCT_NAT_PFT

The sum of these must equal 100%. They represent the fractions of pfts on the natural vegetated landunit given by PCT_NATVEG.

The reason that the PCT_NATVEG variable doesn't appear on the transient landuse file is because it is assumed that any changes in PCT_CROP are compensated by changes in PCT_NATVEG. This is done in the code.

@oleson,I note that the PCT_CROP+PCT_NATVEG+PCT_LAKE+PCT_WETLAND+PCT_GLACIER+PCT_URBAN = 100 ,as you said. But I sum the surfdat named "surfdata_0.9x1.25_hist_16pfts_Irrig_CMIP6_simyr2000_c190214.nc" in the F2000climo compset. I got the minus value is 44.38838057, not 100. It's that right?

 

[oleson]

"Note that unlike other landunits, there are up to three urban landunits per gridcell."
I'm guessing that you are only summing the first urban landunit.

 

[CGL]

"Note that unlike other landunits, there are up to three urban landunits per gridcell."
I'm guessing that you are only summing the first urban landunit.

You are right! When I sum all of the Urban landunits, it is 100%.

 

[JIAA]

Hello all, I have one question about changing the PCT_CROP or something like this.

In fsurdata file, there is up to 81 variables, and some variables like albedo, lai, are closed to landunits. Can I just change PCT_NATVEG or PCT_NAT_PFT to research the role of landcover?

Thanks all of you!

 

[slevis]

Similar question answered here: How to fix a certain type of PFT in CLM5.0

 

[CGL]

Ok, I think I see what you are doing.
Let me know if any of my assumptions are wrong.
Based on previous posts you've modified the FMOZ compset to use CLM5 instead of CLM4.
You are changing the surface dataset pointed to by the fsurdat namelist item in lnd_in.
You aren't running transient landcover, you are simply using the information contained within the transient landcover dataset to make changes to the surface dataset file.

The existing surface dataset (in my FMOZ case this is surfdata_0.9x1.25_hist_16pfts_Irrig_CMIP6_simyr2000_c190214.nc) has these fields on it:

PCT_CROP
PCT_NATVEG
PCT_LAKE
PCT_WETLAND
PCT_GLACIER
PCT_URBAN

The sum of these has to equal 100% at each gridcell. Note that unlike other landunits, there are up to three urban landunits per gridcell.

If you change PCT_CROP then you'll have to change one or more of the other landunits to ensure that they all add up to 100%.

Also on the surface dataset is:

PCT_CFT

The sum of the two crops types (15 - C3 Unmanaged Rainfed Crop and 16 - C3 Unmanaged Irrigated Crop) must equal 100%, even for gridcells where PCT_CROP is zero (in this case crop type 15 is set to 100% and crop type 16 is set to 0%). These two crop types represent the non-irrigated/irrigated fractions on the crop landunit given by PCT_CROP.

Also on the surface dataset is:

PCT_NAT_PFT

The sum of these must equal 100%. They represent the fractions of pfts on the natural vegetated landunit given by PCT_NATVEG.

The reason that the PCT_NATVEG variable doesn't appear on the transient landuse file is because it is assumed that any changes in PCT_CROP are compensated by changes in PCT_NATVEG. This is done in the code.

Hi,@oleson
I use the fusrdata named "surfdata_0.9x1.25_hist_16pfts_Irrig_CMIP6_simyr1850_c190214.nc" . I sum the PCT variables as you mentioned before.
But I got confuse because the Minimum is 99.99999999999997, not 100. As you can see, the maximum is 100.00000000000003.
It's will work in CLM? If I want to modify this to 100, which PCT should I choose?

 

[slevis]

To clarify, are these the sums from the original fsurdat file, or a version that you modified?

Either way, I think that the CLM will work with this level of precision. The only way to confirm is to try.

To modify this to 100, I would modify a PCT variable that is already non-zero. This way you don't introduce or try to remove landunits that do not already exist.

 

[CGL]

To clarify, are these the sums from the original fsurdat file, or a version that you modified?

Either way, I think that the CLM will work with this level of precision. The only way to confirm is to try.

To modify this to 100, I would modify a PCT variable that is already non-zero. This way you don't introduce or try to remove landunits that do not already exist.

The sums from the original fsurdat file.
Yes, the CLM work with this level of precision. So, It seems like the worry about not 100 for the sum of PCT is no need.

 

[xiaoxiaokuishu]

Note that the user above wasn't running transient landcover, they were simply using the information contained within the transient landcover dataset to make changes to the surface dataset file. You can change PCT_CROP on the landuse file. As stated above, the reason that the PCT_NATVEG variable doesn't appear on the transient landuse file is because it is assumed that any changes in PCT_CROP are compensated by changes in PCT_NATVEG. This is done in the code.

Hi, Oleson,
If i want to running a transient land cover, i have to revise the PCT_CROP in landuse time series and also all PCT_XX in surfdata for each year, and
give the right location of revised surfdata (now is time series surfdata) and revised time series landuse file in user_nl_clm, right?