Question about floats

[evan]

Hi

I am trying to introduce a cluster of floats into my model. I am not sure how the Fdx, Fdy, Fdz parameters in floats.in work? Can somebody tell me what range of values might be used for these parameters, and what sort of clusters will result?

On the last line of floats.in a routine called 'init_floats.F´is mentioned - I don't have this routine in ROMS 2, though I see it was used in ROMS 1. Has this now been omitted from ROMS 2?

Many thanks

Evan

[OcGaBy]

I want to add some floats to my application. What else than declared them in floats.in do I need to do??

Thanks and Regards
GaBy

[kate]

You need to #defined FLOATS in cppdefs.h. The code will then read floats.in and create the corresponding netcdf output file.

[OcGaBy]

Yea!
It does it, but the resulting NetCDF ocean_flt.nc, doesn't have the trajectories of the floats... Xgrid, Ygrid, Zgrid, and lon y lat are just series of zeros...

I also try the LAKE_SIGNELL application with the same result...

I can't run the FLT_TEST, it does complie but when I try to run it I get:

Code: Select all

[gaby@localhost roms-2.2]$ ./oceanS <External> Test
forrtl: Is a directory
forrtl: severe (30): open failure, unit 5, file /home/gaby/Desktop/roms-2.2/
Image              PC        Routine            Line        Source
oceanS             08130B04  Unknown               Unknown  Unknown
oceanS             0812F29D  Unknown               Unknown  Unknown
oceanS             0810867E  Unknown               Unknown  Unknown
oceanS             080E1692  Unknown               Unknown  Unknown
oceanS             080E64FE  Unknown               Unknown  Unknown
oceanS             08083F89  Unknown               Unknown  Unknown
oceanS             08049DFD  Unknown               Unknown  Unknown
oceanS             08049A4E  Unknown               Unknown  Unknown
oceanS             080499D6  Unknown               Unknown  Unknown
libc.so.6          00A34D7F  Unknown               Unknown  Unknown
oceanS             08049911  Unknown               Unknown  Unknown

same thing with 2 & 3D test....
Can you tell me whats wrong?

Thanks for your quick replay!
GaBy

[kate]

[gaby@localhost roms-2.2]$ ./oceanS <External> Test
forrtl: Is a directory

It is telling you what the problem is: the input to ROMS should be a file, not a directory. Run it like:

Code: Select all

./oceanS <External> output

Code: Select all

./oceanS <External_ocean_floats2d_in> output

or use whatever input file makes sense. This is the case for serial ROMS and OpenMP ROMS, but MPI ROMS needs to be run like:

Code: Select all

./oceanM External/ocean_floats2d.in > output

Actually, I typed what I wanted to type for the serial case and it isn't showing up the way I meant it to - perhaps that happened elsewhere too! The real input file is External/ocean_floats2d.in (or your file of choice).

[OcGaBy]

I think I use the runing instruction rigth:
./oceanS <External> output

But I didn't got the trjectories even when I get an application with floats to run, and the corresponding output NetCDEF...

Cheers
GaBy

[OcGaBy]

There is a type issue with the Forum...

What I wanted to say is that I did use External/float_3dtest.in as input file...



GaBy

[kate]

Did you look through the ROMS output to see if there is any mention of floats? Did you tell ROMS to output to the floats file every step or five? So you say ROMS ran without any floats output being nonzero? But you do get floats?

[OcGaBy]

Yes, I get the floats output NetCDF, with the number of floats I chose. I'm saving the positions every time step, but all of them are zero.

[kate]

Hmmm, I tried the 3d FLT_TEST case and I get values of 1e+35 for most everything. Clearly something isn't right here, but I don't have time to debug this just now.

[OcGaBy]

Thanks anyway... hope some day you get it to work... please keep me inform.

Gaby

[m.hadfield]

I'm not sure if my last attempt to post this succeeded. Apologies for duplicates, if any.

FLT_TEST works for me (I just checked, with a couple of recent versions of ROMS.) The floats are release at 0.1 days; before that you get the missing-float value, which I think is 1.E35.

Generally if you get a float position of 1.E35 the first thing to check is whether it's been released yet.

[OcGaBy]

I run my appliction for 10 days, I declare my floats to be released after one day. I got a position's series of 10 days for each float but all the values are 1.e35.

