make some of the structured history output variables default-on

[ckoven]

We've added a bunch of structured history variables that let one look at much greater detail at what's going on in the model than the bulk grid cell averages, but at this point all of them are default-off for purposes of not taking up a lot of space. This used to be more of an issue for the size x PFT variables when we still used the old CLM number of PFTs, and that was the only dimension we could look across, however it is less of an issue now that we can slice across multiple different dimension combinations, and also since our PFT and PFT-multiplexed dimensions are sized by FATES rather than host model PFT numbers.

So, to that end, I'd like to propose that we start outputting a limited number of these as default-on in simulations. I've been working on a list that I think covers the basics of growth, mortality, number densities, and canopy structure.

Size-indexed NPLANT_CANOPY_SCLS NPLANT_UNDERSTORY_SCLS DDBH_CANOPY_SCLS DDBH_UNDERSTORY_SCLS MORTALITY_CANOPY_SCLS MORTALITY_UNDERSTORY_SCLS BA_SCLS

Age-indexed PATCH_AREA_BY_AGE CANOPY_AREA_BY_AGE

Size x Age -Indexed NPLANT_SCAG

scalar MORTALITY_CARBONFLUX_CANOPY MORTALITY_CARBONFLUX_UNDERSTORY

size x PFT -indexed (these are maybe a slightly lower priority since the size of the axes can get large, so perhaps it might make sense to put these all on a size-only dimension instead, but currently these mortality rates by type variables are only available on this dimension) NPLANT_SCPF M1_SCPF M2_SCPF M3_SCPF M4_SCPF M5_SCPF M6_SCPF M7_SCPF

[rosiealice]

I think that's a good idea... That way we can encourage people to look at these outputs and do things with them with a low technical overhead.

On Nov 14, 2017 1:16 AM, "Charlie Koven" notifications@github.com wrote:

We've added a bunch of structured history variables that let one look at much greater detail at what's going on in the model than the bulk grid cell averages, but at this point all of them are default-off for purposes of not taking up a lot of space. This used to be more of an issue for the size x PFT variables when we still used the old CLM number of PFTs, and that was the only dimension we could look across, however it is less of an issue now that we can slice across multiple different dimension combinations, and also since our PFT and PFT-multiplexed dimensions are sized by FATES rather than host model PFT numbers.

So, to that end, I'd like to propose that we start outputting a limited number of these as default-on in simulations. I've been working on a list that I think covers the basics of growth, mortality, number densities, and canopy structure.

Size-indexed NPLANT_CANOPY_SCLS NPLANT_UNDERSTORY_SCLS DDBH_CANOPY_SCLS DDBH_UNDERSTORY_SCLS MORTALITY_CANOPY_SCLS MORTALITY_UNDERSTORY_SCLS BA_SCLS

Age-indexed PATCH_AREA_BY_AGE CANOPY_AREA_BY_AGE

Size x Age -Indexed NPLANT_SCAG

scalar MORTALITY_CARBONFLUX_CANOPY MORTALITY_CARBONFLUX_UNDERSTORY

size x PFT -indexed (these are maybe a slightly lower priority since the size of the axes can get large, so perhaps it might make sense to put these all on a size-only dimension instead, but currently these mortality rates by type variables are only available on this dimension) NPLANT_SCPF M1_SCPF M2_SCPF M3_SCPF M4_SCPF M5_SCPF M6_SCPF M7_SCPF

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/298, or mute the thread https://github.com/notifications/unsubscribe-auth/AMWsQ0XhWiWBcNwxEoM95kcyuBzB5viNks5s2OnpgaJpZM4QcqNp .

[ckoven]

ok, thanks. I'll put in a PR soon to make this change. ED2 people (e.g. @mdietze @aswann @serbinsh ) are there any other structured (by size and/or age, etc) output variables that you find yourself looking at often and that we ought to be outputting by default?

[aswann]

I use AGB by dbh regularly. I’m not so familiar with the FATES variable names, but it doesn’t look like that is on your list?

Abby

On Nov 14, 2017, at 10:21 AM, Charlie Koven notifications@github.com wrote:

