Adding non-advection meteo variables

[chron]

I'm trying to add some surface fields for use in the deposition model, and am wondering about the easiest way to do it. I have successfully modified gfs2arl to add the necessary fields to the ARL-format binary met files, and have added flags to DEFMETO.INC and metini.f (these confirm that Hysplit can see the variables: chk_file shows them correctly present for each timestep, and the flags are printed as T in MESSAGE).

But in trying to actually load in the fields and pass them to depdry via depelm, I'm lost trying to keep track of the various global/sub-grids. My understanding is that advmet is the only interface for non-advected variables, so it should seems it should be possible to do this without changing the I/O spec of all of the other routines. Can all of the changes be done in advmet using the meto and drec sequences?

[roland.draxler]

Your on the right track. Essentially ADVMET assigns values to predefined meteorological variables to the particle at the end of the advection step. For instance, a non-temporally varying field, like land use (LU) is simply assigned to the variable METEO%LAND which is then passed through to the DEPELM subroutine. A time-varying variable such as friction velocity is first interpolated in space and time (METO%USTR) before being passed to DEPELM. You don't need to worry about full- or sub-grid definitions. Just make sure the variable is allocated in ADVPNT and passed through the code to METINP. The model will automatically adjust the sub-grid and reload data as needed.

[chron]

Thanks for the help! In case anyone else feels compelled to do the same, to get access to the fields I only needed to modify:

• library/hysplit/DEFARG2.INC (interfaces to metinp and advmet)
• library/hysplit/DEFMETO.INC (METO sequence definition)
• library/hysplit/advmet.f (returns local meteorology at a point in space and time)
• library/hysplit/advpnt.f (along with advmet, this does all the magical interpolation and grid handling)
• library/hysplit/dalloc.f (deallocates arrays)
• library/hysplit/metinp.f (reads meteorological input files)
• library/hysplit/metval.f (included in other routines -- common interface to declare meteorological arrays which can then be allocated)

Most of these were just interface changes (e.g. in DEFARG2), and really only comprised a few lines. As a guide, I used an old revision (147) which had added 2m relative humidity input as a guide for the changes. I found that debugging by examining text profiles of the meteorological input file via the hysplit GUI menu was helpful.

After that, it was necessary to modify calls from hymodelc.f to depelm (and subsequently its interface to depdry). I actually just branched a new deposition program so as not to break legacy functionality in the standard hycs modes, though it wouldn't be hard to add a compile flag to just build another variant of hymodelc, as is already done for hycs_{std,ens,...}.

One last step was to change the interfaces to advmet and metinp in vmixing.f, since their input specs changed (even though I do not use that method).

[chron]

A follow-up question on this topic: is it possible to output interpolated meteorological variables on the concentration grid, similar to the way it is done for trajectories? I realize that this might not seem that useful, but it would be very handy for situations where one wants to evaluate the surface conditions during deposition. As a bonus for those of us who like sanity-checks, it would already be on the same grid via the same internal interpolation routines (leaving no space for me to make an error in reproducing the interpolation externally).

I've poked around the code a bit, and as far as I can tell the trajectory meteorology output (via trjinp and trjdsk) isn't in a form that would be easily adapted to particle runs. But condsk does have access to the meto grid information, so it seems like one could just add a duplicate concentration grid (say, T02M) at each output, for all nonzero concentration values. Any thoughts on this?