Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add CABLE option cable_user%L_REV_CORR to all configurations #24

Open
ccarouge opened this issue Jan 30, 2025 · 2 comments
Open

Add CABLE option cable_user%L_REV_CORR to all configurations #24

ccarouge opened this issue Jan 30, 2025 · 2 comments

Comments

@ccarouge
Copy link
Member

To improve on the energy balance, we need to have the following option in cable.nml:

cable_user%L_REV_CORR = .True.

This option was introduced for work on ACCESS-CM2 to improve the energy balance and should be in used for ACCESS models based on CABLE3.

The option should be set in all configurations.

@ccarouge
Copy link
Member Author

ccarouge commented Jan 30, 2025

@har917 Can you check the issue above and make sure I understood the conversation here correctly? Is that so we need the L_REV_CORR option on in all ESM1.6 configurations.

From what I can see, I think Jhan added it to his running configuration but not to the shared configurations in this repository.

@har917
Copy link

har917 commented Jan 30, 2025

@ccarouge Hopefully for clarity:

  • offline runs do NOT need the correction terms - l_rev_corr shouldn't make a difference because all usage should be inside a cable_runtime%um_implicit like condition [but this itself is confused]
  • ESM1.5 effectively has l_rev_corr = .FALSE.
  • all future coupled configurations should have l_rev_corr = .TRUE. by default [unless someone really wants to go backwards].

Whether the route to ensure the switch takes a TRUE value is via the standard configuration (namelist) or hard-wired into the code somehow is down to NRI preference.


In the longer term we should either

  1. work to remove the switch from the code base entirely (it was only implemented this way to allow for backwards compatibility]
  2. (my preference) remove the correction terms from the codebase entirely (they're a blocker for SLI)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants