Opened 10 years ago

Closed 8 years ago

#591 closed help (fixed)

meaning over days and hours

Reported by: salvatore Owned by: jeff
Component: UMUI Keywords: daily means, 12-hour means, 6-hour means
Cc: Platform: <select platform>
UM Version: 4.5

Description

Hi,
I have this problem with the umui. In job xfule I use daily means defined via TDAYMNA together with the usage profile UPA. In the job xfulj (or for example xfulk) I use 12-hour (or 6-hour) means defined via T12HR (or T6HRMN) always together with the same usage profile UPA. These runs have the same start dump, same target run lenght (1 year, 0 hours, 1 hour). However when I work out the mean surface temperature over the year I got slightly different numbers whereas I should get exactly the same number as the period is the same.

I also have produce 2-day means, 5-day means etc. (job xfule, xfulf) and seasonal and annual means (xfuld) and they all give me the same mean surface temperature ovet the year, as it should be. So I suspect that problems start when I consider 12- and 6- hour means. I really can't see what I do wrong.

Many thanks for consideration,
Salvatore

Change History (14)

comment:1 Changed 10 years ago by salvatore

Hello,
I think I can reprhase my question in simpler terms: Once I have defined TDAYMNA, T12HR, T6HRMN and UPA, how should I define the target run length in order to all the means coverinf exactly the same time period and thus exactly the same mean values for the fields?

comment:2 Changed 10 years ago by jeff

  • Owner changed from um_support to jeff
  • Status changed from new to accepted
  • UM Version changed from <select version> to 4.5

Hi Salvatore

Looking at experiment xful jobs j,k have restart dumps every 180 days whereas all the other jobs have restart dumps every 45 days. Having a different restart dump frequency will give different model results, this would explain why jobs j,k give different values for the annual mean.

Jeff.

comment:3 Changed 10 years ago by salvatore

Hi Jeff,
so now if you have a look at jobs xful-i,j,k they have the same target run length (1 year and 1 day), same start dump, same dump frequency (45 days).
In job i I use 15-day (T15DYMN) means together with UPA.
In job j I use 12-hour means (T12HR) with UPA.
In job k I use 6-hour means (T6HRMN) with UPA.

Job i produces annual, 6-month, seasonal and 15-day means.
Job j produces annual, 6-month, seasonal and 12-hour means.
Job k produces annual, 6-month, seasonal and 6-hour means.

When you work out the means surface temperature for this outputs, you get two different numbers (one for the i-means, one for the j- and k-means). Somehow it seems that effectively two different run lenghts are considered if either hour- or day- means are considered. Maybe the target run length should be changed a little bit or add few hours to it (1 year 1 day few hours).

Many thanks
Salvatore

comment:4 Changed 10 years ago by salvatore

Hi Jeff,
the problem is still there but I have found a (obvious) way to bypass it and go on with my work:
I define (jobs xfulx,xfuly in T24HR and T240HR) the 1-day, 2-day,…,15-day means in terms of hours as well (i.e. as 24-hour, 48-hour, ….360-hour means) which now I see it's fully consistent with jobs xfulj, xfulk (12- and 6- hour means). Also the climatological means defined via TDAYMN and UPMNEAN (seasonal, annual, etc.) give consistent results.

So it really seems that what makes the difference is using the day in place of thr timestep, which is still something puzzling. Anyway thanks a lot for your help.

Salvatore

comment:5 Changed 10 years ago by jeff

Hi Salvatore

Looking again at your jobs I have noticed that the ocean restart dump frequency also has different values in different jobs. Sometimes its 45 days, sometimes 180, you should also make this the same for all your jobs as this may also affect the results.

Jeff.

comment:6 Changed 10 years ago by salvatore

