Open drnimbusrain opened 1 year ago
@zmoon After talking further with Rick, it seems that a sub-module approach to CANACC may be a good idea:
Canopy-app module containing functions to simply create generalized inputs for:
1) GridDefcow35.dat
generated from current canopy-app model namelist settings,
2) cnpycrs35.dat
generated from reading the shape distribution function from Massman as a surrogate for LAD in a new module (as done before for biogenics),
3) efCL160728d3.dat
generated from input point/gridded meteorology (GFS), and
4) soilCW160728.dat
generated from input point/gridded soil (GFS).
Ultimately canopy-app could generate these generalized inputs for each column and populate the control file, canaccCTRL.dat and run CANACC.
I think we should have all needed inputs for CANACC:
xa - NH3 at Zhi (ug/m3) ppfd - photosynthetic photon flux (umol/m2-s)
tak - air temp at Zhi (K) radg - incoming SW solar radiation (W/m2)
ts05k - soil temp at 2cm (K) lwdn - downwelling longwave radiation (W/m2)
ts20k - soil temp at 20cm (K) lewm2 - latent heat flux (W/m2)
pmb - air pressure (mbar) hwm2 - sensible heat flux (W/m2)
ubar - mean wind speed at Zhi (m/s) gwm2 - soil heat flux (W/m2)
rh - relative humidity (%) soilm - volumetric soil moisture (m3/m3)
ustar - friction velocity (m/s).
Canopy-app runs only at single time stamp with no time integration, single line of input data with time stamp for CANACC.
date time xa tak ts05k ts20k pmb ubar rh ustar ppfd radg lwdn lewm2 hwm2 gwm2 soilm
2016-07-28 00:00:00 6.20000e-02 2.94894e+02 2.94700e+02 2.93810e+02 9.34322e+02 1.05284e+00 8.58555e+01 1.35058e-01 0.00000e+00 0.00000e+00 3.72060e+02 -1.67100e+01 -1.95911e+01 2.65923e+00 1.87666e-01
I have a very preliminary start to making CANACC a submodule and running it through canopy-app (https://github.com/noaa-oar-arl/canopy-app/tree/canacc). The module interfaces to write/read CANACC inputs/outputs through canopy-app has not been done yet
Including CANACC will allow for subsequently adding related pieces of ACCESS model as stand-alone modules in canopy-app, such as dry deposition.
Ultimately, it would be better to use CANACC more as a library, i.e. instead of creating input files, pass the info to a driver routine. I don't think this would be that hard to set up.
Ultimately, it would be better to use CANACC more as a library, i.e. instead of creating input files, pass the info to a driver routine. I don't think this would be that hard to set up.
@zmoon Could you help with this outside of your priority NEXUS time? You can work off of the canacc branch or something else better.
Ultimately I think it would be best to have both approaches, i.e., 1) standalone parameterized modules (e.g., net photosynthesis) with individual canopy-app options (where possible), and 2) well as full coupled 1-D canopy models (as driver/ libraries as you suggest) with CANACC as a start. This is the ultimate flexibility for comparisons and implementation into larger scale models. I could start with 1) and maybe you on 2).
This issue is linked to #65 and deriving the carbon and nitrogen profiles in the canopy related to net photosynthesis rates (anet). The calculation of anet in canopy-app based on ACCESS is being derived in issue #60 for the Medlyn dry deposition method.
After discussion with Rick and Barry, we will go forward at first with taking pieces from ACCESS/CANACC, starting with photosynthesis net assimilation module, which can help connect the next pieces in adding LEB (also includes photosynthesis assimilation), temp/water vapor/scalar profiles, and dry deposition.