Opened 9 years ago

Closed 9 years ago

#659 closed help (fixed)

Converting UM output files to NetCDF

Reported by: raw88 Owned by: jeff
Component: UM Tools Keywords: ff2pp, bigend, NetCDF
Cc: Platform:
UM Version: 7.3

Description

Hi,

I'm currently running jobs with the UKV model at Vn7.3. My output files are byte-swapped 64-bit ieee UM files and I want to convert them to NetCDF format for analysis. So far I have been doing this simply using xconv on HECToR; however, this results in slight changes in the latitude and longitude coordinates of the data. For example:

353.052500 becomes 353.052490
353.088500 becomes 353.088501
353.124500 becomes 353.124512

A colleague who has encountered this issue before said that the way to overcome it was to convert the data to 32-bit pp-format before converting it to NetCDF using xconv. They're method of doing this was as follows, for a UM file xgala.pp7:

$UMDIR/bin/ff2pp -ieee64bs xgala.pp7 xgala_be.pp7
bigend -32 xgala_be.pp7 xgala_le.pp7

As I can see from the output when I try this, the first step converts the file to 32-bit pp-format and the second changes from big-endian to little-endian. However, the first step also completely messes up the data coordinates, with the 3 values listed above becoming

-2147483648.000000
-3221225472.000000
-4294967296.000000

All of the latitudes and longitudes are changed to huge numbers in this way and in fact the latitudes and longitudes are set to be equal for the length that they overlap (i.e. the first 744 latitudes are equal to each of the 744 longitudes).

I encountered this type of issue before when using xconv to view data from the UKV model. Jeff Cole told me that the version of xconv I was using could not deal with variable resolution grids and pointed me in the direction of an updated version (/home/n02/n02/jwc/bin/xconv1.92) which could. So are there similar updated versions of the utilities ff2pp and bigend which will work on UKV output without messing up the coordinates? Also is the approach to getting NetCDF files with the original coordinates I've described above correct?

Thanks,

Rob

Change History (19)

comment:1 Changed 9 years ago by jeff

  • Owner changed from um_support to jeff
  • Status changed from new to accepted

Hi Rob

The converting to 32 bit method won't work, because the problem is that 64 bit numbers in the um file have been converted to a 32 bit netcdf file and the numbers you get are the closest 32 bit numbers to the 64 bit ones. Also for UKV data the lat/long values are stored in a part of the um header which isn't available in pp format, that is why you get the strange values after using ff2pp.

The only way to get the correct values is to convert the um file into a 64 bit netcdf file. In xconv go to Setup → Setup Xconv Defaults and change Netcdf output precision to be 64 bit.

Jeff.

comment:2 Changed 9 years ago by raw88

Hi Jeff,

Thanks for your response, that worked fine.

I have a slightly different query now, regarding xancil. I am currently trying to create an orography ancillary file for a UKV run where I have flattened the orography of the southwest peninsula of the UK. I created a NetCDF file which contains the altered orography height, orography standard deviation and XX, XY and YY orography gradient fields, using data from a UKV start dump. This file is on HECToR in /work/n02/n02/raw88/ancils/orog_flat_sw.nc. I then use xancil to convert this to an ancillary file (though I am not including the orography gradient fields) - the job is in the same directory as the NetCDF file and is called orog_flat_sw.job. In the 'Grid Configuration' window I have NOT checked the box 'Specify ancillary file dates', in which case (as I understand it) xancil will determine the date from the NetCDF file, which in this case is 2010/07/21:04.00 (0.041667 days since 2010-07-21 03:00:00). However, when I create the ancillary file the date is set to 0000/01/01:00.00 (0.000000 days since 0000-01-01 00:00:00). I have tried specifying the date instead but this appears to have no effect. I tried running my UKV job with the resulting ancillary file but it crashed with the message

*
ERROR!!! in reconfiguration in routine Rcf_Ancil_Atmos
Error Code:- 110
Error Message:- INANCILA : Wrong calendar set in Ancillary File
Error generated from processor 0
*

Clearly I need xancil to give my orography file the correct date, but I don't know how. Do you know where I'm going wrong?

Thanks,

Rob

comment:3 Changed 9 years ago by jeff

Hi Rob

I been away so didn't answer your query, have you managed to sort this out now?

Jeff.

comment:4 Changed 9 years ago by raw88

Hi Jeff,

Sorry for the delay, I didn't see that you had responded.

I haven't managed to sort the issue with xancil, no. I was wondering if it was something to do with the fact that this is UKV data again. I know that this caused problems in xconv, though I can't imagine why the variable grid should have any effect on the time variable. Certainly the date is fine in the NetCDF file, through I do have the weird addition of a 'rotated pole' variable which is some sort of artifact of generating NetCDF files from UM LAM data in IDL.

Any thoughts you have on this issue would be appreiated.

Cheers,

Rob

comment:5 Changed 9 years ago by jeff

Hi Rob

