refactor of land NP supplementation flags & fates fixation updates

[rgknox]

This set of changes refactors the logic behind N and P supplementation in land bgc.
Also, ecosystem (free-living) N fixation was enabled for fates runs.

[non-BFB] for FATES tests

[rgknox]

land developer tests running on perlmutter: /pscratch/sd/r/rgknox/e3sm_tests/E03ee01df93-Fb8b905cc-spinup-v3

A previous version passed, but I had not merged in minor update, so I'm re-testing.

[rgknox]

cc: @evasinha @dmricciuto @bbye

[rgknox]

Testing generates differences from BASELINE in FATES test, this is expected. It also generates the following computation time increases:

TPUTCOMP Error: TPUTCOMP: Computation time increase > 10% from baseline

SMS_Ly2_P1x1.1x1_smallvilleIA.IELMCNCROP.pm-cpu_gnu.elm-force_netcdf_pio
SMS_Ly2_P1x1.1x1_smallvilleIA.IELMCNCROP.pm-cpu_gnu.elm-lulcc_sville

Are these also expected or typical?

[amametjanov]

@ndkeen can chime in too, but CPU runs (pm-cpu here, although gnu) should not vary this much from one run to another.

If you put in call t_startf('timer_name') + call t_stopf('timer_name') before and after the new additions and look at run/timing/model_timing[.00, _stats], do you observe corresponding timing increases?

Are these Ly2-long tests the only tests that show TPUTCOMP differences: e.g.

• SMS_Ld20.f45_f45.IELMFATES.elm-fates_[eca,rd,satphen] ?

You could try the tests that failed TPUTCOMP on Chrysalis+intel, to rule out a performance regression.

[rljacob]

I think pm has had a lot of variation while they work on the network.

[rgknox]

@amametjanov those two ly2 tests are the only ones showing tputcomp differences

[evasinha]

The changes in the PR look good and will not make any modifications to the crop simulations.

[bishtgautam]

@rgknox Is this BFB?

[bishtgautam]

@rgknox Just saw your comment above regarding test differences.