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

Determine development needs to update elm-fates with spitfire mode options #6

Closed
4 tasks done
glemieux opened this issue Jul 20, 2022 · 5 comments
Closed
4 tasks done

Comments

@glemieux
Copy link
Owner

glemieux commented Jul 20, 2022

Ryan noted that we do not have the Init2 routine and call in elmfates_interfaceMod.F90: https://github.com/ESCOMP/CTSM/blob/master/src/main/clm_initializeMod.F90#L457-L459

The elm code is setup to recognize the various spitfire mode options and pass them to fates, but we don't have any tests exercising this in e3sm or actual api code to appropriately initialize and read data for these modes.

@glemieux
Copy link
Owner Author

glemieux commented Oct 6, 2022

@ckoven I realize I had created this issue for my task list this summer. Do you have a prioritization for getting elm-fates to work with spitfire data modes?

@ckoven
Copy link
Collaborator

ckoven commented Oct 6, 2022

This will be needed/ highly desired for both pantropical (NGEE-Tropics) and global (E3SM) simulations, so I would say there is some amount of prioritization.

@glemieux
Copy link
Owner Author

glemieux commented Oct 6, 2022

For reference, this issue contains links to multiple issues and prs relevant to the fire data refactors that have taken place in clm: ESCOMP/CTSM#982

@glemieux
Copy link
Owner Author

Discussion this with Charlie today, we bumped this in priority to be the next major project post-seed dispersal. See this planning spreadsheet for context.

@glemieux
Copy link
Owner Author

glemieux commented Dec 5, 2022

Closing as complete.

@glemieux glemieux closed this as completed Dec 5, 2022
glemieux pushed a commit that referenced this issue Jun 13, 2023
cee/15.0.0 with GPU MPI buffers can crash in a system lib like this:

#4  0x00007fffe159e35b in (anonymous namespace)::do_free_with_callback(void*, void (*)(void*)) [clone .constprop.0] () from /opt/cray/pe/cce/15.0.0/cce/x86_64/lib/libtcmalloc_minimal.so.1
#5  0x00007fffe15a8f16 in tc_free () from /opt/cray/pe/cce/15.0.0/cce/x86_64/lib/libtcmalloc_minimal.so.1
#6  0x00007fffe99c2bcd in _dlerror_run () from /lib64/libdl.so.2
#7  0x00007fffe99c2481 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2
#8  0x00007fffea7bce42 in _ad_cray_lock_init () from /opt/cray/pe/lib64/libmpi_cray.so.12
#9  0x00007fffed7eb37a in call_init.part () from /lib64/ld-linux-x86-64.so.2
#10 0x00007fffed7eb496 in _dl_init () from /lib64/ld-linux-x86-64.so.2
#11 0x00007fffed7dc58a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#12 0x0000000000000001 in ?? ()
#13 0x00007fffffff42e7 in ?? ()
#14 0x0000000000000000 in ?? ()

Work around this by using cee/14.0.3.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants