search

NCAR / ccpp-framework

Common Community Physics Package (CCPP)
http://www.dtcenter.org/community-code/common-community-physics-package-ccpp/
Other
26 stars 64 forks source link

Static API: Functional interface for communication between host and CCPP #353

Open nbren12 opened 3 years ago

nbren12 commented 3 years ago

Does the "static" method of coupling CCPP and the host require accessing the global state of the host model? For example, the single column models generated "ccpp_static_api.F90" file has these lines in it's module level declarations:

   use gmtb_scm_type_defs, only: physics

which get used further down like this


           ierr = SCM_GFS_v15p2_run_cap(physics=physics,cdata=cdata,con_eps=con_eps,con_epsm1=con_epsm1,con_fvirt=con_fvirt, &
                  con_rog=con_rog,con_rocp=con_rocp,con_rd=con_rd,LTP=LTP,con_g=con_g,con_tice=con_tice, &
                  con_cp=con_cp,con_hvap=con_hvap,huge=huge,con_hfus=con_hfus,con_jcal=con_jcal, &
                  con_rhw0=con_rhw0,con_sbc=con_sbc,con_pi=con_pi,rlapse=rlapse,con_t0c=con_t0c, &
                  con_rv=con_rv,con_omega=con_omega,con_epsq=con_epsq,con_cliq=con_cliq,con_cvap=con_cvap)

This prevents the host model from passing dynamically generated data to CCPP, which could be useful for a variety of applications. I am exploring automatically differentiation of CCPP, but need a functional interface like f(x) to do so. Another good example might be a Runge Kutta time stepper, which would need to call the "physics" multiple times before updating the global state.

nbren12 commented 3 years ago

Is this a requirement or mostly an implementation detail of the SCM?

climbfuji commented 3 years ago

Is this a requirement or mostly an implementation detail of the SCM?

For the current ccpp-framework code generator, it is more of a choice of design, and it's the same for the UFS, the SCM and NRL's NEPTUNE. We are currently working towards a new ccpp-framework code generator called capgen.py, which will handle those implementation details differently. Whether this version will be able to do what you want right from the start or, if not, how much effort it will require to implement it, is hard to say at the moment as we are still in the active development phase.

nbren12 commented 3 years ago

Thanks for the reply. When do you anticipate capgen being done?

I'd lobby for avoiding global state in the internals, since it can make a lot of cool things harder (e.g. wrapping by python/julia, auto diff/anything requiring >1 "state"). It would be great to consider these non-traditional use-cases assuming it doesn't harm the performance, since it will make the CCPP more widely usable outside of its original context of the FV3/UFS.

climbfuji commented 3 years ago

Thanks for the reply. When do you anticipate capgen being done?

I'd lobby for avoiding global state in the internals, since it can make a lot of cool things harder (e.g. wrapping by python/julia, auto diff/anything requiring >1 "state"). It would be great to consider these non-traditional use-cases assuming it doesn't harm the performance, since it will make the CCPP more widely usable outside of its original context of the FV3/UFS.

We are hoping to transition by the end of March, although this may slip by a bit. We'll keep your recommendation in mind, thanks for letting us know. Let's keep this issue open so that we don't forget.

nbren12 commented 3 years ago

Haha. sorry the de ja vu: https://github.com/NCAR/ccpp-framework/issues/345#issuecomment-758268611