POP is not consistent in how it applies scale factor to forcing fields

[mnlevy1981]

Description of the issue:

POP has three different ways it applies a scale factor to ecosys forcing data read from a file, depending on how the field_source argument to forcing_fields_add():

1. For shr_stream, we pass a unit_conv_factor argument
2. For POP monthly calendar, the scale factor is pulled out of the forcing_calendar_name argument (forcing_calendar_name%input%scale_factor)
3. For file_time_invariant, the scale factor must be applied separate from the file read (in forcing_init_post_processing)

For the time invariant files, we should definitely use the unit_conv_factor argument and apply the scale factor when reading the data. Note that this may not be bit-for-bit because currently the subsurface sediment flux is summed prior to applying the scale factor => this will change the order of operations.

For the POP monthly calendar files, there seem to be two options:

1. Pass unit_conv_factor=file_details%input%scale_factor in the forcing_fields_add() calls
2. Add a comment in the forcing_fields_metadata_type definition that unit_conv_factor is not used for monthly calendar files

This is not a high priority and should wait until after @klindsay28 has merged some of his science changes back to the marbl_dev branch of POP

Version:

• CESM: 2.2
• POP2: cesm_pop_2_1_20190410
• Migrating from marbl-ecosys/MARBL#123, originally noted in January 2017

Machine/Environment Description:

Machine independent

Any xml/namelist changes or SourceMods:

Problem exists out of the box