[MITgcm-support] Particle tracking with MITgcm (flt package)

[Andrea Cimatoribus]

Thanks a lot for the reply! I will also certainly start looking at the 
python repo as soon as I start getting my hands dirty with the flt package.
Cheers,
Andrea

Andrea Cimatoribus
postdoctoral researcher
EPFL ENAC IIE ECOL
https://people.epfl.ch/andrea.cimatoribus

On 14/10/16 15:44, Ryan Abernathey wrote:
> Andrea, you are right that the MITgcm flt package is not well
> documented. However, it IS very capable and is almost certainly more
> efficient / scalable than offline codes, since it parallelizes along
> with the rest of MITgcm.
>
>
>     THE QUESTIONS to the MITgcm masters:
>     - does anyone know if flt can actually deal with curvilinear grids
>     and 3D advection (if I understand right, the answer to the latter is
>     yes)?
>
>
> I have used it with cartesian and sphericalpolar grids. I to NOT know if
> it works correctly with llc / exch2 / etc. Maybe Jean Michel can
> enlighten us.
>
> It has options for the floats to be truly 3D, isobaric, or profiling. So
> yes, 3D advection works.
>
>
>     - Is there any other verification available? I cannot find any
>     data.flt other than the one under flt_example.
>
>
> Not that I know of. Here is another example:
>
>  &FLT_NML
> # 1 day
>  flt_int_traj = 86400.,
>  flt_int_prof =  0.0,
>  flt_noise    = 0.0,
>  flt_selectTrajOutp = 3,
>  flt_file     = 'flt_ini_pos_hex.epac.32deg.bin',
>  &
>
> It is pretty simple. A lot of the float behavior is determined in the
> input file, rather than data.flt.
>
>
>     - What about advection schemes? README.flt states that second-order
>     Runge-Kutta is the only option, but I was wandering if that is still
>     the case and whether that is important (I am only starting to
>     scratch the surface of Lagrangian methods).
>
>
> Runge-Kutta 4th order was implemented by Andreas Klocker, and this is
> the default. I believe this is considered state of the art.
>
>
>     - Can flt actually interface to the diagnostic and mnc packages? A
>     grep in its directory returns nothing, but my understanding of the
>     workings of the code is certainly limited at best.
>
>
> No. The float output is quite primitive and is on a tile-by-tile basis.
> This makes it hard to parse and aggregate the float data. To deal with
> this, we have created a python package called floater which parses and
> translates the float data into other more convenient storage formats:
> https://github.com/rabernat/floater
> There is also some basic capability for writing the float input files.
> There is still lots of room for improvement here, but it should be
> easier than starting from scratch. I welcome issue reports and pull
> requests on this repository.
>
>
>     Thank you very much,
>     Andrea
>
>     --
>     Andrea Cimatoribus
>     postdoctoral researcher
>     EPFL ENAC IIE ECOL
>     https://people.epfl.ch/andrea.cimatoribus
>     <https://people.epfl.ch/andrea.cimatoribus>
>
>     _______________________________________________
>     MITgcm-support mailing list
>     MITgcm-support at mitgcm.org <mailto:MITgcm-support at mitgcm.org>
>     http://mitgcm.org/mailman/listinfo/mitgcm-support
>     <http://mitgcm.org/mailman/listinfo/mitgcm-support>
>
>
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>