Running CLM with ERA5 forcings

[oleson]

If you think your datm forcing files are good, then maybe your domain file (/work/aa0049/a271098/inputdata/atm/datm7/atm_forcing.datm7.ERA5/domain.lnd.1280x640_ERA5.0v1.c2106023.nc) is not consistent with your forcing data. The "mask" field on that file should have ones where there is valid forcing data and zeros where there is not. If the model is trying to use e.g., missing or bad values, from the forcing data, it could be causing an error.

It looks like your most recent simulation ran for at least 12 timesteps. You could output the forcing data at the model time step frequency on a history file to see if the forcing values the model is using are reasonable (e.g., FSDS, FLDS, QBOT, TBOT, RAIN, SNOW, etc.).

 

[adrienD]

I had to drop this issue for a while, but I can work on it again.

As you recommend, I checked all the forcing values on a regular grid and they all seem unreasonable. Therefore, the problem is not just solar forcing. I show you an example where I compare TBOT with the ERA forcings above, and the model forcing values below. Same scale, 06:00 January 1st 2000. I have similar results for the other variables.

I'm really sorry about this terrible "on the fly" mapping.



It seems that the problem is with the interpolation of the forcings?

I checked the ERA5 domain file and all the variables seem to make sense when I compare them to the GWSP3 domain file.

 

[oleson]

Since the ERA forcing is global, I guess there's not a problem with using missing/fill values.
You could try compiling/running in DEBUG mode and see what turns up: ./xmlchange DEBUG=TRUE.
You could also chase down the large longwave error you are getting:

3: indexp = 197990
3: WARNING: BalanceCheck: longwave energy balance error (W/m2)
3: nstep = 13
3: errlon = -232.276846976741
3: clm model is stopping - error is greater than 1e-5 (W/m2)
3: calling getglobalwrite with decomp_index= 197990 and clmlevel= pft
3: local patch index = 197990
3: global patch index = 186117
3: global column index = 186117
3: global landunit index = 74130
3: global gridcell index = 58576
3: gridcell longitude = 33.6110000610352
3: gridcell latitude = 65.7524642944336
3: pft type = 0
3: column type = 5
3: landunit type = 5
3: ENDRUN:
3: ERROR: ERROR in BalanceCheckMod.F90 at line 677

Put in some write statements to check the values of the incoming and outgoing longwave. It should be relatively easy to find the cause of such a large error.

 

[adrienD]

I have partially resolved my errors. The previous domain file we created contained negative longitude values for the corners, the first latitude was the north pole instead of the south pole and other details.

The procedure to create this domain file is actually quite complex. Is there a script in the github directory or elsewhere that people can use to make a domain file for new forcings? @oleson

Now, I can run any domain with ERA5 forcings but for some reason the model takes a very long time to read the forcings (over 2 hours, whereas it takes less than a minute with GSWP3 or CRU). Is this due to the fact that ERA5 is a higher resolution data file?

Thanks

 

[oleson]

@erik can probably provide better answers to these questions that I can.

 

[adrienD]

I have partially resolved my errors. The previous domain file we created contained negative longitude values for the corners, the first latitude was the north pole instead of the south pole and other details.

The procedure to create this domain file is actually quite complex. Is there a script in the github directory or elsewhere that people can use to make a domain file for new forcings? @oleson

Now, I can run any domain with ERA5 forcings but for some reason the model takes a very long time to read the forcings (over 2 hours, whereas it takes less than a minute with GSWP3 or CRU). Is this due to the fact that ERA5 is a higher resolution data file?

Thanks

If anyone has the same problem, I have managed to solve it. You need to reduce the number of files (number of years) of forcing in your stream files (e.g. user_datm.streams.txt.CLMGSWP3v1.Precip). By changing from including 50 years to 1 year, the model no longer needs 2 hours to read the forcing files.