OpenDrift / opendrift

Open source framework for ocean trajectory modelling
https://opendrift.github.io
GNU General Public License v2.0
249 stars 120 forks source link

land_binary_mask issue #642

Closed AndresSepulveda closed 1 year ago

AndresSepulveda commented 3 years ago

Hi,

I am using an CROCO output with the reader_ROMS_native.py reader

which maps mask_rho to land_binary_mask

    # Map ROMS variable names to CF standard_name
    self.ROMS_variable_mapping = {
        # Removing (temoprarily) land_binary_mask from ROMS-variables,
        # as this leads to trouble with linearNDFast interpolation
        'mask_rho': 'land_binary_mask',

the CROCO output file does have the mask_rho variable

    float mask_rho(eta_rho, xi_rho) ;
            mask_rho:long_name = "mask on RHO-points" ;
            mask_rho:option_0 = "land" ;
            mask_rho:option_1 = "water" ;
            mask_rho:standard_name = "land_binary_mask" ;
            mask_rho:coordinates = "lat_rho lon_rho" ;

( but in the output I see the message

10:51:06 WARNING opendrift.models.basemodel: Missing variables: ['land_binary_mask']

I remember this warning message

10:52:19 WARNING opendrift.readers.basereader.structured: Data block from roms native not large enough to cover element positions within timestep. Buffer size (82) must be increased.

was related to a particle leaving the model domain. Could this be the case for the land_binary_mask also?

Regards,

Andrés

knutfrode commented 3 years ago

After you create the reader, is land_binary_mask listed when you type >>> print(reader) ?

If so, you could also try to plot it: >>> reader.plot('land_binary_mask')

AndresSepulveda commented 3 years ago

It does,

Available time range: start: 2000-01-01 00:00:00 end: 2001-03-25 00:00:00 step: 1 day, 0:00:00 450 times (0 missing) Variables: sea_floor_depth_below_sea_level land_binary_mask sea_surface_height x_sea_water_velocity y_sea_water_velocity sea_water_temperature upward_sea_water_velocity

and the plot loos as what it should be.

The warning appears not very often, so my guess it is related to a particle leaving the domain.