Different levels of "active" for history fields

[ekluzek]

The following fields should be default inactive, as they are in the cmip6_output user-mods directory:

'PCT_CFT', 'PCT_GLC_MEC', 'SOIL1C_vr', 'SOIL1N_vr', 'SOIL2C_vr', 'SOIL2N_vr', 'SOIL3C_vr', 'SOIL3N_vr', 'CWDC_vr',
'LITR1C_vr', 'LITR2C_vr', 'LITR3C_vr', 'LITR1N_vr', 'LITR2N_vr', 'LITR3N_vr','CWDN_vr',
'PCT_NAT_PFT','SMIN_NO3_vr','CONC_O2_UNSAT', 'CONC_O2_SAT','SMIN_NH4_vr','SMINN_vr'

[ekluzek]

The c13 and c14 versions should also be turned off for: 'SOIL1C_vr', 'SOIL1N_vr', 'SOIL2C_vr', 'SOIL2N_vr', 'SOIL3C_vr', 'SOIL3N_vr', 'CWDC_vr',

[dlawrenncar]

Looking at this more carefully, I realize that we may not want to turn all these off by default. Some of them were turned off for monthly, but then added at annual level. If we turn off by default and user didn't turn on annual output through user-mods, then they wouldn't get these fields at all, which might be a problem.

…

On Tue, Oct 2, 2018 at 10:33 AM Erik Kluzek ***@***.***> wrote: The following fields should be default inactive, as they are in the cmip6_output user-mods directory: 'PCT_CFT', 'PCT_GLC_MEC', 'SOIL1C_vr', 'SOIL1N_vr', 'SOIL2C_vr', 'SOIL2N_vr', 'SOIL3C_vr', 'SOIL3N_vr', 'CWDC_vr', 'LITR1C_vr', 'LITR2C_vr', 'LITR3C_vr', 'LITR1N_vr', 'LITR2N_vr', 'LITR3N_vr','CWDN_vr', 'PCT_NAT_PFT','SMIN_NO3_vr','CONC_O2_UNSAT', 'CONC_O2_SAT','SMIN_NH4_vr','SMINN_vr' — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#528>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUAcVKLQImd3pzqHOHQsVZBleW1aSpcEks5ug5VmgaJpZM4XEaYQ> .

[ekluzek]

In that case the list to exclude would be...

'SMIN_NO3_vr','CONC_O2_UNSAT', 'CONC_O2_SAT','SMIN_NH4_vr','SMINN_vr'

[ekluzek]

I think we should be able to have more than one default output file (this would allow there to be default yearly output files). The user could change the output frequencies and details, but we could setup the default to be what we want. So we make the default output be a series of file streams at specific default output frequencies and such. I think this wouldn't be hard to do. If we really want it to be the standard default it might be best to have in the code. This would somewhat overlap with #529, but they can work together.

[wwieder]

sorry, traveling at the moment and just have my phone, but we should also should make sure FFIX_TO_SMINN is turned on by default in the CMIP6 / default CLM5 configuration, not sure what issue this points to now... On Tue, Oct 2, 2018 at 8:19 PM David Lawrence <notifications@github.com> wrote:

…

Looking at this more carefully, I realize that we may not want to turn all these off by default. Some of them were turned off for monthly, but then added at annual level. If we turn off by default and user didn't turn on annual output through user-mods, then they wouldn't get these fields at all, which might be a problem. On Tue, Oct 2, 2018 at 10:33 AM Erik Kluzek ***@***.***> wrote: > The following fields should be default inactive, as they are in the > cmip6_output user-mods directory: > > 'PCT_CFT', 'PCT_GLC_MEC', 'SOIL1C_vr', 'SOIL1N_vr', 'SOIL2C_vr', > 'SOIL2N_vr', 'SOIL3C_vr', 'SOIL3N_vr', 'CWDC_vr', > 'LITR1C_vr', 'LITR2C_vr', 'LITR3C_vr', 'LITR1N_vr', 'LITR2N_vr', > 'LITR3N_vr','CWDN_vr', > 'PCT_NAT_PFT','SMIN_NO3_vr','CONC_O2_UNSAT', > 'CONC_O2_SAT','SMIN_NH4_vr','SMINN_vr' > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#528>, or mute the thread > < https://github.com/notifications/unsubscribe-auth/AUAcVKLQImd3pzqHOHQsVZBleW1aSpcEks5ug5VmgaJpZM4XEaYQ > > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#528 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHqLJOBSDfCsp8V5OK55-Vli_hSSYuoMks5ug65MgaJpZM4XEaYQ> .

-- Will Wieder Project Scientist CGD, NCAR 303-497-1352

[billsacks]

@ekluzek regarding this comment:

I think we should be able to have more than one default output file (this would allow there to be default yearly output files). The user could change the output frequencies and details, but we could setup the default to be what we want. So we make the default output be a series of file streams at specific default output frequencies and such. I think this wouldn't be hard to do. If we really want it to be the standard default it might be best to have in the code. This would somewhat overlap with #529, but they can work together.

