LTRANS: Larval TRANSport Lagrangian model

[enorth]

We are pleased to announce that the Larval TRANSport Lagrangian (LTRANS) open source model has been released at the following website:

http://northweb.hpl.umces.edu/LTRANS.htm.

LTRANS is an off-line particle-tracking model that runs with stored predictions from ROMS. Although LTRANS was built to simulate oyster larvae, it can easily be adapted to simulate passive particles and other planktonic organisms. LTRANS is written in Fortran 90 and is designed to track the trajectories of particles in three dimensions. It includes a 4th order Runge-Kutta scheme for particle advection and a random displacement model for vertical turbulent particle motion. Reflective boundary conditions, larval behaviors, and settlement routines are also included.

A User's Guide, sample input data files, and visualization software are available at the LTRANS website. The User's Guide contains instructions for setting up and running LTRANS in both Linux and Windows environments.

We hope that you find it useful!

Regards,
Elizabeth North and Zachary Schlag
LTRANS Developers

[jmanning]

I'm not sure if this is the correct place to post comments on LTRANS.
I understand a separate discussion board might be formed eventually.

LTRANS holds a lot of promise and I look forward to getting started with it.

I have found that the main hurdle in getting started is to get the netcdf package in place.
For each new machine, I need to have the netcdf package properly installed.
LTRANS_compile.sh typically bombs at the line "USE netcdf" in the hydrodynamic_module.f90 code
because it can't find the compiled module file.

I first tried downloading the netcdf-4.0 binaries but, after getting a message that "This module file was not
generated by any release of this compiler", I then compiled netcdf from the source code according to the netcdf "INSTALL" instructions.

Now, I am getting LTRANS compile error messages like "Error in opening the compiled module file. Check INCLUDE paths."

While I continue to struggle, I was just wondering if anyone else had these troubles.

I am using intel ifort compiler on a Ubuntu Linux.

-JiM.

[kate]

ROMS itself requires you to have the netcdf.mod file produced by the same Fortran 90 version used to compile the model. It's a pain we all share, you are not alone. Doesn't it make you eager for parallel ROMS I/O via MPI-I/O and HDF5?

[enorth]

Hi Jim,
Are you using the LTRANS_compile.sh script? Perhaps your new NetCDF include files are installed in a directory other than /usr/local/include? If so, then the correct path to the NetCDF include files should be modified in the script.

Regards,
Elizabeth

[jmanning]

Elizabeth-

The trial-and-error solution was simple. When I listed "libnetcdf.a" on the ifort compile statement WITHOUT the -L or -l prefix, it compiled!!!

-JiM.

[harrison]

Perhaps this should be directed at Elizabeth directly, but I thought others might like to know as well:

I'm wondering which version of ROMS LTRANS was designed to interface with. I'm using the (almost current) Rutgers, which outputs variables s_w and s_rho as opposed to sc_w and sc_r which LTRANS is looking for. This is pretty trivial to change, but I'm wondering if there are other fun surprises in store for me.

Cheers,
Cheryl

[jmanning]

Hi Cheryl-

Yes, I had to make a few variable-name changes in "hydrodynamic_module.f90" like the ones you mentioned: renaming s_w and s_rho to sc_w and sc_r.

After getting around those problems, I now have particles "still out after 3rd flection" and "jumped over a v element".
I think these new problems (that cause the program to halt) might be due to my not setting the proper values for "dt" and "idt" in the LTRANS.inc file but, since I did not generate the model output myself, I'm not sure what to specify. Please let me know if you (or any other users) run into this same problem so we might find a solution together.

-JiM.

[harrison]

Hi Jim -

In LTRANS idt is the timestep for your LTRANS particles, so you get to decide what it is. The dt you'll have to figure out by looking at the ROMS netcdf history file, so you'll need some program that reads netcdf files, like ncview or snctools. You'll have to calculate dt from the ROMS timestep (also dt) and nHIS, the number of timesteps between history outputs in your ROMS file. LTRANS dt = nHIS * ROMS dt. It would be cool if LTANS could just read this in from the history file...but I'm currently resisting the temptation to change things for productivity's sake!

Cheers,
Cheryl

[bsteffen]

