Clean up soil vertical layers definition #279
Comments
|
Here was the response from @swensosc 2015-10-09 it's not simply an order of operations thing. The original code sets the nodes based on an exponential function, then specifies the interfaces to be midway between the nodes. I've spoken with @martynpclark about this, and I think we agreed that it wasn't the proper way to discretize things. The proper thing to do (I think) is to specify the layer thicknesses, with the assumption that the nodes are at the middle of each layer. Then the interface depths just follow from summing the dz's. Because the two ways of doing things are based on different assumptions about the relationship between the node position in the layer, I would prefer to somehow have that information clear. Going forward, I would like to see method 2 used for alternative soil discretization. I agree the code could be cleaner. I am picturing it looking a bit different than the above, with submethods: |
billsacks
added
type: enhance - science
type: enhancement
1) Clean-up following @swensosc and @billsacks suggestions in issue ESCOMP#279 2) Initial proposal for user-defined option of soil layer structure: - Use existing namelist variable soil_layerstruct - Instead of setting to an existing option (e.g. '5SL_3m', etc.), set soil_layerstruct = 'user:aa,bb,cc,dd,ee,ff,gg,...' where the string is declared of len=256 and 'user:' tells the code to expect a user defined structure, aa gets assigned to nlevsoi and nlevgrnd in the code, bb gets assigned to dzsoi(1) in the code, cc gets assigned to dzsoi(2) in the code, and so on to dzsoi(nlevgrnd).
|
From discussion: There are still two node-based options. It doesn't add much complexity to the code to keep it in, so we'll do that. |
Soil layer definition clean-up and user-defined option Code clean-up clarifes that there are two types of soil layer definition: the node-based and the thickness-based. User-defined option allows user to specify a soil layer profile in the form of a dzsoi vector (values in meters) in the thickness-based approach. Default nlevsoi for NWP configurations had to change from 5 to 4 for consistency with the new error check described in known bugs below. Other code clean-up removes a couple of sections of repeating code. Resolves #279 Resolves #728
Modified crown allometric spread logic
Moving a comment I made 2015-10-09 to here
I was looking at the new initVerticalMod on the branch that @bandre-ucar is about to bring to the trunk, because it ties in with the initInterp vertical interpolation stuff I'm working on. In doing so, I noticed some duplicated code / logic in setting up the vertical structure: It seems like there are basically two options:
Fundamentally set zsoi, then set dzsoi and zisoi based on that
Fundamentally set dzsoi, then set zsoi and zisoi based on that
However, the code to set zsoi based on dzsoi (or vice versa), and the code to set zisoi based on the others is duplicated for each of the 4(?) options. To me, having this near-duplicated code obscures the real differences between the different methods.
I feel this should look like:
See also #728
The text was updated successfully, but these errors were encountered: