Opened 9 years ago

Closed 9 years ago

#412 closed help (fixed)

some ancillary files missing

Reported by: anmcr Owned by: willie
Component: UM Model Keywords: ancillary generation ozone
Cc: g.m.s.lister@… Platform:
UM Version: 6.1

Description

Please rerun your ancillary job, but select 'method 2' in the >'IGBP >Aggregation Method' chooser box. I successfully ran the >job with >this option (you can see the files in /export/puma/data-01/ancil/m1.1264003927 or use them if you wish).

Hi,

Earlier this year I had a problem generating ancillary files over a region of Antarctica which was solved by the solution above. I recently moved my LAM domain to another region of Antarctica but when I regenerate the ancillary files qrclim.smow and qrparm.soli_igbp are missing. I have tried all combinations of IGBP methods and exaimined UMDP 73, but I haven't been able to fix it.

The nearest I came was choosing IGBP Aggregation method 4 which at least generated qrparm.veg_frac_igbp and qrparm.veg.func_igbp files, otherwise these are often missing.

I tried running the model without the qrclim.smow and qrparm.soil ancillaries but it failed.

The dimensions of my LAM are:

cols: 750
rows: 750
dx: 0.036
dy: 0.036
1st lat: -46.58
1st lon: 169.85
pole lat: 21.73
pole lon: 8.07

Thanks,

Andrew

Change History (15)

comment:1 Changed 9 years ago by grenville

Andrew

I am looking into the problem. The error messages in the log files are rather cryptic. Please could you remind me of the dimensions of the LAM that did run successfully. Please also let me know the job id of the run that failed when you didn't reconfigure the soils and smow ancillaries. I would have thought that reconfiguring a global start file (without soil/smow ancillaries) should produce pretty much what the CAP would give for the soil/smow fields in view of the resolution of the source ancillary data. Did the reconfigured start file have reasonable fields?

Grenville

comment:2 Changed 9 years ago by anmcr

Dear Grenville,

Thanks for looking into this.

1) The dimensions of the LAM which ran successfully were

No. cols: 750
No. rows: 750
dx: 0.036
dy: 0.036
1st lat: -19.48
1st lon: 185.0
pole lat: 21.73
pole lon: 8.07

2) The experiment id of the run in which I switched off the configuration of the .soil and .smow ancillaries is 'xdvhr'.

I can't view the start dump myself at this moment as Hector is having a maintenance session. However I have nested down from a global → 12 km → 4km run. The global startdump was ECMWF ERA40. The startdump of the 4km run is the reconfigured 12 km startdump.

Thanks,

Andrew

comment:3 Changed 9 years ago by willie

  • Status changed from new to assigned

comment:4 Changed 9 years ago by willie

  • Component changed from Data to UM Model
  • Status changed from assigned to accepted

comment:5 Changed 9 years ago by willie

  • Cc g.m.s.lister@… added
  • Keywords ozone added

Hi Andrew,

I looked at your run xdvhr and eventually discovered that your ozone file is corrupted - looks like it is a third of the size it should be. I have regenerated the ozone file - it is in /work/n02/n02/wmcginty/Anmcr_ozone.1272037800 - and the run seems to work. The soil and smow ancillaries are not used.

I hope that helps.

Willie

Below I repeat the error messages in the '.leave' file for the run xdvhr for the record, though they are not at all helpful.

BUFFIN: Read Failed: Success

**FATAL ERROR WHEN READING/WRITING MODEL DUMP**
buffer in of real data
Error code = 0.00
Length requested = 562500
Length actually transferred = 0
Fatal error codes are as follows:
-1.0 Mismatch between actual and requested data length
0.0 End-of-file was read
1.0 Error occurred during read
2.0 Other disk malfunction
3.0 File does not exist

And later,

ERROR!!! in reconfiguration in routine ReadFlds
Error Code:- 1
Error Message:- Rcf_READFLDS:I/O error
Error generated from processor 0

And still later,

 REPLANCA: UPDATE REQUIRED FOR FIELD 7 : Ozone
Information used in checking ancillary data set: position of lookup table in dataset: 97
Position of first lookup table referring to data type 1
Interval between lookup tables referring to data type 24 Number of steps 4
STASH code in dataset 60 STASH code requested 60
'Start' position of lookup tables for dataset in overall lookup array 1
*ERROR* Reading field no 97
FIELD NO. 97 OZONE **
VALID AT: 0000Z 01/04/1984 DAY 0 DATA TIME: 2359Z 30/04/1989 DAY 0
LBTIM LBFT LBLREC LBCODE LBHEM LBROW LBNPT LBEXT LBPACK
21 0 562500 101 3 750 750 0 0
LBREL LBFC LBCFC LBPROC LBVC LBRVC LBEXP LBBEGIN LBNREC
2 453 0 128 9 0 0 54091776 563200
LBPROJ LBTYP LBLEV LBRSVD LBRSVD LBRSVD LBRSVD LBSRCE
0 0 19 0 0 0 0 6061111
DATA_TYPE NADDR LBUSER ITEM_CODE LBPLEV LBUSER MODEL_CODE
1 54000001 0 60 0 0 1
BULEV BHULEV BRSVD(3) BRSVD(4) BDATUM
7.6100E+03 3.1958E-01 0.0000E+00 0.0000E+00 0.0000E+00
BACC BLEV BRLEV BHLEV BHRLEV
0.0000E+00 7.2200E+03 6.8500E+03 3.4527E-01 3.7055E-01
BPLAT BPLON BGOR BZY BDY
2.1730E+01 8.0700E+00 0.0000E+00 -4.6616E+01 3.6000E-02
BZX BDX BMDI BMKS
1.6981E+02 3.6000E-02 -1.0737E+09 1.0000E+00