What umui job are using this ancillary file in? What calendar type does this job use? Your ancillary file uses a Gregorian calendar and it looks like your job is using a 360 day calendar.

Jeff.

comment:6 Changed 9 years ago by raw88

Hi Jeff,

The UMUI job using this ancillary file is xgalh (UKV run - NOOROG), which doesn't use a 360 day calendar. The start dump I am using to create the orography data is 20100721_qwqv03.T+1 in /work/n02/n02/raw88/startdump. This is a version 7.6 start dump while the run is version 7.3 - when I create the orography ancillary in xancil I am setting the version to 7.3, so I don't know if that could be causing any problems.

Cheers,

Rob

comment:7 Changed 9 years ago by jeff

Hi Rob

Is there a .leave file available for this run which shows the error?

Jeff.

comment:8 Changed 9 years ago by raw88

Hi Jeff,

The .leave file is xgald000.xgald.d11216.t103111.leave in /home/n02/n02/raw88/um/umui_out. I should point out that the job identifier has since been changed to h so the run ID is now xgalh.

Cheers,

Rob

comment:9 Changed 9 years ago by jeff

Hi Rob

The error message in the leave file says the orography file uses a 360 day calendar and that is why it failed but when I looked at the file it was using a 365 day calendar, the same as the model. So to try and clear up this confusion I thought I would run your job xgalh but it doesn't work. Have you run this job because it looks like it needs some more branches added to make it work.

Jeff.

comment:10 Changed 9 years ago by jeff

I just thought of a reason why the job wasn't working so let me fix that first, when Hector comes back.

Jeff.

comment:11 Changed 9 years ago by jeff

Hi Rob

It looks like xgalh needs extra branches to work. Have you actually run this job?

Jeff.

comment:12 Changed 9 years ago by raw88

Hi Jeff,

The job is copied from another, xgala, which runs just fine. The only important change I have made in xgalh is to use the orography ancillary file that I have generated - if you do a job difference there are a number of other non-significant changes, relating to STASH diagnostics and output LBCs. Why do you think xgalh needs extra branches to work?

Cheers,

Rob

comment:13 Changed 9 years ago by jeff

Hi Rob

This job tries to use mpirun to run the parallel job, which doesn't exist on the Cray. Usually a branch is added to change this so it uses the Cray command aprun. So I don't understand how your job could work? Some of your xgal jobs have lots of branches and some have none, so I not sure what your doing?

Jeff.

comment:14 Changed 9 years ago by raw88

Hi Jeff,

So the first job in experiment xgal is running the UKV model from an operational UKV start dump and LBC files using a pre-compiled executable from another job (xfsyd). Consequently xgala does not use any branches. The remainder of the jobs in this experiment are sensitivity tests. For some of these I have need to make code edits and therefore have had to create a new model executable - in these cases there is both a build job and a run job (b+c, d+e, f+g). The build jobs are the ones which have FCM branches switched on - each of them has been created by starting from job xfsyd and then adding the branch with my code edit. The run jobs meanwhile have each been taken from xgala and editted to use the executable from their respective build jobs. However, in the case of my orography senstivity test (xgalh) I am only changing an ancillary file so the model executable does not need to change. Therefore, this job uses the executable from xfsyd.

I hope all that is correct and makes sense. It might be easier if we discuss this in person since it has taken a lot of work and discussion with Willie to get to this point. I don't really understand why your getting the mpirun/aprun issue. Let me know what you think is best.

Cheers,

Rob

comment:15 Changed 9 years ago by jeff

Hi Rob

Ok I understand a bit better what you are doing now. One thing I still don't understand if you are using another jobs executable then you don't need branches to compile that executable but you still need them to change the job scripts so the correct method of running the executable in parallel is used (i.e. changing from mpirun to aprun). Looking at your DATAW directory you do have the correct scripts I'm just not sure how they got there, did you copy them there by hand? Anyway it looks like if I want to try and compile/run your job I should use xfsyd and just change the ancil file.

Jeff.

comment:16 Changed 9 years ago by raw88

Hi Jeff,

I tried the job and it seemed to run fine though I am still unsure about where those scripts you talked about are coming from. Does it have anything to do with the option 'Use bottom and top script inserts' being set in the window 'Script inserts and Modifications'?

In any case, given that the job ran I guess that means that the UM doesn't care what the date is in the ancillary orography file. Presumably then xancil does not bother setting a date when it creates orography files. Is this correct?

Thanks for your help,

Rob

comment:17 Changed 9 years ago by jeff

Hi Rob

The UM doesn't care about the orography file date but does care about the calendar type, so this needs to be set correctly. I'm not sure why it does this as the calendar type doesn't matter either.

Is everything working ok now? Can I close this query?

Jeff.

comment:18 Changed 9 years ago by raw88

Hi Jeff,

Yes you can close the ticket as the job ran fine.

Thanks for your help,

Rob

comment:19 Changed 9 years ago by jeff

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.