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

Bring in CTSM bug fix tag when it is ready #616

Closed
cacraigucar opened this issue Jul 12, 2022 · 4 comments
Closed

Bring in CTSM bug fix tag when it is ready #616

cacraigucar opened this issue Jul 12, 2022 · 4 comments
Assignees
Labels
bug Something isn't working correctly Priority 1 bug Top priority bug

Comments

@cacraigucar
Copy link
Collaborator

cacraigucar commented Jul 12, 2022

What happened?

ESCOMP/CTSM#1802

What are the steps to reproduce the bug?

See the CTSM PR

What CAM tag were you using?

NA

What machine were you running CAM on?

Other (please explain below)

What compiler were you using?

Other (please specify below)

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

Yes

Extra info

This bug causes issues when CAM's timestep is changed to something other than 30 minutes. See the more complete description below by @billsacks

@cacraigucar cacraigucar added the bug Something isn't working correctly label Jul 12, 2022
@cacraigucar cacraigucar self-assigned this Jul 12, 2022
@cacraigucar cacraigucar added the Priority 1 bug Top priority bug label Jul 12, 2022
@cacraigucar cacraigucar moved this to To Do in CAM Development Jul 12, 2022
@billsacks
Copy link
Member

Just to clarify for people reading this issue who haven't read the associated CTSM issue: The issue isn't quite as pervasive as suggested by this:

CTSM remains at 30 minute timestep

Rather, the issue is more subtle: CTSM has a number of accumulation fields that accumulate averages over some period. These accumulation fields weren't properly handling a change in time step (relative to what was used to generate the initial conditions file). So, for example, if you are using a 15-minute time step with an initial conditions file that originated from a run with a 30-minute time step (at some point in its history), then an average that was supposed to be 10-day instead becomes 5-day; an average that was supposed to be 1-day becomes 12-hour, etc. (The issue is that the number of time steps in the averaging period was staying fixed rather than the actual amount of time staying fixed.) It appears that the biggest impacts are on VOC emissions and in BGC runs; we expect the impact to be small (but still non-zero) in prescribed phenology (SP) runs that don't use VOC emissions.

@billsacks
Copy link
Member

I have just made the relevant CTSM tag: ctsm5.1.dev103

@adamrher
Copy link

Thanks, @billsacks. I'm not that concerned how this bug may have impacted my prior variable-resolution simulations, particularly because I run SP mode, but also because I don't do really in-depth analysis of CLM fields besides the surface mass balance stuff, and its hard to conceive that this abstract accumulation variable is a leading order term influencing temperature, melt rates, etc... I think @lkemmons and the MUSICA folks are more concerned about this bug as they run in BGC mode and emissions and other land model specific processes are a crucial component of their science, so I'm sure they appreciate you prioritizing this issue.

@cacraigucar
Copy link
Collaborator Author

@billsacks I have just successfully made a CAM tag using dev102, so I will be able to use your CTSM tag ctsm5.1.dev103 directly and will not need you to make a special branch tag.

Repository owner moved this from To Do to Done in CAM Development Jul 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working correctly Priority 1 bug Top priority bug
Projects
Status: Done
Development

No branches or pull requests

4 participants