-
Notifications
You must be signed in to change notification settings - Fork 371
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
Remove excess initialization from BGC code #6058
Remove excess initialization from BGC code #6058
Conversation
Added initializing into compute loops when needed, and switched some variables to be only be initialized on the first time step. the harvest variables shouldn't require initializing every timestep but extra effort is needed to untangle the dependencies and order of operations.
…lity. Cleaned up the comments in VegetationDataType
…land test to fail.
@@ -308,7 +308,9 @@ subroutine SoilLittDecompAlloc (bounds, num_soilc, filter_soilc, & | |||
/ cp_decomp_pools_new(c,j,cascade_receiver_pool(k)) ) | |||
|
|||
else ! 100% respiration | |||
pmpf_decomp_cascade(c,j,k) = - p_decomp_cpool_loss(c,j,k) / cp_decomp_pools(c,j,cascade_donor_pool(k)) | |||
if(decomp_ppools_vr(c,j,cascade_donor_pool(k)) > 0._r8) then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peterdschwartz, is this future proofing or was this already causing div0s? If zero's were being passed in, then I would recommend flagging this as an issue so you can have someone put time into figuring out why.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this only became an issue when I removed certain initializations from the SetValues routine. Likewise with other changes: some initializations were moved to loops that first use that variable. This is for variables that only have meaningful values for certain types of pfts or cols for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rgknox Did I answer your question?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, sorry for the late reply! thanks for the bump
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These look good to me @peterdschwartz
addressed comments |
…#6058) Every model timestep, the vegetation and column fluxes are set to zero for the CNP variables. This took up roughly 1/3rd of the time for the Ecosystem model time, and this PR reduces that by over half. [BFB]
I see some of the e3sm_integration BGC tests have diffs with intel compiler only. I'll try to have it sorted today |
Looks like it was a small number of fields. |
@bishtgautam Queue times have been slow, but I've isolated the issue to a specific subroutine. I'll be able to push a fix sometime tonight (depending on job turnover), but I wouldn't worry about being able to re-merge it tonight. |
Testing found some diffs with baselines. Seen on both chrysalis and pm-cpu (The only ones running integration with baselines) The cases with 5 variables diffing.
The variables (from one of the cases, grepping for "RMS" in cprnc.out)
This seems like its a simple fix. But 2 other cases had 255 variables diffing (which implies a real diff introduced in to the state early since its only 5 steps).
|
@rljacob Yes I'm aware of the differences. I tried to focus on
as it is shorter and requires less resources, but I ran into the issue on chrysalis where this test DIFFs (in 255 variables) with master. I asked Gautam to do the same, and his case also gave DIFFs (same 255 variables) with master, so I think something is wrong with the default chrysalis environment (this isn't the only issue I've encountered when running test suites on chrysalis) I don't have this issue with pm-cpu but the queue times are pretty long and that's the only thing holding this debugging effort back. |
I was just noting for the record. The jenkins testing on Chrysalis uses different node counts then regular runs for a given resolution. If you are comparing a run you do with the Jenkins-generated baseline then you might be picking up a pelayout diff that has crept in. Try making your own baseline with the same pelayout as your test case. |
@rljacob Right! the cases do also report NLDIFF for the pelayout so that could be it, thanks. |
Good that should help find the issue with this PR. Unfortunately, there's now another issue because that case can't pass a PEM test. That may have existed for a while and can be looked at later. |
@bishtgautam Newest commit has fixed the 4 test diffs |
@bishtgautam you can merge this to master. |
Every model timestep, the vegetation and column fluxes are set to zero for the CNP variables.
This took up roughly 1/3rd of the time for the Ecosystem model time, and this PR reduces that by over half.
[BFB]