Opened 8 years ago

Closed 8 years ago

#454 closed defect (fixed)

ropp_io_assign needs to copy BG information across

Reported by: Ian Culverwell Owned by: Ian Culverwell
Priority: normal Milestone: 9.0
Component: ropp_io Version: 8.0
Keywords: copy Cc:

Description

As a result of tests of the TPH routines, Hans Gleisner at DMI spotted that ropp_io/ropp/ropp_io_assign.f90 was not copying the %BG substructure of Roprof. Don't know why. The attached ROPP8.1 code gives the required updates.

Attachments (1)

ropp_io_assign.f90 (30.4 KB ) - added by Ian Culverwell 8 years ago.
ropp_io_assign.f90

Download all attachments as: .zip

Change history (7)

by Ian Culverwell, 8 years ago

Attachment: ropp_io_assign.f90 added

ropp_io_assign.f90

comment:1 by Ian Culverwell, 8 years ago

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

comment:2 by Ian Culverwell, 8 years ago

(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.)

comment:3 by Ian Culverwell, 8 years ago

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

comment:4 by Ian Culverwell, 8 years ago

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.)

comment:5 by Ian Culverwell, 8 years ago

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

comment:6 by Ian Culverwell, 8 years ago

Resolution: fixed
Status: newclosed

Closing ticket as 'fixed'.

Note: See TracTickets for help on using tickets.