The more I think about this, the more I like the proposal in #529 rather than having this in code: I feel like, having a user_nl file set up with a starting point makes it easier for the user to add / change things, and makes it more likely that the end result of user modifications will be correct. I'm thinking about a few specific points:

1. Adding / removing fields from a stream is easier if you have the default list laid out in front of you (in the user_nl_clm file)

2. If you want to add, say, a field with daily frequency, gridcell average, this is again easier if you have hist_nhtfrq and related variables laid out in front of you (in the user_nl_clm file that you're editing). Otherwise it takes more work to determine which list the variable should be added to.

3. Perhaps the most important: Having the code say something like, "field FOO should be on by default on hist stream 2" doesn't feel like what we want, since the user can change the meaning of hist stream 2. For example, what if a user decides they just want two hist streams: the default monthly stream and a second stream that gives output every time step. They probably won't want the fields that were listed as active by default on hist stream 2 under the assumption that hist stream 2 is monthly average subgrid. So it seems like, if we go with your suggestion, we'd have to recommend to users that, if they change hist_dov2xy or hist_nhtfrq, then they should also set hist_empty_htapes (which would then need to be expanded to be a vector like the other hist_* variables). This seems to make things even harder for users to get right. Alternatively, we could have a more complex mechanism for specifying what's active by default, e.g., saying, "this field should be active on a history stream that is monthly average subgrid, if such a stream exists" – but it seems like that would be challenging to implement.

[billsacks]

However: I'm happy to defer to what users want here: if the people who need to use the model are happy not having this stuff in the default user_nl_clm, but instead having it set automatically, then I'm fine with it, too.

[dlawrenncar]

I'm fine with having it in the default user_nl_clm. I agree that it provides some nice flexibility. Perhaps something to discuss at a future CLM scientist meeting to see what people might prefer.

…

On Tue, Oct 2, 2018 at 4:14 PM Bill Sacks ***@***.***> wrote: However: I'm happy to defer to what users want here: if the people who need to use the model are happy not having this stuff in the default user_nl_clm, but instead having it set automatically, then I'm fine with it, too. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#528 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUAcVNxxRPnVwuTcNPWC_tYHWn7OS7Mdks5ug-UhgaJpZM4XEaYQ> .

[ekluzek]

Yeah, I'm for going with whatever users think makes the most sense. The thing I don't like about the #529 approach is that you have to have at least three configuration options. Right now we see, "sp", "bgc", and "crop", but in the future there could end up being others.

I've been thinking about how to implement this, and I envision having active flags like the following:

'active'
'active_yearly'
'active_yearly_1d_land' .
'active_yearly_REQUIRED'

'active_yearly' fields would go out to any 2D yearly output files (or not output if you don't have any yearly 2D output history files).
'active_yearly_REQUIRED' would be the same as above, except if you don't have any 2D yearly output files that would flag an error.

Two advantages of this are, first you don't worry about different lists for different configurations, and second when new fields are added you add it to the appropriate list. So you don't have to add the fortran code and then also add it one of the user_nl_clm lists.

It doesn't give the user the full list of all fields that will be output -- which I do see as both an advantage and as a headache.

[ekluzek]

So @dlawrenncar when is our next CLM Science meeting that I could present the two options at? I think it actually still makes sense to pursue both at the same time. But, work on this one would make #529 simpler. So we still do #529, but if we do this it's implementation would become simpler. That said we should still check with Sheri about how the cylc stuff works.

[dlawrenncar]

I wasn't planning to have a CLM meeting this week, but perhaps we could have a quick chat with just a few of us to review some options (e.g., Keith, me and you).

…

On Tue, Oct 2, 2018 at 4:56 PM Erik Kluzek ***@***.***> wrote: So @dlawrenncar <https://github.com/dlawrenncar> when is our next CLM Science meeting that I could present the two options at? I think it actually still makes sense to pursue both at the same time. But, work on this one would make #529 <#529> simpler. So we still do #529 <#529>, but if we do this it's implementation would become simpler. That said we should still check with Sheri about how the cylc stuff works. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#528 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUAcVLrbK9YaNkAKZBD5I2wVhd2kHY5qks5ug-84gaJpZM4XEaYQ> .

[billsacks]

In discussion with @dlawrenncar @ekluzek and @olyson , @ekluzek 's recent idea has grown on us.

@dlawrenncar suggests an additional idea (at least long-term): Having an xml variable that turns on/off vector output. This would control the hist_nhtfrq / hist_dov2xy lists.

[billsacks]

Moving over a comment that used to be its own issue: #6 ("For history fields, change 'active' terminology"):

I am adding 'active' flags saying: 'should computations be done here?' This leads to overloading of the term 'active' in histFileMod, which can lead to confusion. Erik suggests that we should eventually rename 'active' as it applies to history fields, perhaps to something like default_on.

We'll address this when putting in tiered output

I don't feel strongly about whether we should do this, but I wanted to mention this here.

[billsacks]

Title no longer matches what needs to be done. @ekluzek will edit.