ok, thanks. I'll put in a PR soon to make this change. ED2 people (e.g. @mdietze @aswann @serbinsh ) are there any other structured (by size and/or age, etc) output variables that you find yourself looking at often and that we ought to be outputting by default?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ckoven]

Thanks Abby. That's right, we don't have that in there yet--just basal area and number density by dbh. I'll add that as a variable.

[tompowell9]

Hi Charlie,

Can you also add the component parts of DDBH by size-class--i.e. DDBH_CANOPY_MORTALITY_SCLS, DDBH_CANOPY_GROWTH_SCLS, DDBH_UNDER_MORTALITY_SCLS, DDBH_UNDER_GROWTH_SCLS?

The inventory data will have information about the cause of the change in dbh, and where in the canopy the different types of change occurred-- for example, slow growth of all trees and no mortality of any trees, compared to high growth of understory trees and infilling of tall trees after mortality of a few tall trees--all very useful for benchmarking.

Thanks, Tom

On Tue, Nov 14, 2017 at 8:13 PM, Charlie Koven notifications@github.com wrote:

Thanks Abby. That's right, we don't have that in there yet--just basal area and number density by dbh. I'll add that as a variable.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/298#issuecomment-344480801, or mute the thread https://github.com/notifications/unsubscribe-auth/AJnK6EWoFiiuek0h69S6fxopdJfajyq7ks5s2mT0gaJpZM4QcqNp .

[rgknox]

Thanks for the requests!

@tompowell9, can you elaborate a little on exactly variable we are capturing with: DDBH_CANOPY_MORTALITY_SCLS for instance? I'm a little confused because DDBH and MORTALITY are two different variables, or are you saying to bin the growth rates by their mortality rate?

[tompowell9]

In the censuses plots, the change in dbh for any particular size class is the sum of the growth in dbh of the trees that survived from census_1 to census_2 and the loss of dbh from the trees that died in that interval. The data may look something like this: [image: Inline image 1] This is made up data for 15 trees in the 30-40 cm size class. Units of dbh are cm. The census interval is 5 years. In that 5 year period, one tree died. The reported dbh data are usually richer than just the summary DDBH value. The reported data usually includes additional information about how the dbh changed over the interval. If we also include DDBH for growth and mortality in the model output, then we can make sure that the DDBH_CANOPY_SCLS is correct for the right reasons.

The reason it is nice to get at growth and mortality this way, rather than through other metrics like AGB, NPP, etc., is because dbh is what is directly measured on each tree in the field. If AGB or NPP is reported for measurements, then that has to first be run through some other scaling equation, which may not be the same scaling equation that is used in FATES; therefore the direct comparison can be confounded by these other factors.

Hope that clarifies.

Tom

On Wed, Nov 15, 2017 at 11:55 AM, Ryan Knox notifications@github.com wrote:

Thanks for the requests!

@tompowell9 https://github.com/tompowell9, can you elaborate a little on exactly variable we are capturing with: DDBH_CANOPY_MORTALITY_SCLS for instance? I'm a little confused because DDBH and MORTALITY are two different variables, or are you saying to bin the growth rates by their mortality rate?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/298#issuecomment-344709391, or mute the thread https://github.com/notifications/unsubscribe-auth/AJnK6B7I78XVBWrK_X3FWqLKvmaL2vo8ks5s20GZgaJpZM4QcqNp .

[rgknox]

OK, I see, thanks for clarifying. I am familiar with using BA for this type of metric.

[tompowell9]

I just suggested dbh because DDBH was already in the list, but I think doing it in terms of either BA would be fine too. TP

On Wed, Nov 15, 2017 at 1:27 PM, Ryan Knox notifications@github.com wrote:

OK, I see, thanks for clarifying. I am familiar with using BA for this type of metric.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/298#issuecomment-344733875, or mute the thread https://github.com/notifications/unsubscribe-auth/AJnK6Am8jA0fVbO374cKhCztzh9Li0Hhks5s21cwgaJpZM4QcqNp .

[ckoven]

closing; fixed by #304.