Open simohaka opened 1 month ago
Maybe @oyvindseland can answer this?
That is a mistake / misinterpretation. I was surprised that no one had found the problem since short wave cloud forcing is a quite common variable to analyze.
The reason is that short wave cloud forcing is not a variable that is cmorized but derived from other variables and this was never picked up since rsdsdiff was a Emon variable not Amon.
That is a mistake / misinterpretation. I was surprised that no one had found the problem since short wave cloud forcing is a quite common variable to analyze.
The reason is that short wave cloud forcing is not a variable that is cmorized but derived from other variables and this was never picked up since rsdsdiff was a Emon variable not Amon.
Thanks for the reply, Øyvind.
I don't understand what you said " short wave cloud forcing is not a variable that is cmorized but derived from other variables". So you meant SWCF in the model is derived from other variables, right?
Do we need to retract this dataset for all published rsdsdiff
in Emon
?
Yes SWCF is derived from other variables.
Do we need to retract this dataset for all published rsdsdiff in Emon?
Only for monthly fields. The cmorization script should also be updated as it will make it easier to provide the variable for specific simulations.
In https://github.com/NorESMhub/noresm2cmor/blob/master/namelists/var_CMIP6_NorESM2_default.nml the variable rsdsdiff (Surface Diffuse Downwelling Shortwave Radiation) is CMORized in the monthly data as:
'rsdsdiff ','SWCF (where SWCF: Shortwave cloud forcing)
whereas in the daily and 3-hourly output, it's CMORized as:
'rsdsdiff ','SOLLD+SOLSD (where SOLLD: Solar downward near infrared diffuse to surface, SOLDSD: Solar downward visible diffuse to surface)
The latter seems correct. I have also downloaded monthly rsdsdiff data from ESGF and also there the variable attribute 'original name' is 'SWCF'. Is there any reason/logic behind this or is it just a mistake?