Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mnlevy1981 opened this issue Jan 3, 2017 · 1 comment
Closed

Comments

@mnlevy1981
Copy link
Collaborator

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

@mnlevy1981
Copy link
Collaborator Author

Moved to ESCOMP/POP2-CESM#3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant