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

SLES12 bug in reading LAI, GRN, NIRDF, VISDF and NDVI in (LDAS) ensemble mode #304

Closed
gmao-rreichle opened this issue Jun 24, 2020 · 0 comments · Fixed by #305
Closed

SLES12 bug in reading LAI, GRN, NIRDF, VISDF and NDVI in (LDAS) ensemble mode #304

gmao-rreichle opened this issue Jun 24, 2020 · 0 comments · Fixed by #305
Assignees
Labels
0 diff The changes in this pull request have verified to be zero-diff with the target branch. bug Something isn't working Urgent!

Comments

@gmao-rreichle
Copy link
Contributor

A SLES12-related bug was discovered when the GCM GridComp is used in (LDAS) ensemble mode.
MAPL_ReadForcing is used to obtain time-interpolated, climatological values of LAI, GRN, NIRDF, VISDF and NDVI.
When restarting GEOSldas after certain dates late in the year, MAPL_ReadForcing exits with a "Preliminary end of file" message.

Specifically:

  1. Since the LAI, GRN, etc should be identical for all ensemble members (for now), for each variable the existing design created a set of links, one per ensemble member, to the same clim file. Previous compilers treated these different links as different files and kept separate file positions for each of the links.
  2. The Intel-19 compiler used for GEOSldas under SLES12 treats the different link names as the same file, which violates the design.
  3. As long as the MAPL_ReadForcing can read at least on date record in the forcing file, it produces the right answer because tMAPL_readForcing keeps adjusting the file position through the call "UPDATE_ENDPOINTS"
  4. When we restarted on 17 Dec 2015 at 0z, GRN passes the midpoint of the second to the last data record in the clim file. With the Intel-19 compiler, this messes up the position for the second ensemble member, which expects to read the header (date record) but for the second ensemble member the file position is now at the end of the file. Consequently, MAPL_ReadForcing exits with the "Preliminary end of file" message. If we restart on 16 Dec at 0z, MAPL_ReadForcing still can read the header and figure out that it needs to reposition itself. As long as it re-positions itself right, the reading would be right.
  5. To test this theory, we restarted on 30 Dec, which is past the midpoint of the second-to-last LAI record. Indeed, MAPL_ReadForcing now exits when reading the LAI for the second ensemble member.
  6. Besides not permitting restart dates late in the year, the original design is very inefficient. All ensemble members read and broadcast the data. The revised design saves the data read by the first ensemble member, and the other members simply use it.

cc: @jardizzo @atrayano @weiyuan-jiang @gmao-qliu @sdrabenh @wmputman

@gmao-rreichle gmao-rreichle added bug Something isn't working 0 diff The changes in this pull request have verified to be zero-diff with the target branch. Urgent! labels Jun 24, 2020
@gmao-rreichle gmao-rreichle self-assigned this Jun 24, 2020
gmao-rreichle added a commit to GEOS-ESM/GEOSldas that referenced this issue Jun 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0 diff The changes in this pull request have verified to be zero-diff with the target branch. bug Something isn't working Urgent!
Projects
None yet
1 participant