Opened 12 years ago

Closed 11 years ago

#211 closed help (fixed)

HadCM3 job + 19 tracers as new prognostic fields

Reported by: salvatore Owned by: jeff
Component: UMUI Keywords: umui, UM
Cc: Platform:
UM Version: 4.5

Description

I have to run a HadCM3 job (xdocc) on hector which includes in the modset ENTR.f the use of 19 tracer fields as new prognostic fields. I have already done it for a FAMOUS job (as xdoic) and there it works.

The files included are :
modsets ENTR.f and noadv.f

STASHmaster file: 20trancil4.5

and in "Script Inserts and modifications" the file: mkprimary19.

The run fails and there must be some mistake in the reconfiguration I can't see.

I am going to attach all the files I have mentioned.

Many thanks in advance

Salvatore Pascale
University of Reading, Department of Meteorology.

Attachments (7)

ENTR.f (42.0 KB) - added by salvatore 12 years ago.
first modset
noadv.f (2.0 KB) - added by salvatore 12 years ago.
second modset
20trancil4.5 (8.6 KB) - added by salvatore 12 years ago.
STASHMASTER
mkprimary19 (320 bytes) - added by salvatore 12 years ago.
script inserts and modifications
MAX_LEN2 (89 bytes) - added by salvatore 12 years ago.
trial.f (776 bytes) - added by salvatore 12 years ago.
trial.sm (1.0 KB) - added by salvatore 12 years ago.

Download all attachments as: .zip

Change History (17)

Changed 12 years ago by salvatore

first modset

Changed 12 years ago by salvatore

second modset

Changed 12 years ago by salvatore

STASHMASTER

Changed 12 years ago by salvatore

script inserts and modifications

comment:1 Changed 12 years ago by jeff

  • Owner changed from um_support to jeff
  • Status changed from new to assigned

Hi Salvatore

The error is here (from your .leave file)

 ERROR : Reconfiguration CONTROL
 MAX_LEN2_LOOKUP_OUT is not big enough
 MAX_LEN2_LOOKUP_OUT=  500
 LEN2_LOOKUP_OUT=  535
 MAX_LEN2_LOOKUP_OUT should be at least as big as LEN2_LOOKUP_OUT.
 You will need to reset the PARAMETER statement in the C_ITEMS comdeck.

You need to create a mod file containing these lines

*ID CITEMSFIX
*DECLARE C_ITEMS
*D GDR1F401.2
      PARAMETER (MAX_LEN2_LOOKUP_OUT = 535)

and put it in the reconfiguration mods umui window.

Jeff.

comment:2 Changed 12 years ago by salvatore

Hello,
I have created the file MAX_LEN2 and inserted it in reconfiguration umui window. This time the job (xdocc) is compiled (that is already an improvement) but gets stuck at the first timestep. Segmentation fault is got.

Salvatore

Changed 12 years ago by salvatore

comment:3 Changed 12 years ago by salvatore

The job xdocc still does't work. Segmentation fault is obtained at the first timestep even though the same modset ENTR.f works ok on FAMOUS. Is there due to another bug in the code?

Salvatore

comment:4 Changed 12 years ago by jeff

Hi Salvatore

The model crashes in routine DIF_CTL. If you look at your mod ENTR.f there is this code

*/ 
*/ Include THETA_AD in call to DIF_CTL to diffuse this field
*/ 
*I ATMDYN1.622
     &       THETA_AD,