I'm trying to get LTRANS v.1 up and running on the Mac OS and using the gfortran compiler. After some troubleshooting, I finally got it to compile (I still don't have it running yet). In case others also plan to go this route, here are some of the problems I encountered and my solutions.

1. The LTRANS_compile.sh script never worked for me, even with my other fixes below, so I created a makefile to compile, which I will attach in case someone wants to use something similar. It uses the gfortran compiler, and sets netcdf paths for my machine, where netcdf is installed through fink in /sw . To use this makefile you'll have to rename from 'Makefile.txt' to 'Makefile'.

2. In hydrodynamics_module.f90: Change the three 'USE netcdf90' statements to 'USE netcdf'. This step is in the LTRANS User's Guide but I'll repeat it anyway.

3. In hydrodynamics_module.f90: Several lines in this file exceed gfortran's line-length limit. You can fix this by adding '&' continuation statements to break them into multiple lines, or use the -ffree-line-length-none compiler flag.

4. In boundary_module.f90: At lines 872 and 1143, change '==' to '.EQV.' It seems gfortran translates '==' as '.EQ.' only.
Important: For line 872: You must add parentheses in the compound IF statement when you make this change to avoid a bug. EX: if((ele(i,j)%form < 15) .AND. (ele(i,j)%used .EQV. .false.))then

--Ben

[harrison]

I also have a group of fixes to make LTRANS compatible with Penvin's ROMS_TOOLS (Currently it only works with Sea Grid), a fix in the time stepping loop to generate LTRANS output files on less than the ROMS output dt, as well as a couple others I probably can't remember right now. I also have a bunch of Matlab scripts to handle i/o and visualizations if anyone is interested, just email me and I can send them to you.

cheryl.harrison@noaa.gov

[hyy]

Dear all,

I am facing the following trouble when executing LTRANS in case of
using Penven's ROMSTOOLS (ROMS_AGRIF) outputs (history or average
file). Would you please teach me how to fix?;

After succeeding in compiling LTRANS,:

% ./LTRANS_compile.sh

I tried to execute "LTRANS.exe" .:

% ./LTRANS.exe

But the messages which should be displayed on screen has been stopped
(suspended) as follows;

****** LTRANS INITIALIZATION *******
read in particle locations 50
Particle n=5 Latitude= 42.00050 Longitude= 142.0000
Particle n=5 Depth= -10.0000000000000
read-in grid information
create elements
find adjacent elements
prepare boundary arrays

Using (Analysing?) above messages, I have found the position where
execution has been stopped (suspended): in "boundary_module.f90", do
loop part: "CREATE ISLAND BOUNDARIES" (line 887 to 961), where,
perhaps execution cannot clear "if(polydone)exit" (line 891).

Any suggestions are greatly appreciated. Thanks a lot in advance.

Best regards,

Hiroshi

[bsteffen]

Dear all,

I am facing the following trouble when executing LTRANS in case of
using Penven's ROMSTOOLS (ROMS_AGRIF) outputs (history or average
file). Would you please teach me how to fix?;

After succeeding in compiling LTRANS,:

% ./LTRANS_compile.sh

I tried to execute "LTRANS.exe" .:

% ./LTRANS.exe

But the messages which should be displayed on screen has been stopped
(suspended) as follows;

****** LTRANS INITIALIZATION *******
read in particle locations 50
Particle n=5 Latitude= 42.00050 Longitude= 142.0000
Particle n=5 Depth= -10.0000000000000
read-in grid information
create elements
find adjacent elements
prepare boundary arrays

Using (Analysing?) above messages, I have found the position where
execution has been stopped (suspended): in "boundary_module.f90", do
loop part: "CREATE ISLAND BOUNDARIES" (line 887 to 961), where,
perhaps execution cannot clear "if(polydone)exit" (line 891).

Any suggestions are greatly appreciated. Thanks a lot in advance.

Best regards,

Hiroshi

I had the very same problem until I fixed the following "bug" in boundary_module.f90

Line 872:
if(ele(i,j)%form < 15 .AND. ele(i,j)%used == .false.)then

is missing parentheses, and should be:

if(ele(i,j)%form < 15 .AND. (ele(i,j)%used .EQV. .false.))then

