source: (poseidon.ohist.f90) [ c_92_rp1 release ]

Types Subroutines Variables



This module provides Poseidon history processing.

After the ocean object is created, the simplest sequence for history processing is:


Alternatively, one can put the WRITE_OHIST inside the time loop and call it under alarm control. If that is done, remember to INITIALIZE_OHIST right after writing

What goes in the history file is determined by the model's Diagnostic. This may seem less than optimally flexible -- one might want to allow the model to compute more diagnostics than we want to write to the history file. What is needed is a way to sub-select from the diagnostic object. Right now, this is provided in this module through code. What we need is a way to turn the history object's diagnostic elements to "unwanted".

Since the history is considered independent of the model, we have less concern with people mucking about here and changing things to tailor what they want to see in the history file, so here is how to do it.

If you want to compute a diagnostic, but omit it from the history, go to CREATE_OHIST and look for CREATE_DIAGNOSTICS_COPY. Add a line

ohist%STUFF%wanted = .false.

To add a new history item: There are two types of history items, those which can be diagnosed on the fly from a snapshot of the state, and those which must be extracted from the model through a diagnostic:

Adding a history item from the state object:

Give it a name, and add it to the T_Poseidon_History declaration as a T_Optional_Array (perhaps 2 or 3 dimensions)

in CREATE_OHIST, set the wanted property and call CREATE_OPTIONAL_ARRAY for the proper size array.

in INITIALIZE_OHIST, set the value to zero:

           if ( ohist%_my_item_%wanted) ohist%_my_item_%val = 0.0

in ACCUMULATE_OHIST, bump the accumulator:

if ( ohist%_my_item_%wanted) & ohist%_my_item_%val = ohist%_my_item_%val + function(ohist%S) * interval

in WRITE_OHIST, divide by the time:
             if ( ohist%_mu_item_%wanted ) &
               ohist%_my_item_%val  = ohist%_my_item_%val  / ohist%accumulator

Now comes the tricky part:

Modifying the ZDF header info

If your new item is a 2-d array, nothing needs to be done. For each new 3-d array, you need to add a line like

if (ohist%_my_item_%wanted) nrecs = nrecs+(km-1)

Add the actual history write. You can use the existing sections as templates. Just be sure to use the proper mask for setting the undefined value.

To keep the GrADS control file useful, you should add a control file write statement:

for 2-d:

if ( ohist%_mu_item_%wanted ) & call SENDOUT2( ohist%g,ohist%_my_item_%val(HERE), & LANDMASK,iu,ic,ZDF_UNDEF,write_control,GRADSVARLINE)

where LANDMASK is notH or notU or notV, depending on the type of variable and GRADSVARLINE is the text line to put in the GrADS control file.

for 3-d: the form is similar:

if ( ohist%_mu_item_%wanted ) & call SENDOUT3( ohist%g,ohist%_my_item_%val(HERE,:), & LANDMASK,iu,ic,ZDF_UNDEF,write_control,GRADSNAME,GRADSVARLINE)

Experienced GrADS users may want to alter the 99 to use GRIB codes, or whatever Remember that if the grads file is screwed up, you can edit it later, or you may not even need it. Dont worry, be happy!


Just add the diagnostic to DIAGNOSTICS_MODULE, and code within the model to compute it.

A final note:

If you are going to create something (as in CREATE_OHIST) please provide clean-up in DESTROY_OHIST. I have never called DESTROY_OHIST, but someday...

Module Private:

Subroutines Use

Poseidon Ocean Model (Release: c_92_rp1 )
Documentation automation by Paul Schopf's DocFort Perl scripts.