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.

Sign up for GitHub

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

Jump to bottom

Dependence on CIME Shared Libraries #177

Closed
rgknox opened this issue Jan 17, 2017 · 2 comments
Closed

Dependence on CIME Shared Libraries #177

rgknox opened this issue Jan 17, 2017 · 2 comments
Labels
question

Comments

@rgknox
Copy link
Contributor

rgknox commented Jan 17, 2017

Summary of Issue:

CIME provides various support functions and routines that may be shared by the models that use it. FATES currently uses these functions to gracefully abort a run.

The routines available are generally found in: cime/share/csm_share/shr/

There are also routines available to check numbers for errors like infinities and NaNs, we don't currently use these, but have started to discuss its possibility.

I believe one option is to maintain use of the CIME shared functions. Another option is to create our own light library, based off of these functions.

In the case of gracefully stopping a run. The CIME share library will print to error logs, perform a backtrace if the compiler provides intrinsics to do so, determine if MPI is running, and then either use MPI signaling to end a run or abort a serial job.

My impression is that copying over the important bits of CIME into a light library to end runs wouldn't be very difficult. But, there may be other juicy utilities that come with CIME that may be useful down the line. Of course, the con is that a dependence on any external library/model brings with it updating our calls if their system changes (incompatibility, although CIME's shared libraries may be very stable).

Thoughts, preferences?
@rgknox rgknox changed the title Dependence on CIME Dependence on CIME Shared Libraries Jan 17, 2017
@ckoven
Copy link
Contributor

ckoven commented Jan 17, 2017

I don't see any pressing need to remove CIME dependencies at this point. Since both of our required v1 HLMs use CIME, I'd support just maintaining the use of the shared functions.

@rgknox rgknox mentioned this issue Jan 25, 2017
Merged
bandre-ucar added a commit that referenced this issue Mar 6, 2017
@bandre-ucar
Interface: endrun and cleaning of fates<->hlm globals
b0bceb0 
Merge branch 'rgknox-endrun-maxcohort-weights'

In this change-set roughly two objectives are tackled. 1) a wrapper
was created to call the CIME shutdown/end-run utitlities. The wrapper
is essentially the same wrapper that CLM uses, but we need our own to
break dependence. 2) We have various globals in FATES that are
dictated by the HLM, and vice versa. I tried to wrangle these
variables into FatesInterfaceMod, and give them some functions to set
those variables and protect them. Moreover, the new global
fates_maxElementsPerSite and fates_maxElementsPerPatch, are calculate
based on the maximum requirements for array allocation for FATES
restarts. Previously, this was a hard-coded and misleading
value. While FATES asks the HLM to allocate a "cohort" array for
restart variables, it is really a multi-purpose array, and may be
larger than the needs we have to store cohorts.

Fixes: #178 and #177 and #144 and #186
Addresses: #141

User interface changes?: No

Code review:

Testing:

  rgknox:

    Test suite: edTest, clm_short_45
    Test baseline: 8b2ca7e (PR #176)
    Test namelist changes: None
    Test answer changes: b4b with baseline
    Test summary: all PASS

  andre

    Test suite: ed - yellowstone gnu, intel, pgi
                     hobart nag
    Test baseline: cdb9db7
    Test namelist changes: none
    Test answer: bit for bit
    Test summary: all tests pass

    Test suite: clm_short - yellowstone gnu, intel, pgi
    Test baseline: clm4_5_12_r195
    Test namelist changes: none
    Test answer: bit for bit
    Test summary: all tests pass
@rgknox
Copy link
Contributor Author

rgknox commented Mar 7, 2017

For the foreseeable future we seem to be maintaining dependency on CIME shared libraries. Feel free to resurrect/re-open this thread if we should re-address this.

@rgknox rgknox closed this as completed Mar 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rgknox @ckoven