I'm not sure if this is causing your problem, but I'd give it a try.

[hyy]

Dear bsteffen,

> I had the very same problem until I fixed the following "bug" in boundary_module.f90
>
> Line 872:
> if(ele(i,j)%form < 15 .AND. ele(i,j)%used == .false.)then
>
> is missing parentheses, and should be:
>
> if(ele(i,j)%form < 15 .AND. (ele(i,j)%used .EQV. .false.))then
>
> I'm not sure if this is causing your problem, but I'd give it a try.

Thanks a lot for suggestion. But.. unfortunately, this debug failed to fix my problem...
The situation of problem is quite same as before; cannot clear "if(polydone)exit": line 891
of "boundary_module.f90".

Do you have another suggestions else to fix this problem? Thanks a lot in advance.

Best regards,

Hiroshi

[enorth]

Dear Hiroshi,
Zack Schlag has developed a new boundary maker which could resolve the problems you are having. He will respond to you when he gets back from vacation this week.

Regards,
Elizabeth North

[staalstrom]

Hi

I have just downloaded LTRANS v.1 and try to compile it with gcc.
I dont think I have any netcdf problems.
This are some of the errors I got.

Hydrodynamic
hydrodynamic_module.f90:12.126:
m,rho_nodes,u_nodes,v_nodes,max_rho_elements,max_u_elements,max_v_elements,rho_ 1
Error: Symbol 'rho_el' referenced at (1) not found in module 'param_mod'

hydrodynamic_module.f90:54.132:
ho_elements),u_ele_x(4,u_elements),u_ele_y(4,u_elements),v_ele_x(4,v_elemen
1
Error: Expected another dimension in array declaration at (1)

hydrodynamic_module.f90:374.28:

r_ele_x(i,j) = rx(RE(i,j))
1
Error: Unexpected STATEMENT FUNCTION statement at (1)

Best regards
Andre Staalstrom

[Yomi]

Dear all,

I am facing the following trouble when executing LTRANS in case of
using Penven's ROMSTOOLS (ROMS_AGRIF) outputs (history or average
file). Would you please teach me how to fix?;

After succeeding in compiling LTRANS,:

% ./LTRANS_compile.sh

I tried to execute "LTRANS.exe" .:

% ./LTRANS.exe

But the messages which should be displayed on screen has been stopped
(suspended) as follows;

****** LTRANS INITIALIZATION *******
read in particle locations 50
Particle n=5 Latitude= 42.00050 Longitude= 142.0000
Particle n=5 Depth= -10.0000000000000
read-in grid information
create elements
find adjacent elements
prepare boundary arrays

Using (Analysing?) above messages, I have found the position where
execution has been stopped (suspended): in "boundary_module.f90", do
loop part: "CREATE ISLAND BOUNDARIES" (line 887 to 961), where,
perhaps execution cannot clear "if(polydone)exit" (line 891).

Any suggestions are greatly appreciated. Thanks a lot in advance.

Best regards,

Hiroshi

Hi, hyy, did you tackle this problem? I ran into the same one today and couldnot fix it yet.
Do you have any suggestions for me now ?

[Yomi]

I successfully compiled LTRANS v2 using the test case. But when I ran LTRANS.exe, the screen printing stoped as follows without any error message. Can anyone please help me with this problem? Thanks in advance

*************** LTRANS INITIALIZATION **************
read in particle locations 608
Particle n=5 Latitude= 37.2761608977490 Longitude=
-76.2108564098010
Particle n=5 Depth= -0.250000000000000
Particle n=5 X= 5118201.07743135 Y= 921278.227723400
read-in grid information
create elements
find adjacent elements
- rho
- u
- v
prepare boundary arrays

[Yomi]

I successfully compiled LTRANS v2 using the test case. But when I ran LTRANS.exe, the screen printing stoped as follows without any error message. Can anyone please help me with this problem? Thanks in advance

*************** LTRANS INITIALIZATION **************
read in particle locations 608
Particle n=5 Latitude= 37.2761608977490 Longitude=
-76.2108564098010
Particle n=5 Depth= -0.250000000000000
Particle n=5 X= 5118201.07743135 Y= 921278.227723400
read-in grid information
create elements
find adjacent elements
- rho
- u
- v
prepare boundary arrays

