New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
#2494 (ICB: cleaning icbutl interpolation routines) – NEMO

Opened 4 years ago

Closed 4 years ago

#2494 closed Bug (fixed)

ICB: cleaning icbutl interpolation routines

Reported by: mathiot Owned by: mathiot
Priority: low Milestone:
Component: ICB Version: trunk
Severity: minor Keywords: ICB,
Cc: nicolas.jourdain@…

Description

BE CAREFUL !!! Due to dynamic behaviour of this ticket creation page, it is highly recommend to set first all other fields before writing the ticket description below.
If you have lost your draft after an unwanted reload, you can click on the link 'Restore Form' in the contextual menu upper right to recover it.

Context

  • icbutl contains 4 routines for interpolation:
    • icb_utl_bilin_h to manage array with extra halo
    • icb_utl_bilin as _h but with the extra halo
    • icb_utl_bilin_x as icb_utl_bilin but for longitude only
    • icb_utl_bilin_e for scale factor

All of these subroutines have the same structure:

  • Firstly, we find the variable ii and ij (indices) for T point or T/U/V/F point depending of the variables and first estimates of interpolation weights zi,zj
  • Then, we apply a sanity check on the bound very similar for all 4 subroutines (it should never go in otherwise it break reproducibility)
  • Finally we compute the weights depending on the case (mask needed, longitude case, scale factor, normal case)

There are, per RK4 step, about 15 calls of icb_utl_bilin* subroutines gather in icb_utl_interp and the first 2 steps (positions+pre weights and sanity checks) are only dependent of the position and the target point T/U/V/F (which don’t change between the various calls).

Suggestion for simplification

  • Get rid of icb_utl_bilin and icb_utl_bilin_x by using icb_utl_bilin_h
    • Integrate in icb_utl_bilin_h an option to deal with longitude (Similar to how we deals with coastline in the interpolation)
    • Create a lon and lat array with extra halo
  • Compute ii,ij and zi,zj for each point T/U/V/F before call all the interpolation routine icb_utl_bilin_h
    • Move the corresponding bloc from icb_utl_bilin_h and icb_ult_bilin_e into a new subroutine icb_utl_pos
    • Move the sanity check on position (on land ?, out bound ?) into the new subroutine icb_utl_pos. Maybe run this test if a new flag ln_icbdbg = .TRUE. as NEMO should never go trough.
  • Add after the call the icb_lnk (maybe need to move it into icb_dyn instead of in the middle of icb_stp), a check if all the icb are inside the inner domain (under debug flag).

Why doing this ?

  • Make icb_utl by limiting the number of interpolation routine.
  • Make icb_utl_interp computing position and pre weight only once per T/U/V/F point (ie 4 times instead of about 15 times).
  • Skip debug test (icb inside the inner domain, …) only if debug flag is true.
  • Nacho work available in a tarballs (#1900) adds a lot of icb_utl_bilin_h calls (1 per level between the surface and the deepest level affected by an iceberg (could be at a depth of 250m). So making icb_utl_bilin simpler and faster could be useful now and much more useful once Nacho work included.

Testing

  • We should have an idealized test case with a lot of icebergs in it, running for long time (offline iceberg ?). Nothing in mind yet, I have to see if something already exist in the literature.
  • These changes should not changes NEMO results (identical run.stat).

Commit History (4)

ChangesetAuthorTimeChangeLog
13276mathiot2020-07-09T09:47:18+02:00

ticket #2494 and #2375: wrong point type inn lbc_lnk_icb for umask_e and vmask_e (see ticket #2492)

13273mathiot2020-07-08T18:06:39+02:00

ticket #2494 and #2375: remove useless lbclnk mentioned in ticket #2375

13265mathiot2020-07-08T13:34:28+02:00

ticket #2494 and #2375: ticket #2494 changes and part of ticket #2375 (lbc_icb_lnk on extended variable at T point removed), ff_e initialisation and lbc_lnk move in the icbini.F90; tests on possible useless lbc_lnk in icbclv not yet done

13243mathiot2020-07-03T17:42:57+02:00

ticket #2494 and #2375: creation branch

Change History (5)

comment:1 Changed 4 years ago by mathiot

In 13243:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:2 Changed 4 years ago by mathiot

In 13265:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:3 Changed 4 years ago by mathiot

In 13273:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:4 Changed 4 years ago by mathiot

In 13276:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:5 Changed 4 years ago by mathiot

  • Resolution set to fixed
  • Status changed from new to closed
  • Type changed from Feature request to Bug

included in the trunk as part of 2020 merge (revision r14030)

Note: See TracTickets for help on using tickets.