Inconsistent stellar_irradiance and downwelling shortwave flux

[lkluft]

• CliMT version: 0.9.1
• Python version: 3.6.3
• Operating System: Red Hat Enterprise Linux Server release 6.9 (Santiago)

Description

First of all thanks for the awesome work you are doing! 👍

I am using CliMT as a wrapper for RRTMG to calculate radiative fluxes and heatingrates. For my calculations I need to change the stellar_irradiance to different values (working together with Sally, #19 ). While doing so I found a disagreement between the stellar_irradiance and the downwelling shortwave flux at the top of the atmosphere. For a zenith angle of 0 degree both values should be exactly the same.

What I Did

When using the CliMT default state the stellar_irradiance is set to 1367.0 but the downwelling shortwave flux calculated is 1414.91 which seems odd. I found that the factor of 1.035 between both values is consistent when using other stellar_irradiance values, too. This may point to an issue with the normalisation of the irradiance?

Unfortunately our calls to CliMT are deeply embedded in our model setup which makes it hard to copy and paste the affected code. My test simulation basically consists of a standard atmosphere without any aerosols or CFCs.

It would be really cool if you could reproduce the bug. Even if not you may have some ideas what could cause this behaviour. I am happy to provide further information when needed!

Cheers,
Lukas

[mcgibbon]

Somewhat related, the solar constant probably shouldn't be hard-coded into the RRTMG docstring if it comes from the constants dictionary.

Can you create a minimal model which reproduces the downwelling shortwave flux, or at the least put your model on pastebin or somewhere, so we can see exactly what you mean by "the downwelling shortwave flux calculated"?

[mcgibbon]

Also use_solar_constant_from_fortran should specify a default value in the docstring (it's False).

[JoyMonteiro]

Hello Lukas,

I think I have seen this behaviour myself. I will see why this is the case in the next couple
of days. More importantly, I will see if this behaviour is present in the RRTMG Fortran code itself.

[JoyMonteiro]

@mcgibbon will fix these, thanks!

[lkluft]

Thanks for the quick response!

@mcgibbon I will try my best to create a minimal working example tomorrow 😉 Maybe I can avoid using our model and reproduce the issue in pure CliMT.

@JoyMonteiro Thanks! Let me know if I can - besides creating a test case - help you

[JoyMonteiro]

import climt
rad = climt.RRTMGShortwave()
state = climt.get_default_state([rad])
tend, diag = rad(state)

reproduces the issue.

[JoyMonteiro]

@mcgibbon looked at the docstring. The hardcoded values are present to inform the user of the internal fortran constants used by RRTMGShortwave. They are not used if use_constant_from_fortran is False.

@lkluft OK, I figured this out. The shortwave code uses the day of year to scale the solar constant with. The default value of time (in state['time']) is Jan 1, which is close to the solstice. Hence, the solar output is higher than the specified solar constant (since that is the average value).

if you change the time, for example

import climt
from datetime import timedelta
rad = climt.RRTMGShortwave()
state = climt.get_default_state([rad])
state['time'] += timedelta(days=80) # Close to equinox
tend, diag = rad(state)

Then the TOA downwelling radiation is close to what is specified by stellar_irradiance.

Recognising the fact that this is a valid RRTMG option that was not yet exposed at the python level,
I have added another option ignore_day_of_year which can be set to True while initialising RRTMGShortwave. It is by default False.
Setting this option will keep the solar constant always the same regardless of the model time.

Thanks for finding this!

[lkluft]

Thank you very much for the quick fix! The new option works like a charm!