The above problem I met occured during the use of Linux and ifort. Then I tried to run the test case under Windows and VF, and I got the following result. How to tackle this problem ? Thanks very much.

[m.hadfield]

Rebuild with bounds-checking enabled, maybe try a few different compilers, to establish the statement and array reference that triggers the bounds violation. Then use your preferred debugging technique (mine is WRITE statements inserted into the code) to establish why this is happening.

This being larval tracking code, you might suspect a larva has moved outside the domain. But that's just a guess.

[simion1232006]

Dear all,

I tried to use the LTRANs version 2 for my ROMS application. It works great if I release the particles on the surface. However, I found something weird of the model outputs if I released the particle in the subsurface layer. In the attached figure, the depth of the first particle moves immediately from -40 m to -1 m at surface. I tried many different setup and gain the same results. Does anyone have the similar experience here. Please help me out here.

[m.hadfield]

It looks like a bit of digging into the particle initialisation code might not go amiss!

[simion1232006]

I added the test command because I found something wrong in the outputs. The interesting thing is I solved the problem by adding another command (see attachments).

[simion1232006]

I don't know exactly what happens here. Seemingly, adding commands to print out variables on the screen can totally change the model results. The original code, in my experience, gave me unrealistic vertical motion of particles. If somebody has the same issue, I hope my post would help.

[m.hadfield]

I trust you are running with bound checking, as I suggested a few posts ago.

When adding a line of code changes the results, it usually means you are doing something a bit dodgy, and writing or reading outside the bounds of an array is definitely dodgy.

[simion1232006]

Thanks for your reply. The good side is it actually solved my problem. The trajectories of these particles look pretty smooth and realistic. So without further debugging of the codes, I would just use it as a temporary solution.

[kate]

Actually, adding a write statement and having it change the results smells like an optimizer bug. You can pursue this by turning off optimization (and adding bounds checking) to see what you get then.

[csherwood]

All,
We ran into some compiler-specific issues using LTRANS this winter, and they were largely resolved by Elizabeth North and Ian Mitchell. I will forward the link to this thread to them and suggest they respond, but in the meantime, contact them for the latest guidance:
Ian Mitchell <imitchell@hpl.umces.edu> Elizabeth North <enorth@umces.edu>

[simion1232006]

Thanks, Kate. I will have a look. There is another issue coming with the code. It is not a bug but very annoying(see the figure). somehow the particle jump over something and the model stop to run. I mean is there a way to turn this thing off or just let the particle stop if it passed through certain elements.

[alanberry]

Hi simion1232006,

I have been using LTRANS for a while for a number of different purposes and have trouble-shooted (shot?) a lot of issues.
I suggest that you decrease the idt value, internal particle tracking time step (s), to prevent the particle skipping through a computational cell.
That should resolve the issue.

Another option (though perhaps not valid for this case) is to change ErrorFlag from 0 (default) to 1,2, or 3 to stop tracking the offending particle if it moves out of bounds 'illegaly'.

Regards,
Alan.

[ian]

Hello All,

As Chris Sherwood mentioned, we have been working on polishing LTRANS, and fixed some compiler specific issues. Please checkout the LTRANS webpage for the code, and information on the updates. Please report any issues you encounter. Should they be compiler specific, in the meantime I can recommend using the same compiler we use: ifort 12.1.3.293

Ian

[LRasmuson]

Hi All,

I was hoping to modify the behavior module to have a vertical migration based on the age (time since day of birth) for each particle. However I know that the variable 'P_age' in behavior_module.f90 is just seconds since the model started. I looked at the manual and I see that the date of birth of each particle is calculated in the hydrodynamic_module.f90. I am not much of a fortraner so I am not quite sure how I would alter the code in the behavior_module.f90 to have access to the dob variable from the hydrodynamic module. Any advice would be greatly appreciated.

Leif

[alanberry]

Hi Leif,

I was hoping to modify the behavior module to have a vertical migration based on the age (time since day of birth) for each particle. However I know that the variable 'P_age' in behavior_module.f90 is just seconds since the model started.

