{"action":"closed","issue":{"url":"https://api.github.com/repos/NOAA-GFDL/MOM6/issues/203","labels_url":"https://api.github.com/repos/NOAA-GFDL/MOM6/issues/203/labels{/name}","comments_url":"https://api.github.com/repos/NOAA-GFDL/MOM6/issues/203/comments","events_url":"https://api.github.com/repos/NOAA-GFDL/MOM6/issues/203/events","html_url":"https://github.com/NOAA-GFDL/MOM6/issues/203","id":95337974,"number":203,"title":"MEKE%Kh not initialised on the edges ","user":{"login":"nicjhan","id":921706,"avatar_url":"https://avatars.githubusercontent.com/u/921706?v=3","gravatar_id":"","url":"https://api.github.com/users/nicjhan","html_url":"https://github.com/nicjhan","followers_url":"https://api.github.com/users/nicjhan/followers","following_url":"https://api.github.com/users/nicjhan/following{/other_user}","gists_url":"https://api.github.com/users/nicjhan/gists{/gist_id}","starred_url":"https://api.github.com/users/nicjhan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nicjhan/subscriptions","organizations_url":"https://api.github.com/users/nicjhan/orgs","repos_url":"https://api.github.com/users/nicjhan/repos","events_url":"https://api.github.com/users/nicjhan/events{/privacy}","received_events_url":"https://api.github.com/users/nicjhan/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-07-16T03:10:50Z","updated_at":"2015-08-07T19:29:16Z","closed_at":"2015-08-07T19:29:16Z","body":"various MEKE% variables may be garbage at the edges ... e.g. in parameterizations/lateral/MOM_MEKE.F90:1190 MEKE%Kh is initialised on range j=js-1, je+1, i=is-1,ie+1 using barotrFac2, however this is only defined from js-je, is-ie. The same goes for bottomFac2 and variables initialised using this. .... actually it might only be a problem with MEKE%Kh\r\n\r\n@adcroft said:\r\n\r\nConcerning MEKE: is the issue that the loops at L439, L446, L452 do not need to be wide since the is a halo update at L457?\r\nIf reducing those loop ranges to the computational domain works under valgrind then I think the model solutions will be unchanged (because of the halo update).\r\n\r\nJust realized that LmixScale is used at L465 in a wider loop so that needs to be calculated wide as you suggested earlier...\r\n\r\nSomething like this...\r\n\r\n```\r\n% git diff -U0 src/parameterizations/lateral/MOM_MEKE.F90\r\ndiff --git a/src/parameterizations/lateral/MOM_MEKE.F90 b/src/parameterizations/lateral/MOM_MEKE.F90\r\nindex 562c22f..0ff7360 100644\r\n--- a/src/parameterizations/lateral/MOM_MEKE.F90\r\n+++ b/src/parameterizations/lateral/MOM_MEKE.F90\r\n@@ -439 +439 @@ subroutine step_forward_MEKE(MEKE, h, SN_u, SN_v, visc, dt, G, CS)\r\n-          do j=js-1,je+1 ; do i=is-1,ie+1\r\n+          do j=js,je ; do i=is,ie\r\n@@ -446 +446 @@ subroutine step_forward_MEKE(MEKE, h, SN_u, SN_v, visc, dt, G, CS)\r\n-          do j=js-1,je+1 ; do i=is-1,ie+1\r\n+          do j=js,je ; do i=is,ie\r\n@@ -452 +452 @@ subroutine step_forward_MEKE(MEKE, h, SN_u, SN_v, visc, dt, G, CS)\r\n-        do j=js-1,je+1 ; do i=is-1,ie+1\r\n+        do j=js,je ; do i=is,ie\r\n@@ -636 +636 @@ subroutine MEKE_lengthScales(CS, MEKE, G, SN_u, SN_v, &\r\n-  do j=js,je ; do i=is,ie\r\n+  do j=js-1,je+1 ; do i=is-1,ie+1\r\n```\r\n"}}