INQUIRE unable to find....

[johnluick]

This is an oddity...but then, so is everything until someone explains it, I suppose...

ROMS stops with the following message from inquire.f90:

INQUIRE - unable to find requested variable:
in files:
...etc. (then it lists all the netcdf forcing files). Notice that the variable field is blank! What is it looking for?

A little background...
this particular project ran fine last time I tried it (November 2011). When I went to run it yesterday, it complained about a lack of a surface flux variable (dye variable with _sflux suffix), so I added a surface flux (with coordinate attribute "lon lat", apparently required for CF compliance). After that, it read it (dye_01_sflux) in, and immediately threw the above error.

The dye comes in as river_dye_01, but the lateral and surface boundary conditions are on dye_01 (no "river" prefix). I guess that makes sense in a way. The open boundary condition is "RAD" only, so it shouldn't be looking for a flux there.

I can't find anything in the forums or repository about _sflux. Did I miss something?

The project still runs fine if T_PASSIVE is turned off.

[arango]

This usually implies that ROMS does not have the name of the variable that it is trying to process. The name for such variable is blank or empty during execution. It is possible that your input metadata file varinfo.dat is old and inconsistent with the newer version of ROMS that you are running.

I have this problem myself before when trying to run old configurations. Then, if I look in the debugger the problem is very obvious and usually due to varinfo.dat or ocean.in.

[kate]

So what's missing from varinfo.dat is something for the dye__sflux. We've got river_dye_, dye_, dye_west_ and the other directions. What should be the syntax for dye_?_sflux in the varinfo file?

[johnluick]

Thank you, Kate, for asking this. I started to experiment with adding it to varinfo.dat, but HOW to do it wasn't obvious because of the way "_sflux" is tacked on within the program after the 01, 02, etc., so I gave up and when home feeling rather frustrated. Nice to see your post this morning.

[arango]

Well, you do not need to do that because mod_ncparam.F take cares of this automatically:

Code: Select all

!-----------------------------------------------------------------------
!  Set passive tracers surface flux metadata. The variable name is the
!  same as the basic tracer but with the _sflux suffix.
!-----------------------------------------------------------------------
!
      DO i=NAT+1,MT
        varid=varid+1
        IF (varid.gt.MV) THEN
          WRITE (stdout,60) MV, varid
          STOP
        END IF
        idTsur(i)=varid
        DO ng=1,Ngrids
          Fscale(varid,ng)=1.0_r8
          Iinfo(1,varid,ng)=r2dvar
        END DO
        WRITE (Vname(1,varid),'(a,a)')                                  &
     &        TRIM(ADJUSTL(Vname(1,idTvar(i)))), '_sflux'
        WRITE (Vname(2,varid),'(a,a)')                                  &
     &        TRIM(ADJUSTL(Vname(2,idTvar(i)))), ', surface flux'
        WRITE (Vname(3,varid),'(a,1x,a)')                               &
     &        TRIM(ADJUSTL(Vname(3,idTvar(i)))), 'meter second-1'
        WRITE (Vname(4,varid),'(a,a)')                                  &
     &        TRIM(Vname(1,varid)), ', scalar, series'
        WRITE (Vname(5,varid),'(a)')                                    &
     &        TRIM(ADJUSTL(Vname(5,idTvar(i))))
      END DO

That's the reason why we do not have the metadata for all the passive tracer fluxes. Because it uses the tracer variable name plus the _sflux suffix. The problem is somewhere else. Make sure that your fluxes follows that convention. It will be awkward to specify the metadata for all the posssible passive tracers

You are combining two different things: inert/passive tracer 3D state variables and tracer point sources. The rivers (point sources) never use surface tracer flux I don't know what are you talking about. Did you modify the distributed code?

[johnluick]

Thanks, Hernan, for this explanation, and for your post yesterday. You are quite right; I did think that there was a connection between the 3D state variable and the point source. This now makes much better sense. This also explains why it ran when T_PASSIVE was turned off. I also got rid of all references to _sflux and it now runs fine (again). Cheers.
(Sorry if I caused confusion to anyone by previous post.)

[kate]

Did you figure out how to run with passive tracers? You might try these options:

Code: Select all

# define ANA_BPFLUX        /* analytical bottom passive tracers fluxes */
# define ANA_SPFLUX        /* analytical surface passive tracers fluxes */

and accept the default behavior of the corresponding ana_ routines (or change them).

[johnluick]

Kate,

thanks for that - indeed I did not always have ana_spflux and/or ana_bpflux defined before, and it took me some while (and with some help) to realise they were required (and indeed this was my main problem, since I do not provide surface and fluxes using netcdf files). I was going to add this point to this thread myself eventually.

For what it's worth, this is what I ended up with:
#define T_PASSIVE /*Advect/diffuse/process passive tracers*/
#ifdef T_PASSIVE
# define TS_PSOURCE /*Turn on tracer point sources*/
# undef UV_PSOURCE /*Point source of passive tracer (horizontal)*/
# define Q_PSOURCE /*Point source of passive tracer (vertical)*/
# define ANA_SPFLUX /*Specify passive tracer surface flux analytically*/
# define ANA_BPFLUX /*Specify passive tracer bottom flux analytically*/
#endif
My references to "horizontal" and "vertical" in the above are based on comments in the forum and elsewhere; I have never looked at the code specifically to see if it is true, and the comments in cppdefs and in the standard output do not really distinguish between the two, but it makes sense. Someone is welcome to enlighten me. But I am pretty sure you have to use one or the other; not both. I find that with Q_PSOURCE, and with the variable "river_transport" being negative for a source at any level below the surface (but positive AT the surface), the model behaves nicely (whatever negative dye concentrations appear are extremely small and transient). My sources ("rivers") are out in open water, not at the coast.

In case anyone else was a bit hazy on the relationship between dye_01 and river_dye_01 and their ilk, I will add a quote from John Wilkin (I hope he will not mind). I think it is important...

"Dyes and river_dyes are not independent.
dye_01 is the state variable representing the first passive tracer. If
there are river sources that add to mass of dye_01 then we need to
know the concentration of dye_01 in each river. The concentration is
set by river_dye_01 and it may have a different value in each river
hence the 'river' dimension in the netcdf variable river_dye_01).

But if any particular dye does not occur in ANY river, then you can
by-pass the need to specify its concentration by setting the
LtracerSrc for that river to False. This way get_data.F does not
attempt to process that river when reading the river netcdf file, and
it does not need an entry in the netcdf file.

We introduced this construct to parallel the biological tracers. For
the biological models, with say some 15 or so state variables, we were
in the situation that if there were to be any river sources at all we
were committed to creating netcdf variables for all 15 state variables
in 20 (?) or so rivers. Even if for many of the bio state variables
there would never be any input (like, marine diatoms coming out of
rivers)."