Opened 4 years ago

Closed 4 years ago

#1640 closed help (answered)

segmentation fault when converting from double-call to time-stepping

Reported by: Leighton_Regayre Owned by: um_support
Component: UKCA Keywords:
Cc: Platform: ARCHER
UM Version: 8.4

Description

Hello,

I'm attempting to convert a job (xltp.a) configured to use the double-call radiation scheme into one (xltp.i) that uses the time-stepping scheme. I need these jobs to be identical except in the scheme used, hence the need to make this conversion.

I've converted double-call to time-stepping successfully in the past and have followed the same process here. One problem I faced in the past was the need to make sure the restart file and STASH requests within the job do not conflict. I've avoided that problem by using a restart file from the original double-call job and have made no changes to the STASH.

My time-stepping jobs are failing with a segmentation fault (in qsatmos) and I'm having difficulty understanding why. Output in the .leave files suggests it may be ancillary related with warnings such as:

INANCILA: update requested for item 63 STASHcode 316 but prognostic address not set
FIELDCODE values reset to zeroes

and:

Warning Message: Incorrect structure for ancillary file 18

Please note that the double-call jobs run fine with ancillaries setup for 360 day simulations, where I include the branch:

fcm:um_br/dev/jwalton/vn8.4_ignore_calendar_UKMO/src

so this shouldn't be the problem.

Thanks,

Leighton.

Change History (3)

comment:1 Changed 4 years ago by luke

Hi Leighton,

Can you get your timestepping job to run with a different start dump? You have said that you've got it running before - does it work with the file used in that job? You could <code>cumf</code> the .astart files if it does to highlight if any fields have been added or removed.

I'm not too familiar with the double-call set-up I'm afraid.

Thanks,
Luke

comment:2 Changed 4 years ago by Leighton_Regayre

Hi Luke,

Thanks for taking the time to think about this for me.

I was aware that start dumps could cause problems from attempting this with an earlier version of the job. I therefore made sure I was using a start dump from the double-call job I'd copied, so that wasn't the cause of the problem.

The segmentation fault was occurring during the running of 'compute_aod.F90'. Graham Mann has used this information to identify the problem.

'compute_aod.F90' should not be called in these simulations because we are no longer using CLASSIC aerosols with GLOMAP providing all aerosol types (even dust - we have included a modal dust scheme in these simulations).

However, we are still selecting the sulphur cycle and dust emissions in the (CLASSIC) "Aerosols" UMUI panel because we still pick up the dust, DMS and SO2 emissions from CLASSIC and pass them through to UKCA. Note that that is actually changing imminently with the new UKCA emissions approach that comes in at v8.6 or v9.1-ish.

There is an issue where the UMUI automatically selects the CLASSIC sulphate AOD when the CLASSIC sulphur cycle is selected. For that reason I (Graham) put together a hand-edit to remove that STASH request from the STASHC file in the umui_jobs/jobid/ directory.

This hand_edit can be found on PUMA here:
~gmann/umui_jobs/hand_edits/vn8.4_nosulphateAOD.ed

Cheers,

Leighton.

comment:3 Changed 4 years ago by ros

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