which changes the call to dif_ctl in the atm_dyn routine

      CALL DIF_CTL(
     &          D1(JPSTAR),D1(JU(1)),D1(JV(1)),D1(JTHETA(1)),D1(JQ(1)),
     &       THETA_AD,
     &          RS_FUNCTIONS,DIFF_COEFF,DIFF_COEFF_Q,
     &          DIFF_EXP,DIFF_EXP_Q,
                              .
                              .
                              .

but if you look at the dif_ctl code you have

      SUBROUTINE DIF_CTL
     1                  (PSTAR,U,V,THETAL,QT,RS_SQUARED_DELTAP,K1,K2,
     2                   KEXP_K1,KEXP_K2,
                              .
                              .
                              .

So there is no corresponding mod to add the extra variable in the dif_ctl routine.

Jeff.

comment:5 Changed 12 years ago by salvatore

I understand this point, but I wonder why this has not caused any problem when the job was run on FAMOUS (for instance job xdoic) using the same modset. If it is a problem of syntax, shouldn't the run crash always?

This modset has been given to me by Bob Plant, who said it was well tested. So maybe I should point him out this problem and see if he has had any problem when running it on HadCM3.

If the problem is the one you mention, is there any way to pass theta_ad correctly to the subroutine
dif_ctl (for instance in place of thetal)?

Salvatore

comment:6 Changed 12 years ago by jeff

Looking closer at mod ENTR.f, there is some code to modify DIF_CTL to pass the variable THETA_AD, but this is for deck DIFCTL1A which is what famous uses, but your HadAM3 job uses deck DIFCTL1C which isn't modified. You can either change ENTR.f to do the same mods to DIFCTL1C or switch to using DIFCTL1A in HadAM3 as well. The latter option is simpler and shouldn't make much difference to your run. The only difference between the versions is 1C is an optimised version of 1A, they are scientifically equivalent. To change version goto umui window

Atmosphere -> Scientific Parameters and Sections -> Section by section choices -> Diffusion and Filtering

and select version 1A. You will need to recompile the code.

Jeff.

comment:7 Changed 12 years ago by salvatore

Dear Jeff,
now after the modification you suggested, the job runs fine. But there are still problems. In fact when I look at the output ppfile xdocca@pym90c1 in /work/um_archive/xdocc to see how the fields look like by xconv, I see that all the all the new fields I have added to the diagnostics (not only the 19 tracer, but also the fields from STASHCODE=2300 to 2311 for instance, that are diagnosed without adding further prognostic fields) hace the same value of the pressure at the surface (STASHCODE 1).
To check if this were a problem just of processing or not, I have put a print statement and seen that the calculations are done properly, hence it must be an error of processing somewhere I can't see. The only difference I notice is that in the STASH panel ATMOS, all the given fields have the inclusion of a package A, but I don't know how relevant it is.

From tomorrow until the beginning of the next year I will be away from Reading so probably I will not be able to work on this, but I will go back on it as soon I will be in Reading again.

Many Thanks
Salvatore

comment:8 Changed 12 years ago by salvatore

The problem I mentioned the last time seems to be related with STASH. As my supervisor J.Gregory has advised me, in the job xdocz I have used a very simple diagnostic (STASHCODE=5300) just coping the temperature field and outputting it trhough stash. I still get the values of the diagnosed field equal to the values of the surface pressure at all vertical levels. So this looks like a very general problem related to the use of stash in the atmosphere model of HadCM3 on hector (probably a bug).

I attach the files about the very simple diagnostic used to point out that the problem is not in added code but in the processing.

Many thanks in advance,
Salvatore Pascale

Changed 12 years ago by salvatore

Changed 12 years ago by salvatore

comment:9 Changed 11 years ago by jeff

Hi Salvatore

I ran your xdocz job and can reproduce the problem. The affected fields (5300) have pp header records but the size of the data in the file is 0 bytes. Xconv isn't setup to handle this case and for some reason decides to plot the first field in the file, which in this case is surface pressure.

The problem seems to be caused by the time profile you have used in the STASH panel, TDAYMN. In this profile you have set the field as a daily mean but are outputting it, to the climate meaning system, every dump period (180 days), this mismatch seems to cause the problem. Every other climate mean field in the STASH panel uses TDMPMN or TDPMN4 and if I change your diagnostic to use TDMPMN then it works as expected. I suggest you change all your climate mean diagnostics to use TDMPMN, unless there is some reason you wanted to use the setup in TDAYMN???

Jeff.

comment:10 Changed 11 years ago by jeff

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