drivers and share circular dependency with shr_dmodel #1713
Assignees
Comments
|
Please see #852 regarding the share library. |
Merged
ghost
added
jedwards4b
added a commit
that referenced
this issue
Aug 2, 2017
refactored datamodels refactored datamodels for new modularity This PR contains a refactorization of the data models in order to separate out the driver specfic parts of dxxx_comp_mod.F90 (which now contains datatypes such as cdata, infodata, etc. that are specific to the current mct cpl7 driver) and permit new driver implementations (e.g. nuopc) to use the core parts of the data models. In addition, a new directory data_comps/dshare now contains data model share code that was previously in share/utils. Test suite: scripts_regressions_tests The following tests had baselines generated without the refactor and tests were run to verify that the data model refactor maintained bfb answers - ERI.f09_g17.ETEST.cheyenne_intel.cice-default - ERI.f09_g17.ETEST.cheyenne_intel.cice-default - ERI.f09_g17.ETEST.cheyenne_intel.cice-default - ERI.T62_g16.C1850ECO.cheyenne_intel.pop-ecosys - ERI.T62_g16.C.cheyenne_intel.pop-default - ERI.T62_g16.CIAF.cheyenne_intel.pop-default - ERI.T62_g16.GIAF.cheyenne_intel.pop-default - ERI.T62_g17.DTEST.cheyenne_intel.cice-default - ERI.T62_g17.G.cheyenne_gnu.pop-cice - ERP_D_Ln9.f19_f19_mg17.QPC6.cheyenne_intel.cam-outfrq9s - ERP_D_Ln9.f19_f19_mg17.QSC6.cheyenne_intel.cam-outfrq9s - ERP_Ln9.f09_f09_mg17.F1850_DONOTUSE.cheyenne_intel.cam-outfrq9s - ERP_Ln9.f09_f09_mg17.FHIST_DEV.cheyenne_intel.cam-outfrq9s - ERP_Ln9.f19_f19_mg17.F2000_DEV.cheyenne_gnu.cam-outfrq9s - ERR.f45_g37_rx1.A.cheyenne_intel - ERS.f09_g16.ADLND.cheyenne_intel - ERS_Ld3.f45_g37_rx1.A.cheyenne_intel - ERS_Lm3.T62_g16.AIAF.cheyenne_intel - ERS_Ly20_N2_P2.f09_g16_gl20.T1850G1.cheyenne_intel - ERS_Ly3.f09_g16_gl4.T1850G.cheyenne_intel - PEM.f19_g16_rx1.A.cheyenne_intel - PEM.f19_g16_rx1.A.cheyenne_intel - SMS.f09_g16.ADWAV.cheyenne_intel Also ran most aux_clm5 tests and verified bfb with clm4_5_1_r251 Test baseline: see above Test namelist changes: Test status: none Fixes #1713 User interface changes?: None Update gh-pages html (Y/N)?: N Code review: jedwards, rjacob
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In working on the build system, I've noticed that the drivers/mct/util/seq_.F90 files depend on several share/utils/shr_.F90 shared functions, as is the purpose of share/util. However, there is also one dependency that goes the backward direction, where share/util/shr_dmodel_mod.F90 has a dependency back into drivers/mct/shr/seq_flds_mod.F90:
use seq_flds_mod, only : seq_flds_dom_coord, seq_flds_dom_otherwhere the seq_ variables are used just once in this line:
This is a minor annoyance to the build process, in that the share/util directory has to be broken up into multiple libraries to get the dependencies with drivers/mct/shr correct. I realized that this means that the share directory will not compile when another driver (nuopc) becomes an option, since a new driver presumably won't come with seq_flds_mod.F90. So thought it was worth calling attention to it.
Does anyone understand this code enough to untangle the circular dependency between these two directories, and have motivation to do so? (It isn't as simple as moving shr_dmodel into drivers/mct, since it is in turn used in other share/util files.) Thanks.
The text was updated successfully, but these errors were encountered: