longwave radiation error:

[xgao304]

Dear Sir/Madam:

I am running the CLM5-BGC-crop at the 0.1 degree resolution over the user-defined region (eg., USA) using the following command:

create_newcase --case BgcCrop2000_USA --compset 2000_DATM%GSWP3v1_CLM50%BGC-CROP_SICE_SOCN_SROF_SGLC_SWAV --res hcru_hcru --user-mods-dir USAdata --machine svante --compiler intel --run-unsupported

The 0.1x0.1 surface and domain files are generated based on the suggestions from the thread I posted before (high resolution (0.1 degree) CLM5-BGC-crop regional simulation).

So far I have tested five forcing datasets:
1. GSWP3
2. CRUNCEP V7,
3. our in-house RCM outputs,
4. our in-house RCM outputs with bias-correction
5. CRU JRA v2.3 (https://catalogue.ceda.ac.uk/uuid/38715b12b22043118a208acd61771917)

The first three forcing datasets (the first two are CTSM-supported forcing) work fine, but the last two give me the similar error message:

"urban inside building net longwave radiation balance error" or "urban net longwave radiation error: no convergence"

I am a bit confused about what is going on. Does it imply some issues in the forcing $4 and #5? I can understand the bias-correction procedure may introduced
some inconsistency among variables, which may cause the error. However, #5 is a widely used forcing data as well.

Any suggestion about how to fix the problem? Please let me know if you need any other information.

Thanks a lot.

Xiang

 

[oleson]

In general, that longwave radiation error implies that there is some "bad" forcing (downward longwave radiation). It could either be unrealistically high, e.g., multiple orders of magnitude higher than it should be such that the longwave code can't converge, or it's using a missing or fill value.

 

[xgao304]

@oleson,

Thanks for the information. I have processed all the missing values in the downward longwave radiation and tried again. Now I got a slightly different error message "energy balance in canopy" with larger errors than the designated threshold (although I think the root cause might be the same - "bad values").
I also saw the warning "Total sensible heat does not equal sum of scaled heat fluxes for urban columns", but I assume this should not cause the CLM to stop?

I attached the log files. Based on the log file, does the first error occur at gridcell index "917" (90.55E, 23.05N)?
Is there an way to fix the issue?

Thanks,

Xiang

 

[oleson]

The magnitude of some of the errors you are getting may indicate that you still have forcing problems.
eflx_sh_grnd_scale: -2.438249995467353E+034 -1.950599880109063E+034
-1.950599880109063E+034 -1.015937397187079E+034 -6.095624383122471E+033

FillValues are usually 1e36 so it may still be that you are using FillValues for forcing somehow.

 

[xgao304]

@oleson,

Thanks for the information. I have two follow-up questions. For the forcing generated by the regional climate model,

1. Can boundary conditions of CTSM contain missing values in the ocean?
2. Do missing values in the ocean need to match land-sea mask in the domain file at the 0.1 degree (generated by the procedure you told me before)?

Xiang

 

[oleson]

If by boundary conditions you mean atmospheric forcing, then yes.
But the domain file that is specified in your datm streams files needs to specify a mask variable that is consistent with where the forcing data is valid/invalid.