Inline/Offline passive drifters

[rgrumbine]

Preface/History

The purpose is to continue the operational support in the NWS of sea ice drift guidance, begun in 1978 by Ed O'Lenic and updated/extended 1997-2023 by Robert Grumbine.

These models take in a list of points (latitude-longitude locations) and then provide forecasters guidance on where a surface drifter will be in 1-16 days in terms of drift distance and direction. These were all 'drift rule' models, ice drift being some simple function of atmospheric conditions (only)

Design Of the New Sea Ice Drift Model/Module

The intent here is to preserve the old capabilities while moving to using a sea ice model for the ice motions.

The new code should:

• Run offline (reading in model output from, e.g. CICE, RTOFS, UFS-GFS, ...)
• Run inline (called as subroutines, under control from, e.g., namelist control file)
• • with minimal requirements on calling program and sample stubs available
• • with minimal effect on run time for drifter counts up to tens of thousands
• Produce .netcdf output, CF compliant
• Be amenable to multiprocessing (particularly for inline use)
• • e.g. if a drifter crosses a domain boundary, it should either cleanly hand off, or positions set to unknown
• • I/O must proceed ok whether 1 or 1000 cores

[rgrumbine]

A clearer description of my thought for where to put the code for the Lagrangean tracker:

The offline option suggests to me that the code belongs in tools (configuration/tools/), say:

• configuration/tools/tracker
• • shared
• • offline
• • inline stubs (code required for a generic user on generic model to inline the tracker in their system, CICE or otherwise -- I'll inline them as options in the main code)
• • NWS operations-required directories (fix/parm/ush/ecf/...)

[eclare108213]

@rgrumbine
Is there a github (or other) repository where the existing code is, and/or where your new code is stored? Alternatively, could we see a bit more detail here in this issue about what this code looks like? I'm assuming that the "shared" directory would include a basic particle tracking code; offline would contain an independent driver for the shared code that reads in data files; inline I'm not sure about -- if the capability is to be set up and available in CICE, maybe we don't need a more generic form? What are the NWS directories for?

What we need to discuss here in this issue is (1) what the interface with CICE would need, e.g. I/O; (2) performance considerations, e.g. parallelization strategies; (3) how much of this tool we would be able to support, e.g. those NWS directories are probably not something we could test and maintain, although we could house them similarly to the various coupling caps. (Other topics will likely come up too.) So being able to look at the actual code or a mocked-up pseudo-code would be helpful.

[rgrumbine]

Currently in the dev/desk branch of my work github -- https://github.com/rgrumbine/newdrift/tree/dev/desk

Shared and offline are as you expected.

Inline ... my thought is a) inline it to CICE as you expect, but also b) have code stubs for any who might want to inline the drifter in to their sea ice model, CICE or not

Some NWS directories (ush, fix, ...) include fixed files of general use, such as a demonstration .nc file or two for drifters, and tools to read in IABP or SIDFEx tables of buoys and produce a netcdf that can be used as input. There are also some that are very specific to NWS (version, scripts, jobs) -- needed if NWS chooses to run this in the operational workflow in offline mode. (see footnote)

(1) I'm working in the vein of adding a namelist section to ice_in. It's short. The interfacing inside CICE code should be solely to read these in, decide whether drifters will be used, read the drifter input file, call the drifter position update every so often (input parameter), write out the positions every so often (ditto), and close the output file(s) at the end of the run.

(2) Computationally, it is, so far at least, fast -- trivial compared to the challenges of computing a velocity field. So I'm getting hundreds of thousands of drifter*steps per second on a single processor.

(3) I'll suggest the consortium support only the 'shared' code and the bits that I add to the main body of CICE code. The rest, especially those NWS-specific directories, treat like the caps.

footnote:
Ordinarily, I agree, something unique to the choices of a particular user should simply be maintained elsewhere than the general repository. The specialized NWS directories like 'jobs', 'ecf', ... are not much use outside of NWS operations. This is unlike, say, the cesm cap, which is useful outside of NCAR.

The thing is, it is by now approximately impossible to get something for sea ice added to NWS operations in its own right. Something which is part of the CICE repository is doable. So I beg an indulgence.