Integrate evp1d - dont integrate yet

[TillRasmussen]

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:
  Integration of new version of 1d
• Developer(s):
  Jacob Poulsen Intel, @TillRasmussen, DMI, @mhrib
• 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.
  Test are performed on freya and the following has been run.
  ./cice.setup --suite base_suite,quick_suite,decomp_suite -m freya -e intel,gnu -s debug
  It is bit for bit in all cases (when debug is applied except for the gbox, which is caused by halo updates not being implemented for open boundaries. Cyclic boundaries are updated. This will soon be included.
  QC test are passed.
• How much do the PR code changes differ from the unmodified code?
  • bit for bit
  • [ x] different at roundoff level
  • more substantial
• Does this PR create or have dependencies on Icepack or any other models?
  • Yes
  • [ x] No
• Does this PR update the Icepack submodule? If so, the Icepack submodule must point to a hash on Icepack's main branch.
  • Yes
  • [x ] No
• Does this PR add any new test cases?
  • Yes
  • [x ] 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
  • [ x] No, does the documentation need to be updated at a later time?
    • [ x] Yes
    • No
• Please provide any additional information or relevant details below:
  This is not yet ready to be fully integrated, however this is very close to and I would like a review in order to clarify issues.
  I had to comment out OMP 3 places in the existing code as the code fails otherwise. These are marked with TILL and are located in ice_diagnostics line 1458, 1505, 1544 and 1581. The second place is in ice_transport_remap line 650. The latter has been noted by @apcraig as well.
  I would like a review of the code as is and potentially advise on other test to run.

QC test are shown below

[TillRasmussen]

One thing I will do is to reduce the number of commits.

[mhrib]

A suggestion:
Check for open boundaries and exit if it is the case for evp_1d kernel.

Do something similar as is already done for tripole grid check in file: ice_dyn_evp.F90

if (trim(grid_type) == 'tripole') then
   call abort_ice(trim(subname)//' &
      & Kernel not tested on tripole grid. Set evp_algorithm=standard_2d')
endif

if ((ew_boundary_type == 'open' .or. & ns_boundary_type == 'open')) then 
  call abort_ice(trim(subname)//' &
      & Kernel not ready for open boundaries. Set evp_algorithm=standard_2d')
  endif
endif

PS: I know you're working on implementing open boundary facility to the 1D kernel, but until then an abort_ice is in place.

[mhrib]

Worth mentioning:
Kernel is bit-for-bit using very conservative compiler flags.

Open question: Could consider a single test using these flags?? Drawback is, that such a test is relying on an extra special CICE build.