#3172 closed help (answered)

new prognostic variable not working as diagnostic variable

Reported by: pmcguire Owned by: um_support
Component: Diagnostics Keywords: prognostic variable, diagnostic variable, STASH
Cc: Platform: ARCHER
UM Version: 11.5


Hello CMS Helpdesk:
I have successfully adapted the UM FORTRAN code that is used by u-bq532q on puma/ARCHER to create a new prognostic variable that is used by JULES (the ~30-day time-averaging of the air temperature tl_1). This variable correctly gets outputted to the dump files every thirty days, and the spatial distributions make sense.

In order to see the time dependence of this variable better, and to cross-correlate it to some of the dependent vegetation growth diagnostics/prognostics, I have attempted to also output the same STASH variable (section=0, item=206) to the .pd stream of diagnostic variables (similar to the way some other land variables are output on a daily basis). But the variable doesn't show up in the output .pd files.

I had chosen this item number and section number since it appeared not to be used.

~/cylc-run/u-bq532q/log/job/19880901T0000Z/atmos_main/01/job.err :

??????????????????????????????      WARNING       ??????????????????????????????
?  Warning code: -30
?  Warning from routine: PRELIM_MOD:PRELIM
?  Warning message:
?          Field - Section:0, Item:206 request denied.
?          Unavailable to this model version.
?  Warning from processor: 0
?  Warning number: 27

As a result of this error message, I have looked at the code on puma:
but I can't seem to figure out what is wrong with using the 0,206 STASH number.
Is there a better number I should use?
Can I use a prognostic variable also as a diagnostic variable?
Or is there something I haven't done properly in the FORTRAN code in JULES or in the UM?
Is there some documentation that I should read more closely?
I have already been looking at Section 5 of:

Patrick McGuire

Change History (5)

comment:1 Changed 13 months ago by jeff

Hi Patrick

Looking at your STASHmaster entry for 0.206 you have Space=3, which is primary field unavailable to STASH. This is correct because your field is on land points only but means it's not available to STASH.

In the rose edit STASH Requests panel, if you run the stashtestmask.STASHTstmskValidate macro it tells you what STASH items are unavailable and why.

If you need more help I can look at this more tomorrow.


comment:2 Changed 13 months ago by pmcguire

Hi Jeff
I have now run that STASHTstmskValidate macro.
And I do see the Space=3 Error.
And yes, it is land points only field, as designed.

Do you have suggestions about what I should do about this?
Do I need to convert this somehow to a land+sea points field? Is that the right way?
How should I do that?

comment:3 Changed 13 months ago by jeff

Hi Patrick

One thing to look at would be to add an extra diagnostic which would be your field but on all grid points. Maybe it would be possible to do something like what happens to STASH code 8,208 for example. See JULES routine diagnostics_hyd.F90 where it expands the variable out and copies it into the stashwork array. You will need to add another STASHmaster entry for this new diagnostic. I've not done anything like this so maybe there are reasons it won't work, but it's something to look into.


comment:4 Changed 13 months ago by pmcguire

Hi Jeff
Thanks for the suggestion.
I don't think it would be best to revise the FORTRAN code between UM_ATMO cycles of this run. When I do future runs with perhaps ARCHER2, I will try to implement your suggested change to the diagnostic FORTRAN code.
I will close the ticket now.

comment:5 Changed 13 months ago by pmcguire

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