Opened 7 years ago

Closed 7 years ago

#1160 closed help (fixed)

some un-needed UM dumps are not deleted

Reported by: luke Owned by: jeff
Component: UM Model Keywords:
Cc: Platform: HECToR
UM Version: 7.3



I am running a UM7.3 N48L60 HadGEM3-A r2.0 UKCA job on HECToR, which is set to archive to the /nerc disk. This is job xizva.

This job uses Jeff's archiving branch


at revision 11342 (the latest revision, which uses the LMS for the data copying) with his hand-edit


I have implemented the correction he mentions here

and while the seasonal dumps are saved as requested, and the xizva.requests file asks for the deletion of the end-of-month dumps, e.g.

[15:44:45 luke@hector-xe6-7 xizva]$ grep xizvaa.da xizva.requests 
%%% xizvaa.dag01l0 DELETE     
%%% xizvaa.dag0310 ARCHIVE     DUMP
%%% xizvaa.dag02l0 DELETE     
%%% xizvaa.dag03l0 DELETE     
%%% xizvaa.dag04l0 DELETE     
%%% xizvaa.dag0610 ARCHIVE     DUMP
%%% xizvaa.dag05l0 DELETE 

the 10th and 20th day of the month dumps still exist, e.g.

[15:46:02 luke@hector-xe6-7 xizva]$ ls -l xizvaa.da*
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 10:32 xizvaa.dag01b0
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 11:08 xizvaa.dag0210
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 11:27 xizvaa.dag02b0
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 12:03 xizvaa.dag0310
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 12:22 xizvaa.dag03b0
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 13:00 xizvaa.dag0410
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 13:19 xizvaa.dag04b0
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 13:55 xizvaa.dag0510
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 14:13 xizvaa.dag05b0
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 14:50 xizvaa.dag0610
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 15:09 xizvaa.dag06b0
-rw-r--r-- 1 luke n02 1665024000 2013-10-28 15:45 xizvaa.dag0710

The equivalent job on MONSooN does not show this behaviour.

Do you know what I can do to get these un-needed dumps to be deleted?

Many thanks,

Change History (8)

comment:1 Changed 7 years ago by jeff

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

Hi Luke

This is very strange, I'm not sure what's going wrong. I'm running your job to try and track down the problem, I'll let you know when I have something.


comment:2 Changed 7 years ago by jeff

Hi Luke

I think I've tracked down the problem, there is a local variable which isn't given an initial value and is then used and this causes another variable to be set which stops certain files being archived. The variable is internal_model in routine dumpctl.F90, in later versions of the UM this is fixed by adding an extra line to this bit of the code

      IF (MEANLEV <= 0) THEN  ! Instantaneous dump or analysis

        IF (I_AO == 1) THEN   ! Atmos submodel
          internal_model = atmos_im


It looks a bit of a bodge because it makes the following lines redundant, but I guess that is the UM for you. I'm not sure what the best place to put this fix is, any ideas?


comment:3 Changed 7 years ago by luke

Hi Jeff,

I have a branch that I use in my jobs which makes sure unit 8 is open:

$ fcm diff fcm:um_br/dev/luke/vn7.3_ppctl_reinit@11195 fcm:um_br/dev/luke/vn7.3_ppctl_reinit@11196
Index: src/control/top_level/ppctl_reinit.F90
--- src/control/top_level/ppctl_reinit.F90      (revision 11195)
+++ src/control/top_level/ppctl_reinit.F90      (revision 11196)
@@ -95,6 +95,8 @@
   Integer,Parameter ::AnalysisHours = 0 
   Integer,Parameter ::Toggle        = 1
+  Logical :: FileName_Open ! is unit 8 open at the top of the routine?
   ! Get seconds per timestep and current timestep number.
   If (I_AO == a_im) Then
@@ -105,6 +107,8 @@
   ! Get name of pipe
   Call get_file(8, filename, 80, icode)
+  Inquire(Unit=8,Opened=FileName_Open)
+  If (.Not.FileName_Open) Open(Unit=8,File=filename)
   ! ----------------------------------------------------------------------
   !  1.1 Loop over all valid FORTRAN units and select those to be

so personally I could add this into this branch. However, do you think it should go somewhere else?


comment:4 Changed 7 years ago by luke

Also, thanks for finding this bug!!

comment:5 Changed 7 years ago by jeff

Maybe I'll add it to the archiving branch, hopefully there won't be any clashes. Not sure why its doing tests for the old ocean model anyway, seeing as it isn't even in this model version.


comment:6 Changed 7 years ago by luke

That's probably best, given that it might affect others. Let me know when you've made the change and I'll update my jobs.

Thanks again,

comment:7 Changed 7 years ago by jeff

Hi Luke

I've updated the vn7.3 HadGEM3 archiving branch now.


comment:8 Changed 7 years ago by jeff

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