comment:6 Changed 9 years ago by anmcr

Dear Willie,

Thanks for looking at this.

Now that Hector is back running I had a look at the model run in which you missed out the .smow and .soil ancillaries. Unfortunately although the model completed the 48h run it gave the 'RHS zero so GCR not needed' after each timestep. From experience I believe this is associated with not configuring with all the ancillaries. I don't know if you know a way around this or if Grenville can find a way to compute the .smow and .soil ancillaries.

Thanks,

Andrew

Atm_Step: Timestep 1

==============================================
initial Absolute Norm : 9745690118350876.
GCR( 2 ) failed to converge in 200 iterations.
Final Absolute Norm : 21849950829447.129
==============================================

Atm_Step: Timestep 2

RHS zero so GCR( 2 ) not needed
==============================================

Atm_Step: Timestep 3

RHS zero so GCR( 2 ) not needed

comment:7 Changed 9 years ago by willie

Hi Andrew,

I have made several attempts at solving this, to no avail;

  1. reducing the time step to 25 seconds,
  2. configuring the standard deviation of the orography,
  3. doubling the width of the orography blending zone.

Our CAP program is unable to produce smow and soil ancillaries in this region. However, we believe that it is not necessary to configure these ancillaries. In the past, similar problems have been caused by high orography on the boundary of the LAM, and this is certainly the case here. The solution is less clear. If it is possible to move the boundary of the LAM away from strong orographic gradients, then this should be done.

A five second time step causes a segmentation fault.

Regards,

Willie

comment:8 Changed 9 years ago by anmcr

Hi Willie,

Thanks for doing these tests.

I'II move the boundary of the LAM so that it is away from large gradients in orography.

I'II let you know I get on.

Could you please leave this ticket open for now.

Thanks,

Andrew

comment:9 Changed 9 years ago by anmcr

Dear Willie,

The coastline of Antarctica — which is what I am interested in — is more or less characterised by sharp gradients in orography, which makes moving the boundary of the LAM away from strong orographic gradients difficult.

One option might be to smooth the orography field, as discussed in Webster et al. 2003. Have you heard of this being applied successfully?

Thanks,

Andrew

Webster et al., 2003: Improvements to the representation of orography in the Met Office Unified Model, Quarterly Journal, 129, pp. 1989-2010.

comment:10 Changed 9 years ago by grenville

Andrew

We had problems (the model was developing very high w in the rim) running over Pacific islands in a domain with steep orography in the rim region. We overcame the problems by increasing the rim width from 8 to 12 and increasing the width of the orograpahy blending zone. This means rerunning the model that created the lbcs, and means bigger lbc files. It is probably worth running your model as is and outputting stash at the first timestep to see if you can identify where it is blowing up before trying this. It might also be worth shifting your domain slightly (requiring new ancillaries + lbcs) - this has proved successful in the past. A job with the wide rim and blending zone is xdnqx (rim width 12, blending zone 27)

Grenville

comment:11 Changed 9 years ago by willie

Hi Andrew,

I think it is the high orography in central Antartica that is the issue: it forms one of the borders of the LAM; the coast line is not on the border. I have had a look at the filtering and can find no one who has implemented it in the UM, so there is no contrary information. There does not seem to be an option to use Raymond filtering the UMUI.

Other tickets which relate to orography, convergence and Antartica are #34, #262, #355.

It may also be useful to talk to Ian Refrew (i.renfrew@…) who has worked with the UM on Antartic LAMS.

Regards,

Willie

comment:12 Changed 9 years ago by willie

Hi Andrew,

I switched on the printing of vertical velocity ( Atmos > Scientific > Section 13 and the diagnostic panel) and this shows outrageous values ( ~ 1013 m/s) even after the first time step.

I have looked a little more closely at the reconfigured start dump - some have suggested that very small values of the fraction of ice can make the model unstable. I notice however, that there are some isolated points where the value is the missing data indicator. Thus it looks like the reconfiguration has not worked properly. This could be due to a slighy mis-alignment of the land-sea mask vs the rest of the ancillary files.

Regards,

Willie

comment:13 Changed 9 years ago by anmcr

Dear Willie,

Thanks again for looking at this.

I'm working on this problem now. You and Grenville have given me enough suggestions for me to work through, so I'm hopeful I can resolve the issue.

Could you please leave this ticket open for now. I'II keep you updated.

Andrew

comment:14 Changed 9 years ago by anmcr

Dear Willie and Grenville,

Please close this ticket. Grenville's recommendation to use a rim width of 12 and a blending zone of 27 helped greatly.

Thanks,

Andrew

comment:15 Changed 9 years ago by grenville

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