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

Develop draft design document for elm-fates fire updates #8

Closed
3 tasks done
glemieux opened this issue Oct 10, 2022 · 5 comments
Closed
3 tasks done

Develop draft design document for elm-fates fire updates #8

glemieux opened this issue Oct 10, 2022 · 5 comments

Comments

@glemieux
Copy link
Owner

glemieux commented Oct 10, 2022

  • Review clm and elm fire model code for comparison of approaches
  • Adapt clm design doc to write up design plan
  • Preview with Peter Schwarz and Gautam
@glemieux
Copy link
Owner Author

Design architecture flowcharts sketched out:

Questions so far:

  1. Why do we accumulate the lightning data into a 24 hour average (see InitAccBuffer and related routines for fates_fire_data_type)?
  2. What method (if any) is there that avoids calling the CNFire codes? Is it simply upstream use_cn calls? Is this consistent across hlms?

Note, with 1.) the accumulation routines called are using the AcummulMod that appears to be available in both hlms.

It does appear that the answer to 2.) is yes, it's simply the use_cn logic check for both hlms. However, this will need some refactoring in elm-fates as the FireInit call is behind a check for either use_cn or use_fates:

if (use_cn .or. use_fates) then
call EcosystemDynInit(bounds_proc,alm_fates)
else

@glemieux
Copy link
Owner Author

Questions so far:

  1. Why do we accumulate the lightning data into a 24 hour average (see InitAccBuffer and related routines for fates_fire_data_type)?

Sam said he believed this is because fates spitfire is running daily and data is coming in at a different rate, so it needs to be accumulated for spitfire.

@glemieux
Copy link
Owner Author

glemieux commented Nov 17, 2022

[x] Review the ctsm/fates issues for insight into the accumulation impetus

Conferring with Sam Levis, the reason for accumulating the data is that fates spitfire works on a daily tilmestep and the data set has a finer timestep.

@glemieux
Copy link
Owner Author

glemieux commented Dec 5, 2022

Peter said this looked good via an email. 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

1 participant