Opened 7 years ago

Closed 7 years ago

#1326 closed help (fixed)

failure reading new ancillary file

Reported by: jcrook Owned by: um_support
Component: UM Model Keywords: ancillary file
Cc: Platform: ARCHER
UM Version: 6.6.3


I am trying to use a new single level user ancillary file within HadGEM2 on ARCHER. I have created a user STASH master file called ship_albedo_gain which contains information about one single level parameter to be accessed as parameter 310. This can be found on PUMA (/home/jcrook/umui_jobs/prestash) or on ARCHER (/home/n02/n02/jcrook2/work/xgezr/ancils). On ARCHER I used xancil to create a single level user ancillary file called ship_wake_albedo.anc from this user STASH master file and my data file I set up my run xgezr on PUMA as a copy of a previous run I have done on ARCHER but with the user ancillary file and user STASH master set up. I performed the reconfiguration step and have now compiled the code and tried to run it from xgezr.astart. However it is having problems reading the ancillary file (see xgezr000.xgezr.d14195.t134032.leave).

Change History (15)

comment:1 Changed 7 years ago by grenville


The problem reported in xgezr000.xgezr.d14195.t134032.leave is not with stash item 310, it is with item 301

STASH code in dataset 126 STASH code requested 301

Does the model run OK if you switch of the updating for stash item 310?


comment:2 Changed 7 years ago by jcrook

Hi Grenville

In the UMUI under Atmosphere→Ancillary and input data→Climatologies→User single level ancillary file there was a file called AR5_surfems_1860 under HG2CCL60_ancils that was referred to but the box Not Used was ticked so I thought it was safe to just replace that file with my own ancillary file which only contains my albedo variable. I don't understand what Not Used means if this is what is causing the problem. May be I need to add these variables as well to my ancillary file? I don't know how to do that though.

Also my ancillary file has data for only one time as it doesn't change with month or year. I set it up to be updated once a year and said it was periodic but may be that is wrong? The data in the AR5_surfems_1860 is monthly. I want my data to be set up once and then stay the same - there is no need to read it repeatedly.

comment:3 Changed 7 years ago by jeff

Hi Julia

In your umui job xgezr, in panel STASH → User-STASHmaster files. Diag, Progs & Ancills, can you change


to be


else others can't look at the Initialisation of User Prognostics panel.

User ancillary files really need to be updated, if you want to have a single time file there is another way to do that. In panel "Initialisation of User Prognostics", for item 310 change option from 2 to 7 and enter the file name into the right hand box.

You will probably need to create the ancillary file again in xancil, this time use the Generalised Ancillary Files section, everything should be straightforward except you need to select yes for "Change value of integer header 8" and give it the value of the number of vertical levels, in your case 60.


comment:4 Changed 7 years ago by jcrook

I have changed the user STASH master files as you suggested and changed the prognostics for item 310 to option 7. I put back the single level user file stuff as it was before I started these changes and I used xancil to recreate the ancillary file as a generalised ancillary file. I did not rebuild the reconfig or the executable but I did the reconfig step and then tried to run the executable. I am getting some error in a dump file now but I don't know what it means. It looks like a sea ice albedo field which I haven't touched.

comment:5 Changed 7 years ago by jeff

Hi Julia

The problem comes from the reconfig step which failed. The reason it failed was it couldn't find your ancillary file, in the umui panel you need to enter the full pathname not use $DATAW, i.e.



comment:6 Changed 7 years ago by jcrook

Sorry I hadn't spotted that. I changed the pathname and now I think the reconfig is ok and my data in the xgezr.astart file looks right. I also managed to run it for 3 months but now I want to make use of my new data in the code. I have changed ftsa.F90 to access the D1 array and have added #include typd1.h. Do I need to #include something else as it wont compile?

comment:7 Changed 7 years ago by jeff

Hi Julia

Accessing the data using the D1 array in that part of the code will be tricky and is not the usual way of doing it. Usually the D1 array is used much higher up in the calling tree and then the data arrays are passed to lower routines using their arguments.

In your case the routine which can access the D1 array and calls routines which will eventually call FTSA is ATM_STEP. The calling sequence is

ATM_STEP → Atmos_Physics1 → NI_rad_ctl → Glue_Rad → ftsa

Stash field 0,310 should be available in atm_step as variable USER_ANC10 (its no longer a user ancillary field but this should still hopefully point to stash item 0,310). So you need to add USER_ANC10 to the argument list of the call to Atmos_Physics1, then add this argument to Atmos_Physics1, where you can rename the variable if you want. Similarly for the rest of the routines in the calling tree. There are plenty of variables in the routines which do this so you should be able to find an example to copy.


comment:8 Changed 7 years ago by jcrook

Well I eventually got all the bits of code changed and the run built but now it crashes with a segmentation fault and I cannot see anything in the .leave file to help.

comment:9 Changed 7 years ago by grenville


You can get some more information about the failure if you switch on ATP - in the Script Inserts and Modifications window set the environment variable

ATP_ENABLED to value 1

The model needs to be linked with this set, so delete the executable and ask for a incremental rebuild, and run the model.

The leave file should contain a stack trace when run with this setting (search for ATP). That should give you some idea where the failure has occurred.


comment:10 Changed 7 years ago by jcrook

Thanks Grenville. I have added the ATP_ENABLED variable and now have some atp files created and the .leave file refers to bi_linear_h.f90 but I don't know what this is.

comment:11 Changed 7 years ago by grenville


That wasn't too helpful (but can be) - bi_linear_h.f90 is a trap for all kinds of problems.

I see that you have changed the function FTSA to include ALBEDO_GAIN, but the call to FTSA in glue_rad-rad_ctl3c.f90 makes no reference to the new variable. You changed the call to FTSA in control/top_level/glue_rad-rad_ctl2.F90 (this would apply to the 3A radiation scheme) for the , but your model doesn't call this. Calling a routine with the incorrect number of arguments is likely to cause a segmentation fault.

You can see what gets built after the pre-processing step (ie after all the if defs are applied) in /home/n02/n02/jcrook2/xgezr/ummodel/ppsrc


comment:12 Changed 7 years ago by jcrook

I cannot find a file called glue_rad-rad_ctl3c.f90. When I checked out a working copy of 6.6.3 it only gave me glue_rad-rad_ctl2.f90 and this ctl2 file is in the ….ummodel/ppsrc on ARCHER.

comment:13 Changed 7 years ago by grenville


I grep'd your code base:

grenville@puma:/home/jcrook/hg6.6.3_changes/hg6.6.3_hg6.6.3_sea_albedo_geoengineering/src> grep -i -r ftsa *

atmosphere/short_wave_radiation/glue_rad-rad_ctl3c.F90: Call ftsa (
control/top_level/glue_rad-rad_ctl2.F90: Call ftsa (

so it's there. It is a little odd that the routines are in different directories.


comment:14 Changed 7 years ago by jcrook

Strange cos I thought I'd looked for it in both places. I would also have hoped the compiler would have warned about the mismatch. Now I've made the right changes I believe it is running ok now - it's on it's 3rd month.


comment:15 Changed 7 years ago by grenville

  • Resolution set to fixed
  • Status changed from new to closed


Glad it's going - if you put subroutines in modules you should get argument checking at compile time, but otherwise not sadly.


Note: See TracTickets for help on using tickets.