source: (poseidon.ohist.f90) [ c_92_rp1 release ]
This module provides Poseidon history processing.
After the ocean object is created, the simplest sequence for history processing is:
CREATE_OHIST INITIALIZE_OHIST loop over timesteps step model if (RINGING(some_alarm)) ACCUMULATE_OHIST end loop WRITE_OHIST DESTROY_OHIST
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
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:
ohist%STUFF%wanted = .false.
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.0in ACCUMULATE_OHIST, bump the accumulator:
in WRITE_OHIST, divide by the time:
if ( ohist%_my_item_%wanted) & ohist%_my_item_%val = ohist%_my_item_%val + function(ohist%S) * interval
if ( ohist%_mu_item_%wanted ) & ohist%_my_item_%val = ohist%_my_item_%val / ohist%accumulatorNow 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:
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.
if ( ohist%_mu_item_%wanted ) & call SENDOUT2( ohist%g,ohist%_my_item_%val(HERE), & LANDMASK,iu,ic,ZDF_UNDEF,write_control,GRADSVARLINE)
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...