par(n,pAge), or P_age, is the time (seconds) since birth of the particle (ie, when the particle enters the simulation).

I looked at the manual and I see that the date of birth of each particle is calculated in the hydrodynamic_module.f90

par(n,pDOB) is the time of birth (seconds) of the particle from when the model starts and is read in from the Initial_particle_locations.csv on line 256-258 of LTRANS.f90

As the model progresses in time, if par(n,pDOB) has been reached then par(n,pAge) is incremented, if not P_age remains at 0.0 and the program cycles to the next particle. (lines 790 - 798 in LTRANS.f90)

So if you want to "modify the behavior module to have a vertical migration based on the age (time since day of birth) for each particle", you do actually need to be using the 'P_age' value already passed into subroutine behave in behaviour_module.f90. The P_age value can be converted from seconds since the particle was born to days by dividing P_age by (3600*24).

If you need any other assistance please drop me a line.

Alan.

[LRasmuson]

Thank you very much for your response this helped me a lot.

Leif

[ammachado]

Hello!
Does anyone know if LTRANS is still being used, and who's in charge of developing it?
Thank you!
Ana

[csherwood]

As far as I know, LTRANS is still a good approach for post-processing ROMS output to track dynamic particles.
The original developer, and probably the best contact, is Elizabeth North at enorth@umces.edu.
See her web page at: http://www.umces.edu/hpl/people/enorth

Regards, Chris

[klyons]

Another option is Ichthyop, a java-based Lagrangian tool developed by Christian Mullon and Philippe Verley in France (http://www.ichthyop.org/). This tool handles ROMS files by default and we have used it for numerous projects. It is very simple to use and is open source.

Kieran

[hodamahyar]

Hi, yomi , did you solve your problem? i have the same problem as yours. how did you fix your problem? please look at the picture i attached.

[wolfegg]

Hi all,
I got a weird ErrorLog.txt when I am using the LTRANSv2b to simulate the pathway of passive floats.


Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over v element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 166 jumped over u element after ********** seconds

What does it mean that the particle jumped over u (or v or rho) element? And why do I get "**********" seconds instead of an exact number? '
(My LTRANS.data file is attached.)


Thanks,
Dan

[wolfegg]

Hi all,
I got a weird ErrorLog.txt when I am using the LTRANSv2b to simulate the pathway of passive floats.


Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over u element after ********** seconds
Particle 228 jumped over v element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 258 jumped over u element after ********** seconds
Particle 166 jumped over u element after ********** seconds

What does it mean that the particle jumped over u (or v or rho) element? And why do I get "**********" seconds instead of an exact number? '
(My LTRANS.data file is attached.)


Thanks,
Dan

Further, I found that most of my floats did not move at all. I released 1612 floats to my domain. Does the LTRANSvb2 have a maximum capability in terms of float quantity?


Thanks,
Dan

[emilyln]

Hi Dan,

I don't know why LTRANS reports this error the way that it does, but I've encountered this error when I have particles initialized on land, at depths below the seafloor grid, or above the sea surface (i.e. particles within the domain of my model but not actually in bounds). I'm not sure what the upper limit is for the number of floats, but I've successfully run >3500, so I don't think that's your problem. I would start troubleshooting by double-checking the locations of these flagged particles to make sure they are in water in your domain. When initializing particles near the seafloor or sea surface, I usually give them a few extra meters wiggle room, just in case.

Good luck!
Emily

[tbk14]

I've been very impressed with the LTRANS code, and it has been a pleasure to customize for my particular needs. But I do have a question that someone with more experience may be able to answer. I run simulations with a large number of particles on a large server. When dealing with <1e5 particles I see the usual scaling with time (2x particles takes about 2 times longer).

When I use more than ~1e5 particles, LTRANS seems to stall. The thread continues to run at 100% but there is no more terminal output and it never moves passed this:

prepare boundary arrays
initialize behavior
finding each particle's initial element
Model_005.nc
Time to initialize model = 21.670 seconds.

****** BEGIN ITERATIONS *******

What is causing this and is there a workaround? The server I'm on has plenty of ram, running LTRANSv2, typical ifort compilation, nothing unusual. The thread uses a couple 100 MB of ram according to htop.