Closed JhanSrbinovsky closed 2 days ago
serial single site cable.nml
&cablenml filename%met = 'TumbaFluxnet.1.3_met.nc' filename%out = 'out_cable.nc' filename%log = 'log_cable.txt' filename%restart_in = ' ' filename%restart_out = './restart_out.nc' filename%type = 'gridinfo_CSIRO_1x1.nc' filename%veg = "./def_veg_params.txt" filename%soil = "./def_soil_params.txt" vegparmnew = .TRUE. ! using new format when true soilparmnew = .TRUE. ! using new format when true spinup = .FALSE. ! do we spin up the model? delsoilM = 0.001 ! allowed variation in soil moisture for spin up delsoilT = 0.01 ! allowed variation in soil temperature for spin up output%restart = .FALSE. ! should a restart file be created? output%met = .FALSE. ! input met data output%flux = .TRUE. ! convective, runoff, NEE output%soil = .TRUE. !see #354 soil statescrews up dimensions for ferret output%snow = .FALSE. ! snow states output%radiation = .TRUE. ! net rad, albedo output%carbon = .FALSE. ! NEE, GPP, NPP, stores output%veg = .FALSE. ! vegetation states output%params = .FALSE. ! input parameters used to produce run output%patch = .FALSE. ! write per patch output%balances = .FALSE. ! energy and water balances check%ranges = .FALSE. ! variable ranges, input and output check%energy_bal = .FALSE. ! energy balance check%mass_bal = .FALSE. ! water/mass balance verbose = .TRUE. ! write details of every grid cell init and params to log? leaps = .TRUE. ! calculate timing with leap years? logn = 88 ! log file number - declared in input module fixedCO2 = 350.0 ! if not found in met file, in ppmv spincasa = .FALSE. ! spin casa before running the model if TRUE l_casacnp = .FALSE. ! using casaCNP with CABLE l_laiFeedbk = .FALSE. ! using prognostic LAI l_vcmaxFeedbk = .FALSE. ! using prognostic Vcmax icycle = 0 ! BP pull it out from casadimension and put here; 0 for not using casaCNP, 1 for C, 2 for C+N, 3 for C+N+P casafile%cnpipool='/projects/access/from_raijin/CABLE-AUX/core/biogeochem/poolcnpInTumbarumba.csv' ! casafile%cnpbiome='pftlookup.csv' ! biome specific BGC parameters casafile%cnpepool='poolcnpOut.csv' ! end of run pool size casafile%cnpmetout='casamet.nc' ! output daily met forcing for spinning casacnp casafile%cnpmetin='' ! list of daily met files for spinning casacnp casafile%phen='/projects/access/from_raijin/CABLE-AUX/core/biogeochem/modis_phenology_csiro.txt' ! modis phenology casafile%cnpflux='cnpfluxOut.csv' ncciy = 0 ! 0 for not using gswp; 4-digit year input for year of gswp met gswpfile%rainf = 'gswp/Rainf_gswp1987.nc' gswpfile%snowf = 'gswp/Snowf_gswp1987.nc' gswpfile%LWdown= 'gswp/LWdown_srb1987.nc' gswpfile%SWdown= 'gswp/SWdown_srb1987.nc' gswpfile%PSurf = 'gswp/PSurf_ecor1987.nc' gswpfile%Qair = 'gswp/Qair_cru1987.nc' gswpfile%Tair = 'gswp/Tair_cru1987.nc' gswpfile%wind = 'gswp/Wind_ncep1987.nc' redistrb = .FALSE. ! Turn on/off the hydraulic redistribution wiltParam = 0.5 satuParam = 0.8 cable_user%fwsoil_switch = 'standard' cable_user%pop_fbeam = .TRUE. &end
Issues for the refactorisation are currently organised per file. Drag the task items up and down to order by complexity. Some might be merged later on if they are inter-dependant and can not be treated separately:
Im not sure how you expect this per file issue to work? None of them exist in isolation. e.g Using the CABLE3 albedo() requires at minimum cbl_snow_albedo, soilColour, snowAging, all the corresponding calls and arg lists in cbm, modifications to the Makefile, the build script. Then modications to init_radiation, radiation are required. Then you drag in cbl_rhoch, spitter.
The other thing is prior to testing that the re-factoring yields identical results (with any necessary flags in place), it can''t be deemed as successfully completed. So you're going to need to combine several issues/branches?
My laziness leads me to wipe out a lot of this work. I mean, (following the lengthy opening comment) there is no reason to refactor many files. For e.g. mo/* as there is no CABLE3 counterpart? Several of the files we can move to an offline_pop dir without modification (there may be some thing in here we will want to make consistent across offline/ but I consider this out-of-scope. i.e. this is for an online PoP and perhaps using an offline_pop for spinup)
@JhanSrbinovsky
So you're going to need to combine several issues/branches?
Yes, I know the issues are not independent of each other. Opening them all can help document the dependencies. They still need to be ordered by level of complexity and dependence. But I didn't have the time to order them on Friday.
Several of the files we can move to an offline_pop dir
That's a modification that needs an issue and branch... 😄 So yeah, maybe a lot of the files will end up in one folder, or maybe after discussions, we'll do it differently. We'll see.
ive just revisited this today. It appears that no-one has looked at this in 4 months. I am still trying to see where exactly I got upto in the 242 branch. The comments seem to indicate that the whole thing has been merged except for canopy/ and soilsnow/. This kinda rings a bell, however it sounds to good to be true so I am skeptical.
I'm not sure how to deal with the above issues per file thing. I can't possibly have a branch per issue or each will be broken unless all ~20 are merged or thereabouts, etc. To maintain a testable version. For e.g. cable_albedo is split in cbl_albedo, snow_albedo, soil_colour_albedo. snow_aging is added. CALLs are different for all of them. USE statements different etc.
At any rate, it is taking a while to verify where things are even up to
code wise at least this appears to be the case ^^ except for soilsnow and canopy - merging has been done. comments also suggest that testing has been done given the above namelist. Also note that casa has not been merged. Im assuming we just grab "their" ski and pop and cable_climate as we never use it
apart from small differences in init_rad, rad & albedo = CABLE3 here.
apart from small differences in grid_constants and physical_const, params/ = CABLE3 here.
apart from these files in util = CABLE3 here.
cable_climate_type_mod.F90
cable_common.F90
cable_runtime_opts_mod.F90
extra files in params on either side easily dismissed (basically = CABLE3 here)
I will populate this over the next few days with a branch containing already partially completed tasks and a description of what has been done.
For now I have included some notes.
Background
A decade ago the ultimate/latest version of CABLE was CABLE1.4b.
CMIP5 version of CABLE in ACCESS1.3 corresponds to CABLE1.4c.
Following CMIP5, we created CABLE2 to resolve 2 issues:
Concurrently, we included land biogeochemistry into ACCESS1.3 to create ACCESS1.4.
Ocean biogeochemistry was then included and ACCESS1.4 beacame ESM1.5.
CMIP6 version of CABLE in ESM1.5 corresponds to CABLE2.4
CMIP6 version of CABLE in ACCESS-CM2 corresponds to CABLE2.5
The JAC(JULES and CABLE) project represents a long term aim to include CABLE as an alternative LSM to JULES in the UKMO framework. CABLE2.5 was the basis for JAC.
CABLE3 is the resultant(modified) JAC version of CABLE2.5, but essentially reproduces CABLE2.5
Issue
Below are listed the proposed CMIP7 variants (as per my understanding today) ::
ESM1.6
This model would cover our fast-track submissions and include:
ACCESS-CM3
This model would cover our coupled physical climate submissions:
ACCESS-ESM3
This model would cover our coupled ESM submissions and include:
All of the above CMIP7 variants (except ACCESS-ESM3) use CABLE3. CABLE3 being the most recent version of CABLE. We have (currently being reviewed) a working version of (ACCESS-)AM3, an atmosphere only version of CM3, which in turn logically forms the basis of an ESM3. The clear difference here is that ESM3 is proposed to use CABLE4.
The proposed CABLE4 is CABLE3+CABLE-POP(+LUC+BLAZE)
CABLE-POP is based on CABLE2.4. However, many developments between CABLE2.4 and CABLE3 have been manually implemented
Automated "merging" of CABLE-POP with CABLE3 is not an option as the differences that have evolved over the 10 years since they were last in sync are too great
The over-arching purpose of this development is to merge CABLE-POP into CABLE3. We reccomend that this is done in two steps. In Part 1 our aim is to re-factor CABLE-POP into the same file format as CABLE3, so that in Part 2 we can more easily review the difference in the contents of each of these files.
Part 1
Although our ultimate aim is to merge the contents of CABLE-POP into CABLE3, it is also a requirement to preserve the file structure of CABLE3. It will also become clear that the length of the pre-CABLE3 files ( CABLE-POP fits into this category ), makes this an arduous task. Finally, distributed in the CABLE3 format we will almost certainly discover that the contents of half of the code base can be immediately resolved as CABLE4.
Below we consider the stucrure of both CABLE3 and CABLE-POP. The missing directories can be discussed later but are more or less inconsequential to the merging which needs to be done here.
CABLE-POP
CABLE3
I dont think we should worry about merging the offline/ directories. I think we can proceed for now assuming that for offline applications we will have offline/ and offline_POP/. Certainly there are components of both which can be merged and used across both applications. However neither are required in a coupled application and it is a coupled application which is our priority here. Note however that even online POP may require some namelist/params directives etc. We shall focus on the science/ and core/ directories.
CABLE-POP
CABLE3
Mostly eveerything in biogeochem/ -> science/casa-cnp/. gw_hydro will be populated by the version currently being developed by Mengyuan and Ramzi. pop/ will be overwritten entirely by the POP code here. landuse/ is a directory containing a LU scheme that CABLE-POP has never employed and so will remain as is. sli/ will be reviewed at a later date. Excluding biogeochem/<->casa-cnp`/, in general the remaining science code from biogeophys/ is distributed amongst the corresponding named directory.
CABLE3
The
radiation/
directory in CABLE3 for example contains:Previously the contents of these files existed in one module (in cable_radiation.F90). In CABLE3 these independent module files are used in different combinations within
radiation/
, at other places in CABLE, and also indepently, directly from the UM/JULES. Moreover, ths structure adopted in CABLE3 is identical to that in JAC and is in general commensurate with that in JULES.The
canopy
andsoilsnow
directories are simarly distributed. However note, we have not yet included these in full as a part of a JAC submission and so they have been scrutinized to a lesser degree.The required exercise (at least in the first instance) is the same as what was required upgrading CABLE2.5 -> CABLE3, and then again in ESM1.5 -> ESM1.5+CABLE3. In essence, seperate the CABLE-POP versions of e.g. cable_canopy.F90 into the same parts as in CABLE3. Unfortunately it is not as simple as this, as there is a buch of plumbing that has to be updated as well.
CABLE3's version of POP is obsolete and will be replaced in full by that in CABLE-POP-TRENDY. It is therefore unnecessary run with POP turned on. We are interested in merging the science component outside of POP. To this end I have already modified CABLE-POP-TRENDY to build/run on a single site. I have fast, back-end testing mechanisms which I run periodically. At every significant juncture. As yet I havent modified the MPI build to test globally as we did with CABLE2->CABLE3, but this can be done. We might not bother and just pull it directly into AM3.
Ultimately, the finished article should give you exactly the same results as just running CABLE-POP-TRENDY. It is definitely worth testing periodically as more can go wrong than you might think.
Part 2
Lets do this in a new issue/branch. Basically now we have two file structures that look exctly the same.
At least half of the files will be able to be substituted fully with the CABLE3 versions (with minmimal plumbing perhaps). Everything else is up for discussion.