Opened 8 years ago

Closed 8 years ago

#821 closed help (fixed)

Compilation error after adding subroutines for nudging

Reported by: watson Owned by: willie
Component: UM Model Keywords: fcm
Cc: Platform:
UM Version: 6.6.3

Description

I am trying to create a branch of UM6.6.3 to implement nudging of the zonal wind. I am essentially trying to port code developed for UM7.3 at UM/branches/dev/mdalvi/VN7.3_nudge_new, which should be possible as the nudging code is fairly standalone and is implemented using a folder of subroutines and some changes to the top level control routines. I have created a 6.6.3 branch and made what I think are the necessary changes, but my job fails during compilation with error message:

gmake: * No rule to make target nudging_main1.done', needed by atm_step.done'. Stop.

My branch is UM/branches/dev/watson/r5321_nudge_new. I made this using the script /usr/local/bin/create_HG2_branch on Puma (which took options then executed the command fcm br —create —branch-of-branch —name nudge_new —revision HG6.6.3_CFG —type DEV::USER fcm:um_br/pkg/Config/HadGEM2-ES).

I then made a new directory src/atmosphere/nudging using "fcm mkdir" and copied the nudging routines to here using "fcm cp". I made changes to files src/control/top_level/atm_step.F90, src/control/top_level/readlsta.F90, src/include/common/cntlatm.h and src/include/common/cruntimc.h analagous to those in the UM7.3 code (which basically involved copying some extra lines over). I committed these changes and the branch looks correct in trac.

The problem seems to relate to the part in atm_step.f90 which calls the routine nudging_main1 at line 7776, which is in the file src/atmosphere/nudging/nudging_main1-nudging_main1.F90 (this is the top level routine in src/atmosphere/nudging):

! DEPENDS ON: nudging_main1

CALL nudging_main1 (

Essentially I do not see why the compiler is unable to link the nudging subroutines to atm_step.

I created the branch r5321_test_add_file to test adding a simple subroutine contained in a new file called from src/control/top_level/um_shell.F90 and one in a new folder (in a similar way to the FCM tutorial exercise), and this compiled successfully. I don't see what is different here that made this successful.

Change History (17)

comment:1 Changed 8 years ago by ros

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

Hi Peter,

Unfortunately the branch you have created has been created at the wrong point. One tip - When you create a branch for a UM version it should always be prefixed with the UM version e.g HG6.6.3_branch name. So if you get anything else, like r5321_branch_name something has likely gone wrong somewhere.

Can you try re-creating the branch using the create_HG2_branch script but when it asks for the version select the option next to HG6.6.3 (NOT HG6.6.3_CFG) this will then create the branch from the correct point.

Full details on creating a branch for HadGEM2 are available here:
http://puma.nerc.ac.uk/trac/UM/wiki/FrequentlyAskedQuestions#how-do-i-create-a-HadGEM2-branch

If you still have problems with it compiling the nudging code having recreated the branch then please let me know and I'll take a look.

Cheers,
Ros.

comment:2 Changed 8 years ago by ros

Hi Peter,

I also wouldn't use "fcm mkdir" or "fcm cp" - I've never used these commands so not sure how robust they are. I remember using "fcm move" once and it caused no end of problems - so I would recommend avoiding their use.

I think it would be safer to checkout a working copy of your new branch and use the usual unix mkdir/cp to create the directory and copy the files you need into the new directory from an exported copy of VN7.8_nudge_new (fcm export fcm:um_br/dev/mdalvi/VN7.3_nudge_new).

Then run "fcm add" and "fcm commit" to lodge these new files into the repository.

Cheers,
Ros.

comment:3 Changed 8 years ago by watson

Thanks Ros for the prompt replies. Funnily enough I selected the HG6.6.3 option in the first place, but then switched to HG6.6.3_CFG after seeing that in the FCM Options for the job (which is a copy of the example HadGEM2 job xgadb) it gives hg6.6.3_cfg as "User's own version of the trunk", which I thought meant I had to branch from that. I created the branch for version HG6.6.3 in the way you suggested (UM/branches/dev/watson/HG6.6.3_nudge_new) and this gives the same error during the compilation. By the way my job is xhbfe and the compilation output is in ~watson/um/umui_out/xhbfe000.xhbfe.d12076.t150453.comp.leave on Hector.

Cheers,

Peter

comment:4 Changed 8 years ago by ros

Hi Peter,

Ok I can see what's happening. If you look at the preprocessed code under /home/n02/n02/watson/xhbfe/ummodel/ppsrc/UM/atmosphere/nudging you will see that all the files are empty. This is because all the code in these files is surrounded by "#if def A39_0A" or "#if def A39_1A" and since this is a new section the relevant defs aren't set by default in the UMUI. Without having one of these defs set you are effectively saying "I don't want this section code".

Now I've not done this myself before, but I think you just need to add the extra def to the list setting of %jobdefs in FCM_UMUI_MODEL_CFG, for example, A39_1A=a39_1a.

%jobdefs \
   CONTROL=control \
   REPROD=reprod \
   ATMOS=atmos \
   GLOBAL=global \
   A04_ALL=a04_all \
   UM_RUN=um_run \
   A01_3Z=a01_3z \
   A02_3Z=a02_3z \
   A03_9A=a03_9a \
   .....
   A39_1A=a39_1a

If you want to run a quick test to check this does fix the problem, you could just edit the FCM_UMUI_MODEL_CFG file after processing the job and then submit to compile. If that does work,
then you'll need to create a hand-edit. I assume Mohit would have done this to use this new section at VN7.3 so it may be possible to just use his hand-edit or at least use it as a basis….

Hope that makes sense. If you need any help, let me know.

Cheers,
Ros.

comment:5 Changed 8 years ago by watson

Thanks again Ros. With that change the model compiles, but fails to run, with the following error message:

Mismatch in no of prognostic fields.

No of prog fields in ocean dump 968
No of prog fields set up by UI 970


Run RECONFIGURATION to get correct no of prognostic fields in ocean dump
or
Check/Reset? experiment in User Interface


Failure in call to INITDUMP
*
UM ERROR (Model aborting) :
Routine generating error: INITIAL
Error code: 202
Error message:

INITDUMP: Wrong no of ocean prognostic fields

*

The problem is not fixed by reconfiguring the start dump. I'm guessing the problem may be related to the introduction of the new STASH section. The code was originally developed for the atmosphere-only configuration I think, so I wonder if including the coupled ocean creates problems. Is there anything obvious to try or should I contact the people who developed the original code?

Cheers,

Peter

comment:6 Changed 8 years ago by watson

An example .leave file is ~watson/um/umui_out/xhbfe000.xhbfe.d12076.t200900.leave

Cheers,

Peter

comment:7 Changed 8 years ago by willie

  • Owner changed from ros to willie
  • Status changed from accepted to assigned

Hi Peter,

The problem is that you are asking for two fields that are not in the ocean start dump. You should check that all the items in Ocean GCM > STASH > initialisation of user prognostics are in the ocean dump. I suspect two won't be. Then you need to decide whether you need them and if so how to initialise them in that table.

regards

Willie

comment:8 Changed 8 years ago by watson

Dear Willie,

Thanks for your response. I've been trying to track down the problem. My job xhbfe will run except when the FCM branch which contains the nudging code fcm:um_br/dev/watson/HG6.6.3_nudge_new/src and hand_edits ~watson/umui_jobs/hand_edits/nudg_on_L60_hector.ed and ~annette/hadgem3/hand_edits/load_netcdf.ed are included. The job will compile when I amend FCM_UMUI_MODEL_CFG as Ros suggests above, but gives the error relating to the ocean start dump above. My job xhbfc is essentially this job without these FCM branch and hand edits.

The hand edit ~watson/umui_jobs/hand_edits/nudg_on_L60_hector.ed adds some STASH items to the atmosphere output, but I cannot see why the ocean component should be affected. Looking through the files created by job processing in ~watson/umui_jobs/xhbfe and ~watson/umui_jobs/xhbfc, the only file with substantial differences is STASHC which contains extra diagnostics for the nudging, starting at "### Start of Nudging Diag Macro. ###" - if this is what is causing the problem, how to I stop the inclusion of these diagnostics affecting the ocean?

I also noticed that ~watson/umui_jobs/xhbfe/EXT_SCRIPT_LOG contains the message "ERROR executing Nudging Hand_Edit", but I don't know why. I think the edit to FCM_UMUI_MODEL_CFG suggested by Ros above should have been made by the script, but was not for some reason.

Sorry for my inexperience with dealing with these problems and thanks for any help you can give.

Cheers,

Peter

comment:9 Changed 8 years ago by willie

Hi Peter,

You need to check the hand edit,

~watson/umui_jobs/hand_edits/nudg_on_L60_hector.ed

It does seven things (!) and sets variables e1, …, e7 and the checks them at the end to see if an error occurred. One or more of them has complained. You should test them individually and print an unique error message to locate the error.

Regards,

Willie

comment:10 Changed 8 years ago by watson

Hi Willie,

I got the hand edit working properly - it was failing in one place where it essentially was making the edit that Ros suggested, but it started by searching for a line which doesn't exist. Having fixed this, I still get the same error as before.

Cheers,

Peter

comment:11 Changed 8 years ago by willie

Hi Peter,

Is the job xhbfe supposed to run the executable from xhbfc? If so you need to point to the executables for that job in Compile Options for the Model. You may need to run xhbfc again now that you've fixed the hand edit.

On the Ocean GCM > Control > Post Proc > Dumping and meaning page, of you tick "defining a meaning sequence", then all the STASH errors will magically disappear. The errors reported by the UMUI for epflux606 can be ignored - they're not really errors.

Regards,

Willie

comment:12 Changed 8 years ago by watson

Thanks Willie,

xhbfe has its own executables. I implemented your suggestion and the error is still the same.

Cheers,

Peter

comment:13 Changed 8 years ago by willie

Hi Peter,

In the Compile options for the model pane, you need to tick the box "compile and build the executable named below, and run". You don't need to force a full FCM build.

You have not been building the model. The last build is in /home/n02/n02/watson/xhbfe/ummodel/bin and took place at 11:01 on the 21st march. This is repeatedly copied to the work directory on each subsequent run. If you look for "OK" in the comp.leave file, you can see what it has built.

Regards,

Willie

comment:14 Changed 8 years ago by watson

Hi Willie,

I set the compilation not to run on just the last job to save time since I didn't think changes to the executables needed to be made and this would save time. I made the changes you suggested and the error is still the same.

The job will run if the additional FCM branch and hand edit are not included. Is this not an indication that the problem lies with one of these things rather than something that can be adjusted in the UMUI? The nudging code is called from the routine atm_step.f90 and it acts to adjust the atmospheric u, v and T, so it doesn't seem to me likely that the code itself would be interfering with the ocean component. At the moment the hand edit makes changes to files CNTLATM, FCM_UMUI_MODEL_CFG, SIZES, RECONA, PRESM_A and STASHC (in ~watson/umui_jobs/xhbfe). So which of these changes might the ocean component care about? As far as I can see, CNTLATM, RECONA and PRESM_A only affect the atmospheric component. The change to FCM_UMUI_MODEL_CFG is just the one Ros suggested above - this doesn't prevent the job from running when the FCM branch and hand edit are not included. This leaves SIZES and STASHC. Can you see any changes to these files the hand edit is making which would affect the ocean component? I was wondering if there is anything to say the changes to STASHC should only apply to atmospheric STASH, or whether the model is trying to apply these changes to the ocean component as well?

Or are any of my ideas above incorrect?

Cheers,

Peter

comment:15 Changed 8 years ago by willie

Hi Peter,

We're down to the hand edit or the branch. If you are sure that the branch does not modify any ocean code, then it must be the hand edit. I notice that there is a comment "Could be dangerous as atmos_sr contains section defs. of other sections" in the hand edit. I would suggest examining this further.

Regards,

Willie

comment:16 Changed 8 years ago by watson

Hi Willie,

I'm afraid I'm a little stuck on how to proceed. I don't really understand what the commands relating to STASH written by the hand edit mean (apart from that they are basically adding variables to be output), and I cannot find any documentation explaining this, so I don't know what changes I should try making in order to stop the ocean sub-model being affected.

Cheers,

Peter

comment:17 Changed 8 years ago by willie

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