Hi Jeff
what you said is right, you must have the same restart dump frequencies to get consistent results. Now I have another problem. I want to get 10-day means but, this time, for ocean fields. The job is xfulp. I have defined a time profile called T10DAYMN which can seen in the stash panel. But there must be something wrong. First the output I get are pp files of the form xfulpa#pb000006497jn+ which look like atmospheric files (because of thw "a"). More seriously the fields inside these files are empty. This must be due maybe to this error I can read with CNTRL -v "You have not reserved this unit number for diagnostics in partition O" but I don't what to do to fix this problem.

Second problem it seems that the averaging is not done as it should: in fact the only field which is not empty is ss(oc=101) (potential temperature) and when I look at it over the year what I have output steadily increases, as if it was accumulated and not meaned.

So my question may be rephrases more generally: what should I do in order to get these 10-day means properly for *ocean fields*? I tried to do the same I did for the atmosphere, but something went wrong.

Many thanks Jeff

Salvatore

comment:7 Changed 10 years ago by jeff

Hi Salvatore

Go to umui panel

Sub-Model Independent→Post Processing→Initialization and processing of mean & standard PP files

and make sure the PP units you have assigned to the ocean STASH have an O in the Sub Model Name column. In your case unit 61 needs an O. You cannot use the same unit for both atmosphere and ocean so always verify both STASH panels to check this, your atmosphere STASH doesn't use unit 61 so this job is fine.

Fix this in your job first and see if it fixes the other problem, if not I will look at this further next week.

Jeff.

comment:8 Changed 10 years ago by salvatore

Hi Jeff,
I put an O and now the pp files are of the right form xfulpo#pb000006497jn+ but still most of the fields that should be in it are empty except very few (oc=101, 30503,30502) whereas all the others (from 30401—> 30415 and from 30431 —>30444) are empty (they have -1.0737e+09 at all points, i.e. the mdi), although I have defined time,space and usage profiles in the same way for all of them.

Salvatore

comment:9 Changed 10 years ago by salvatore

Hi Jeff
as I told yoy now the fields I diagnose are not empty, which is a step forward, but still there is the other problem, i.e. the the averaging is not done as it should: in fact if a look for instance at ss(oc=101) (potential temperature) , it steadily increases, as if it was accumulated and not meaned over the year (here I define 10-day means, so I should also be able to see the season cycle, but I just see a monotonic increase over the year). For the definition of the profiles I followed what done for the atmosphere, but there must be something fundamentally different with the ocean.

Salvatore

comment:10 Changed 10 years ago by jeff

Hi Salvatore

Can you point me to where your 10 day mean output is on hector, I can't seem to find it.

Jeff.

comment:11 Changed 10 years ago by salvatore

Hi Jeff
I moved the output in the directory:

/home/n02/n02/swr07sp/work/xfulp_data

where you can fine the files with the 10-day means.

Thanks
Salvatore

comment:12 Changed 10 years ago by jeff

Hi Salvatore

I ran your job (xfulp) and got some instantaneous potential temperature fields out. These look to have increasing values, so I don't think there is a problem with the STASH temporal averaging but a basic problem with your job which causes the values to increase.

Jeff.

comment:13 Changed 10 years ago by salvatore

Hi Jeff
you're very right about that, but the point is that the problems are cause by the fact that I want to use STASH for day-means. I have done a check: job xfuln and xfulo differ only in for the fact that in xfulo I wanted to get 5-day means of potential temperature ss(oc=101) (you can see the TIME profile T5DYMN, USAGE profile UPO). Moreover in xfulo I have also excluded the modset ocean_qt.f whereas I included it in xfuln (just to check that it is not that causing problems). I found that the temperature keeps increasing in xfulo but it's absolutely normal in xfuln: this means simply that the use of T5DYMN+UPO interfeers with the model in a way it shouldn't. But if this happens, how should I do to diagnose any oceanic quantity on a for daily means??? I have tried in a way similar to what I did for the atmosphere, but why for the ocean there are all these problems?

I guess that if we can find out just how to get say 5-day means for potential temp (101) then we've sorted out the problem.

Thanks
Salvatore

comment:14 Changed 8 years ago by jeff

  • Platform set to <select platform>
  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.