How can I check if the floats are actually released?

Thanks

GaBy

[m.hadfield]

First look closely at all the values in your floats file. Are you releasing the floats inside the domain? (When floats go outside the domain, their position is reported as 1.E35.) Are your initial float locations consistent with your coordinate type C (the second entry in each float-position line)?

If you don't see any problems there, you're going to have to do it the slow way. Run your code in debugging mode and work through the relevant routines, checking the float status at the critical locations. Some people do this with a debugger, but I use print statements in the code (the .f90 files), rebuild and rerun, etc. You *will* eventually find the problem this way and you *will* be surprised by how simple it is.

Some debugging tips: You might want to modify the floats file to cause the floats to be released earlier and/or reduce the number, or to find some settings that *do* work before you work out why your original ones *don't*. Debugging in serial, single-tile mode, where possible, simplifies things. Oh and the usual one: enable bounds-checking!

[OcGaBy]

I was hoping that the correction release for small bugs was going to fix my problems with floats... since a correction to grid_coords.F is mentioned...

(*)grid_coords.F: Corrected a bug in the computation of the grid coordinates for floats and stations from (lon,lat) values. This problem is only found at the tile boundaries.

But it still doesn't work to me...

If somebody already fix it, please let me know.

Cheers
GaBy

[m.hadfield]

I suspect the problem is with your input data rather than a model bug. If you're waiting for someone else to fix it, then you might be in for a long wait.

[OcGaBy]

I figure it out what was the problem.

Everithing is ok with the model. My problem was reading the netCDF files. I'm reading them in Matlab using netCDF_toolbox, on Windows. As the first values are 1e35, before the floats are released, matlab show just 1e35 and 0e35 instead of the real values. So first you need to clear the large values with something like:

Code: Select all

% clear large values... 
ind = find(Xgrid(:,1)==Xgrid(1,1)); 
Xgrid(ind,:) = []; 
Ygrid(ind,:) = []; 

and then you can see the real values...

I guess the same thing happen to you Kate... so just in case it happen to somebody else.

Cheers
GaBy

[m.hadfield]

I'm glad you found the problem.

It's surprisingly easy to make mistakes like this. (If I had $0.01 for every time I've done it, I'd have ... well, a dollar or too anyway.) The best solution is to have independent ways of scanning through your data files. The ncdump utility is useful for this. It's particularly good at giving you a view of the overall structure of your file, but it can dump data too. Another useful set of tools is NCO:

http://nco.sourceforge.net/

[rouf]

I am new in ROMS. I tried to run the lake_signell test case.
After the compilation, when i tried to run, it gives ocean_his.nc, ocean_avg.nc and ocean_flt.nc but ocean_flt.nc is completely empty. Along with these I received following error.


MuhammadAbdurRouf@ROUF /roms/test/lake_signell
$ ./oceanS < ocean_lake_signell.in> lake_signellout.dat
At line 282 of file def_floats.f90
Traceback: not available, compile with -ftrace=frame or -ftrace=full
Fortran runtime error: Expected CHARACTER for item 1 in formatted transfer, got
REAL. If you want to make character descriptors typeless, compile with -fsloppy
-char
(6x,'DEF_FLOATS - inquiring history file: ',a)


Someone pls help me to solve the problem?
Rouf

[m.hadfield]

$ ./oceanS < ocean_lake_signell.in> lake_signellout.dat
At line 282 of file def_floats.f90
Traceback: not available, compile with -ftrace=frame or -ftrace=full
Fortran runtime error: Expected CHARACTER for item 1 in formatted transfer, got
REAL. If you want to make character descriptors typeless, compile with -fsloppy-char
(6x,'DEF_FLOATS - inquiring history file: ',a)

I get the same error. I'll look into it.

PS: why do the "quote" tags not work properly?

[m.hadfield]

There's a bug in ROMS/Utility/def_floats.F in the following section of code.

Code: Select all

#  ifdef SEDIMENT
          DO i=1,NST
            IF (itrc.eq.idsed(i)) THEN
              WRITE (Vinfo(19),20) 1000.0_r8*Sd50(i,ng)
            END IF
          END DO
#  endif

The format-statement number in the WRITE statement should be 40.

I'll report this on Trac.

[arango]

Yes, I already found that one. The fix is coming in the next big IO release. I am testing now.