Opened 9 days ago

Closed 2 days ago

#2629 closed help (fixed)

STASHmaster_A edition trouble with reconfiguration (required filed is not in input dump)

Reported by: cbellisario Owned by: willie
Priority: normal Component: UM Model
Keywords: stashmaster, um, reconfiguration Cc:
Platform: NEXCS UM Version: 11.0

Description

Dear NCAS team,

I am currently trying to add the longwave downwelling flux from SOCRATES on bands to be saved between each time step in the UM.
I choose to add an item in the STASHmaster_A file, following (https://code.metoffice.gov.uk/doc/um/latest/um-training/stashmaster.html):

#
1| 1 | 0 | 512 |SURFACE DOWNWARD LW RADIATIONbdsW/M2|
2| 2 | 0 | 2 | 1 | 5 | -1 | -1 | 2 | 1 | 2 | 0 |
3| 000000000000000000020000000000 | 00000000000000000001 | 3 |
4| 1 | 2 | -99 -99 -99 -99 -99 -99 -99 -99 -99 -99 |
5| 0 | 1582 | 0 | 129 | 0 | 0 | 0 | 9999 | 0 |
#

and the associated

[stashmaster:code(512)]
description=SURFACE DOWNWARD LW RADIATIONbdsW/M2
help=Gridbox mean spectral downward longwave radiation at the surface.

in STASHmaster-meta.conf

I also changed in rosie um/env/Runtime controls the directory associated in STASHmaster.

However, when running, I get the error

????????????????????????????????????????????????????????????????????????????????
???!!!???!!!???!!!???!!!???!!! ERROR ???!!!???!!!???!!!???!!!???!!!
? Error code: 30
? Error from routine: RCF_RESET_DATA_SOURCE
? Error message: Section 0 Item 512 : Required field is not in input dump!
? Error from processor: 5
? Error number: 2
????????????????????????????????????????????????????????????????????????????????

I have been trying to look at the ticket associated to similar error, however, they appear to be obsolete (because linked to a previous user STASHmaster).

I have looked at https://collab.metoffice.gov.uk/twiki/bin/view/Support/UnifiedModelErrors but I could not figure out to perform an initialisation of the data to 0 (not sure where I could access the prognostic?)

The suite number is u-bb586, using the UM vn11.0, running on NEXCS.

Any hint and advice are welcome.

Thank you in advance,

Best regards,

Christophe

Change History (6)

comment:1 Changed 8 days ago by willie

  • Owner changed from um_support to willie
  • Status changed from new to accepted

Hi Christophe,

You'll need to make an entry in the "Configure ancils and initialise dump fields" table for your new STASH item. If it is not in the dump then you need to specify the source.

Regards
Willie

comment:2 Changed 8 days ago by cbellisario

Dear Willie,

Thank you for coming back to me.
Following "Configure ancils and initialise dump fields" I created a new line to initialise the values to 0. However, in the stash_req, I cannot find the new 512 item related to my stash list although it refers to the good file.

Any idea?

Thank you again,

Best regards,

Christophe

comment:3 Changed 4 days ago by cbellisario

Dear Willie,

Still related to the problem, I have been checking that:

  • in um/env/Runtime Controls, the path to the STASHmaster directory is correctly set-up,
  • the STASHmaster_A file does include my new lines written above,
  • also for the STASHmaster-meta.conf file.

However, in um/namelist/Model Input and Output/STASH Requests and Profiles/STASH Requests/New? + in 0 Primary fields, I still cannot find the new item I added.
The same happens when I try to initialise it in um/namelist/Reconfiguration and Ancillary Control/Configure? ancils and initialise dump fields

Is there some kind of limitation that makes a item numbered 512 out of read?
Is there somewhere I should have linked again the STASHmaster directory to the new file?

Because the run crush in the reconfig part by telling me the item 512 is "Required field is not in input dump!" I have good feelings that it is read at some points.

Thank you in advance for your help.

Best regards,

Christophe

comment:4 Changed 3 days ago by willie

Hi Christophe,

I think you are doing Case scenario 2: Running a suite with a different STASHmaster_A in the Met Office link you mention. You need to modify the UM STASHmaster_A.

Currently, your working copies for UM and JULES have no changes in them and are therefore unnecessary. Your SOCRATES working copy does have changes, but they have not yet been committed to the branch.

Your directory GA7.1_UM11.0_AMIP/Branch_Seq02_JULES_mod/vn5.1_Seq02_JULES_mod contains UM code with two files added STASHmaster_A_mod and STASHmaster_A_original.

I think you may have confused GA7.1_UM11.0_AMIP/Branch_Seq02_JULES_mod/um11.0_Seq02_JULES_mod/ which is a SOCRATES branch with GA7.1_UM11.0_AMIP/Branch_Seq02_JULES_mod/vn11.0_Seq02_JULES_mod which is a UM branch , which contains your modified STASHmaster. Use fcm info in these directories to see this.

I say branch loosely here. You have no branch called
vn11.0_Seq02_JULES_mod in UM or JULES or SOCRATES. So I don't know
how this directory was created. It is important not to copy working
copies you have extracted from repositories: they have embedded
repository information.

I am sorry if this seems confused. I certainly have had difficulty in figuring it out.

So I think you need to take a step back here. Read carefully the UM training notes on FCM at
http://cms.ncas.ac.uk/documents/training/April2018/UM_Introduction_Presentations.pdf.

I hope that helps.

Regards
Willie

comment:5 Changed 3 days ago by cbellisario

Dear Willie,

I figured out the problem (partially).

Following https://code.metoffice.gov.uk/doc/um/latest/um-training/stashmaster.html (To see your changes), I first changed the meta to um-atmos/HEAD and I could find the STASH added. However, this change created several problems not linked to my STASHmaster modifications. There were many configurations differences using um-atmos/HEAD causing this and the macro that is supposed to fix them did not work.

Therefore, I copied/pasted the version working (um-atmos/vn11.0) to a um-atmos/vn11.0_HEAD where I performed the previous changes on the STASHmaster_A and STASHmaster-meta.conf.

The code is now running fine and I checked that the size of the d1 array where the variables are meant to be has been increased, which is what I expected.

I do have now some segmentation fault issue related to my variable declaration to get the values back (some plumbing required), but I think you can consider this specific issue as resolved and close the ticket.

Thank you again for your time,

With best regards,

Christophe

comment:6 Changed 2 days ago by willie

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