Opened 5 years ago

Closed 4 years ago

#1449 closed help (answered)

Further UMUI options to help Debug HadGEM3-A

Reported by: swr04ojb Owned by: um_support
Component: UM Model Keywords:
Cc: Platform: ARCHER
UM Version: 8.5

Description

Hello,

thanks to Grenville I have switched on ATP, and that's helped move things forward a little. But now I'm getting an error which appears to be in the windfields, but I'm fairly certain has propagated there from elsewhere. There are a few things I'd like to be able to do to help, and I wondered if some/all are possible:

1) switching on bounds-checking? (looking at other tickets suggests that the -C compiler flag would accomplish this, but lacks the detail on how to go about supplying an additional flag to the compiler?)

2) I'd like to check if a variable is being used beyond where I think it is (grep suggests not), and would like to simply use NaNs? to trigger a floating point exception in the case where something tries to work with this variable. Is there anything extra I would need to do to catch floating point arithmetic errors? (rather than allowing them to propagate).

3) Is it possible to examine the model state more frequently? e.g. a simple way to dump the D1 array? I'm running into that wind-field error on the 5th—15th timestep, and was wanting to check a few other fields in the immediate run-up to the crash to try to pin down where it might be coming from.

thanks!

Oliver

Change History (2)

comment:1 Changed 5 years ago by grenville

Oliver

To answer (3) - you can request dumps at individual time-steps; navigate to model selection→atmosphere→control→post processing, dumping ..→dumping and meaning and select Irregular dump times, hit Next, and complete the Dumps table.

(1) can be done:

Switching on bounds checking is possible - you will need to write a file override (this is covered in the FCM tutorial, please see https://puma.nerc.ac.uk/trac/UM_TUTORIAL/wiki/UmTutorial/vn8.2/CodeChange and search for Compiler and Machine Overrides) - or you can "hack" the bld.cfg file (not highly recommended, since your changes won't be recorded). It helps if you have some idea of where the model may be going out of bounds and apply bounds checking to that section (or routine ) only.

Our experience of trapping floating point errors in the UM has been poor, and we haven't really pursued this debugging technique.

Grenville

comment:2 Changed 4 years ago by annette

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