Add time-varying wave forcing, add warning for FSD without waves, make FSD tendencies per second

[lettie-roach]

For detailed information about submitting Pull Requests (PRs) to the CICE-Consortium,
please refer to: https://github.com/CICE-Consortium/About-Us/wiki/Resource-Index#information-for-developers

PR checklist

• Short (1 sentence) summary of your PR:
  Add time-varying wave forcing, add warning for FSD without waves, make FSD tendencies per second
• Developer(s):
  Lettie Roach
• Suggest PR reviewers from list in the column to the right.
  @eclare108213 @apcraig
• Please copy the PR test results link or provide a summary of testing completed below.
  No testing done
• How much do the PR code changes differ from the unmodified code?
  • bit for bit
  • different at roundoff level
  • more substantial
• Does this PR create or have dependencies on Icepack or any other models?
  • Yes
  • No
• Does this PR update the Icepack submodule? If so, the Icepack submodule must point to a hash on Icepack's main branch.
  • Yes
  • No
• Does this PR add any new test cases?
• Not sure
  • Yes
  • No
• Is the documentation being updated? ("Documentation" includes information on the wiki or in the .rst files from doc/source/, which are used to create the online technical docs at https://readthedocs.org/projects/cice-consortium-cice/. A test build of the technical docs will be performed as part of the PR testing.)
  • Yes
  • In icepack
  • No, does the documentation need to be updated at a later time?
    • Yes
    • No
• Please provide any additional information or relevant details below:

(@eclare108213 edited to remove spaces from the checkboxes)

[eclare108213]

This looks good to me. There should already be tests using this configuration, which is generalizing an existing one, but the new file will need to be posted with the rest of the (Icepack) forcing files.

[apcraig]

This all looks fine to me, I may run a few tests separately. I don't see any new file needed. Where does the new file come in?

[apcraig]

I ran a small suite of fsd tests and everything seems to pass and be bit-for-bit as currently implemented using the current test file.

PASS narwhal_gnu_smoke_gx3_4x2_debug_diag24_fsd1_run5day test 
PASS narwhal_gnu_smoke_gx3_8x2_diag24_fsd12_run5day test 
PASS narwhal_gnu_smoke_gx3_8x2_diag24_fsd12ww3_run1day test 
PASS narwhal_gnu_smoke_gx3_14x2_fsd12_histall test 
PASS narwhal_gnu_smoke_gx3_14x2_fsd12_reprosum_run10day test 
PASS narwhal_gnu_smoke_gx3_8x1_cmplogrest_fsd12_reprosum_run10day_thread test 
PASS narwhal_gnu_smoke_gx3_14x2_fsd12_gridc_reprosum_run10day test 
PASS narwhal_gnu_smoke_gx3_8x1_cmplogrest_fsd12_gridc_reprosum_run10day_thread test 
PASS narwhal_gnu_smoke_gx3_14x2_fsd12_gridcd_reprosum_run10day test 
PASS narwhal_gnu_smoke_gx3_8x1_cmplogrest_fsd12_gridcd_reprosum_run10day_thread test 
PASS narwhal_gnu_smoke_gx3_8x2_diag1_run5day test 
PASS narwhal_gnu_smoke_gx3_1x1_diag1_run1day test 
PASS narwhal_gnu_restart_gbox128_8x1_diag1 test 
PASS narwhal_gnu_restart_gx3_4x2_debug_diag1 test 
PASS narwhal_gnu_smoke_gx3_4x1_diag1_run5day_thread test 
PASS narwhal_gnu_unittest_gx3_1x1_helloworld test 
PASS narwhal_gnu_unittest_gx3_1x1_optargs test 
PASS narwhal_gnu_unittest_gx3_4x1x25x29x4_sumchk test 
PASS narwhal_gnu_unittest_gx3_1x1x25x29x16_sumchk test 
PASS narwhal_gnu_unittest_tx1_8x1_sumchk test 
PASS narwhal_gnu_unittest_gx3_4x1_bcstchk test 
PASS narwhal_gnu_unittest_gx3_1x1_bcstchk test 
PASS narwhal_gnu_unittest_gx3_8x2_dwblockall_gridavgchk test 
PASS narwhal_gnu_unittest_gx3_12x1_gridavgchk test 
PASS narwhal_gnu_unittest_gx1_28x1_dwblockall_gridavgchk test 
PASS narwhal_gnu_unittest_gx1_16x2_gridavgchk test 
PASS narwhal_gnu_unittest_gbox128_8x2_gridavgchk test 

[apcraig]

I think this can be merged. We can create a new PR when we have a new fsd dataset. Anyone disagree?