ropp_io_assign.f90

And perhaps the 'extra data' (ie, that held in ro_data%vlist%vlistD?d%next%next%...) too, though that might be more difficult.

(Regarding the latter: Hans suggests that

     ro_data%vlist%VlistD0d  => ro_data1%vlist%VlistD0d
     ro_data% ......  D1d   =>   ro_data1% ...... D1d
     ro_data% ...... D2d   =>    ro_data1% ...... D2d

might work. Needs checking.)

The copying of 'BG' data has been introduced at r4888.

I'm uneasy about extending ropp_io_assign.f90 to 'vlist' data, because one then runs the risk of 'dangling pointers'. Eg, if

to_data%vlist => from_data%vlist

and from_data%vlist is later annulled (eg by a call to ropp_io_free), then to_data%vlist is undefined. This caused some problems when I tested it.

These could be solved by NULLIFYing the relevant structures, but that's starting to get unwieldy. And even if we got around this, there's the problem that if you try to add an extra data variable which has the same name as an existing one, you get a netCDF error:

FATAL ERROR (from ropp_io_write_ncdf_def):  NetCDF: String match to name in use

Fixing that problem, eg by searching for the name of the proposed extra data variables in the list of existing extra data, and then either changing the proposed name (as I did in subroutine check_2d_data_name in ropp_fm_bg2ro_1d at r4872), or by overwriting the existing extra data, is also messy. Besides, if required, one can easily append extra data from the input file to the output file, eg with

ncks -a -vextra_data1,extra_data2,... file_in.nc -A file_out.nc

So, I'll leave ropp_apps_tph_tool.f90 and ropp_apps_pblh_tool.f90 alone (for now). (They get around the problem by working with an 'extra_data-free' copy of the input profile.)

(Some typographical, explanatory changes to ropp_apps_tph_tool.f90 and ropp_apps_pblh_tool.f90 have been made at r4889.)

Closing ticket as 'fixed'.