What to do with FATES tests when init_d is negative

[rosiealice]

In updating the parameter file for NorESM, wherein I had set the default init_d to be negative, @mvdebolskiy ran into the issue that this breaks the tests for full-FATES mode, as this option is only configured for NOCOMP=true modes. It seems to me like we will need a long term workaround for this situation. I can think of two options.

1. Make the code function such that it ignores the negative values when not in NOCOMP mode (adding possible user confusion).

2. Introduce a second defuault parameter file to be used in full-FATES mode (which seems like a bad idea, but maybe in the long run we will need different files for these anyway?)

3. Add logic for this to work in non-NOCOMP modes, maybe by dividing the grid cell evenly between PFTS? This might have some scientific utility anyway...

What do y'all think? @JessicaNeedham @ckoven ?

[JessicaNeedham]

As a long term solution I think 3 sounds like a good option. Maybe short term we could make this two parameters, init_density which is used in full fates, and init_dbh which is used for no comp mode. That way we can maintain sensible values for both and hopefully cause less user confusion? The only issue I see with this is that we'd be making no comp default to using initial size.

[glemieux]

@ckoven notes in the software meeting that having the capability to more robustly modify the parameter file on the fly, is the root problem to solve regarding the user's experience. See #1296 for discussion on this topic.

[JessicaNeedham]

For NorESM we decided to split this into two parameters, one for nocomp runs which continues to be both negative and positive for dbh or density initialisations, and the other which is just positive for density initialisation of full fates. NorESM-FATES PR is here: NorESMhub#34.
Do we also want this change here?