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

MPAS-O analysis bug leads to testing failures #2768

Closed
jonbob opened this issue Feb 26, 2019 · 7 comments · Fixed by #2769
Closed

MPAS-O analysis bug leads to testing failures #2768

jonbob opened this issue Feb 26, 2019 · 7 comments · Fixed by #2769
Assignees
Labels
bug mpas-ocean Testing Anything related to unit/system tests

Comments

@jonbob
Copy link
Contributor

jonbob commented Feb 26, 2019

A recently commit introduced a bug in the mpas-ocean analysis member coding that causes failures in the automated testing of SMS_D_Ld1.ne30_oECv3_ICG.A_WCYCL1850S_CMIP6.allactive-v1cmip6, on sandiatoss3 and anvil using intel compilers

@jonbob jonbob added bug mpas-ocean Testing Anything related to unit/system tests labels Feb 26, 2019
@jonbob jonbob self-assigned this Feb 26, 2019
@milenaveneziani
Copy link
Contributor

Hi Jon, any idea what the bug is? Could you please open an issue on the MPAS-A side? Thanks.

@xylar
Copy link
Contributor

xylar commented Feb 26, 2019

@jonbob, you're referring to an analysis member (online analysis), not MPAS-Analysis, correct?

@jonbob
Copy link
Contributor Author

jonbob commented Feb 26, 2019

Sorry if that wasn't clear. The bug appears in one of the online mpas-ocean analysis member calculations, though my suspicion is that the error itself is in calculating a new array to be time-averaged

@xylar
Copy link
Contributor

xylar commented Feb 26, 2019

Yep, that's what I thought. Thanks for clarifying.

@mark-petersen
Copy link
Contributor

I was able to reproduce this with

SMS_D.T62_oQU120_ais20.MPAS_LISIO_TEST.cori-knl_gnu

It only occurs in debug mode. I’m getting an overflow on this line

mpas_ocn_time_series_stats.f90
2301 subroutine operate3r_avg (start_block, variable, buffers)
 
2333   out_array = (out_array * &                    !!!!!!!!!!!!!!!!!!! This line
2334     (buffers(b) % counter - 1) + in_array) &
2335     / buffers(b) % counter

and only when this new variable is in the time monthly output
activeTracerVerticalAdvectionTopFlux

@mark-petersen
Copy link
Contributor

Fix here. Thanks @jonbob for the help. MPAS-Dev/MPAS-Model#165

@jonbob
Copy link
Contributor Author

jonbob commented Feb 26, 2019

Great - and thanks for the quick fix @mark-petersen. Just let me know when the new submodule is accessible by e3sm

jonbob added a commit that referenced this issue Feb 27, 2019
)

Update mpas-source submodule to pick up indexing fix

This PR brings in a new mpas-source submodule that fixes an indexing issue on an
array that was causing debug tests to fail in the online time-averaging mpas
analysis. Vertical index k=1 on activeTracerVerticalAdvectionTopFlux is the ocean
surface, so is always zero. It was using some uninitialized values when using
k=1, so start loop at k=2.
See [MPAS-Model PR #165](MPAS-Dev/MPAS-Model#165)

Fixes #2768

[BFB]
jonbob added a commit that referenced this issue Feb 27, 2019
Update mpas-source submodule to pick up indexing fix

This PR brings in a new mpas-source submodule that fixes an indexing issue on an
array that was causing debug tests to fail in the online time-averaging mpas
analysis. Vertical index k=1 on activeTracerVerticalAdvectionTopFlux is the ocean
surface, so is always zero. It was using some uninitialized values when using
k=1, so start loop at k=2.
See [MPAS-Model PR #165](MPAS-Dev/MPAS-Model#165)

Fixes #2768

[BFB]
jonbob added a commit that referenced this issue Feb 28, 2019
Update mpas-source submodule to pick up indexing fix

This PR brings in a new mpas-source submodule that fixes an indexing issue on an
array that was causing debug tests to fail in the online time-averaging mpas
analysis. Vertical index k=1 on activeTracerVerticalAdvectionTopFlux is the ocean
surface, so is always zero. It was using some uninitialized values when using
k=1, so start loop at k=2.
See [MPAS-Model PR #165](MPAS-Dev/MPAS-Model#165)

Fixes #2768

[BFB]
bartgol pushed a commit that referenced this issue Mar 27, 2024
…netcdf-in-tas

Automatically Merged using E3SM Pull Request AutoTester
PR Title: Add pnetcdf paths to config line when running test-all-scream
PR Author: bartgol
PR LABELS: testing, AT: AUTOMERGE, scripts, AT: Skip v1 Testing
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mpas-ocean Testing Anything related to unit/system tests
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants