Question about particle tracking

[Yomi]

Hello everyone

I want to use particle tracking method to do a long time period research, but the computation is time-consuming. So I want to run the model without float module and save the circulation related variables once an hour in a file, and then drive the float module with the saved variables. Is it possible? And How to run particle tracking part only?

Thank you!

[kate]

Yes, it's possible and there's more than one way to do it. The option some of us are exploring now is tracmass.

[johnluick]

Is anyone aware of any studies that compare this "offline" tracking approach, with letting ROMS do the tracking? Assuming ROMS updates the positions at each timestep, the two results must diverge noticeably at some point. For example in shallow water with wind.

Another freely available program that can be used for this is LTRANS. A colleague of mine has parallelized it using mpich2. It is possible that he could be induced to provide it.

By the way even hourly files, with the minimum number of variables for tracking, can get pretty massive. So there can be a trade-off between long runtimes and big unwieldy files.

[liyizhen837]

John, can you tell me your colleague parallel ltransv2 or v1. It would be interesting to see how fast it can speed up the computation!

[m.hadfield]

Hi Kate

Can you comment on the relationship between the Github link you gave

https://github.com/TRACMASS/

and this one

http://tracmass.org/

which has an SVN repository

http://svn.tracmass.org/trunk

Mark

[johnluick]

liyizhen:
LTRANS v1
It speeds it up a LOT though the testing was not thorough. A normal run formerly took around 30 hours. With mpich it took an hour and a half or so.

[johnluick]

I meant to say: 18 cpus

[liyizhen837]

liyizhen:
LTRANS v1
It speeds it up a LOT though the testing was not thorough. A normal run formerly took around 30 hours. With mpich it took an hour and a half or so.

John, that sounds a great speeudup! Please let me know when your friend is willing to share the code. We've been using LTRANS for our research for several years. We might also could share some experience on these. Thanks so much!

[rduran]

Is anyone aware of any studies that compare this "offline" tracking approach, with letting ROMS do the tracking? Assuming ROMS updates the positions at each timestep, the two results must diverge noticeably at some point. For example in shallow water with wind.

Rivas and Samelson (2011) did some offline tracking (back in time) and I verified their results forward and backward in time with a couple of different Lagrangian online methods. Results were consistent but this is by no means a thorough study on the topic.

As you mention, each case may be different. For starters, the more the flow is steady the more your results will look alike, it depends on time variability. Then it also depends on correlations of trajectories and velocities (think waves). And these two points should be enough to prove that each application should be checked for independently because it is actually a very complex problem. At the end what you are looking for is: how often do I need an instantaneous velocity to reproduce the best approximation (i.e. what the model sees). And then of course you have to question what the model sees!

good thing we get paid for this.

R

[Yomi]

Is anyone aware of any studies that compare this "offline" tracking approach, with letting ROMS do the tracking? Assuming ROMS updates the positions at each timestep, the two results must diverge noticeably at some point. For example in shallow water with wind.

Another freely available program that can be used for this is LTRANS. A colleague of mine has parallelized it using mpich2. It is possible that he could be induced to provide it.

By the way even hourly files, with the minimum number of variables for tracking, can get pretty massive. So there can be a trade-off between long runtimes and big unwieldy files.

Hi, John, does LTRANS use the same particle tracking algorithm as that in ROMS ?

[kate]

Hi Kate

Can you comment on the relationship between the Github link you gave

https://github.com/TRACMASS/

and this one

http://tracmass.org/

which has an SVN repository

http://svn.tracmass.org/trunk

Mark

They are the same package, possibly different versions. Bror Jonsson is updating it and the related pytraj on github so he would be the one to ask.

[m.hadfield]

Thanks.

[johnluick]

rduran, thanks very much for your comments. I have brought this up before on the forum but am still wondering about it. It would be handy if your test was something that could be easily run for any new application any time one wanted to decide whether to use inline or offline tracking.

liyizhen: my colleague Charles is happy to share his code though apparently only the advection parts (not settlement modules) have been well-tested. charles.james@sa.gov.au

yomi: that is a good question. Somehow it seems unlikely.

[liyizhen837]

Thanks John, and will email James for it.

[Yomi]

Thanks

[csherwood]

I have used LTRANS with ROMS, and worked with E. North as she developed / applied LTRANS 2 to ROMS runs.

The benefits of LTRANS are that it has alot of options for particle behavior, and it is well tested and pretty easy to use.

The downside is that the UMaryland version it is not (yet) parallelized, and it does not do the calculations in the native grid coordinates, but instead transforms everything using a conformal projection before doing the advection.

I don't think any post-processing particle tracker can be expected to produce the exact same solution as the ROMS calculations, unless run for every ROMS time step...but the advantages come in being able to change behavior, diffusivity, location of particle sources, etc. and not re-do the hydrodynamic calcs.

I recommend trying LTRANS...if it is not fast enough, then encourage E. North and her team to speed it up.

[lanerolle]

One of the (unfortunate) things to keep in mind when doing off-line particle tracking is that we have to do a sensitivity study where we examine the sensitivity of the particle paths to the the frequency at which the velocity fields are saved in the *_his.nc or *_avg.nc ROMS output files. Hence, for a region with relatively mild tides such as the Gulf of Mexico, using 2-hourly saved velocity fields may be sufficient to generate reliable particle tracks whereas in Cook Inlet, AK or Gulf of Maine, where tides are intense, we may need 15-minutely saved velocities to get sufficiently accurate particle tracks. This is not an issue when using the ROMS internal particle tracking routines where the particles are tracked every single time-step.

[rduran]

in my Experience every six hours worked ok, it depend on the timescales u are interested in.

I don't think any post-processing particle tracker can be expected to produce the exact same solution as the ROMS calculations, unless run for every ROMS time step...but the advantages come in being able to change behavior, diffusivity, location of particle sources, etc. and not re-do the hydrodynamic calcs.

that I believe to be more or less true, unless the flow is steady ...

lanerolle I agree with, each flow has its frequency with which you can resolve its trajectories, and here notice the plural, we Should be thinking bulk properties not particular trajectories. Particular trajectories are too chaotic anyway.