Opened 10 years ago

Closed 10 years ago

#383 closed help (fixed)

complete umui beginner failing dismally with monsoon job

Reported by: sgalde Owned by: ros
Component: UM Model Keywords: MONSooN, ORCA2
Cc: Platform:
UM Version: 7.4


Hello, I'm new to the UMUI (at least in this century anyway) and I'm having problems running my first experiment on monsoon.

I've copied a colleagues job (at their suggestion) and since the model configuration is bigger and more complicated than I have run in the past in a non-UMUI regime, I wanted to simplify it. Probably a big mistake. The original job was xemgl and my copy is xefra.

I am trying to run the standard ORCA2 experiment that comes with the NEMO model. I've set this up and run it successfully directly on monsoon without the UMUI. I can submit the job to monsoon from puma ok. The problem comes in the UM build step when it comes back with a whole lot of warnings and then the message:

gmake: * No rule to make target OASIS3_conf', needed by all'. Stop.
gmake -j 4 all failed (2) at /projects/um1/fcm/lib/Fcm/ line 625

This was a bit of a surprise since I didn't think I was using OASIS.
I suspect I'm falling into the beginner's elementary trap number 1.
So any help would be appreciated.


Change History (8)

comment:1 Changed 10 years ago by ros

Hi Steven,

In UMUI panel
"FCM configuration → FCM options for atmos and recon"
you have changed "Specify revision number or keyword of base to use" from vn7.4_cfg to HEAD.

This has caused the system to pick up the list of target scripts from the trunk of the repository (HEAD) and then its got confused when it can't find the job script OASIS3_conf which wasn't introduced until UM7.5. The system always extracts all the job control scripts, whether or not it needs them.

You can either change "HEAD" back to "vn7.4_cfg", or if you're only planning to run this job on MONSooN, it would probably be more sensible to change the

"Bindings location" to $UM_SVN_URL/src/configs/bindings

and unselect the switch "Use different version of the UM code base from default for this UMUI version"

[As an aside: The VN7.4_machine_cfg branch is only needed for running on HECToR and the vn7.4_cfg revision keyword was the only way we could force the system to cooperate and pick up the correct settings.]

Let me know if you still have problems.


comment:2 Changed 10 years ago by sgalde

Thanks for that Ros.
I tried replacing HEAD with vn7.4_cfg and replacing "Bindings location" as suggested.
Both cases failed trying to extract the UM on puma.
The ext.out file looks:

Extract command started on Wed Feb  3 07:37:46 2010.
->Parse configuration: start
vn7.4: revision keyword not found for svn://puma/UM_svn/UM/trunk/src/configs/bindings/container.cfg in FCM configuration file, abort.

Looking at this container.cfg file doesn't throw much light on the problem for me.
I guess I must have changed something which is used here, but I can't see what.
Sorry to be a nuisance.

comment:3 Changed 10 years ago by ros

  • Keywords MONSooN, ORCA2 added
  • Owner changed from um_support to ros
  • Status changed from new to accepted

Hi Steven,

You'll be glad to know you haven't changed anything to cause this problem! Your fcm setup just needs to be told where to find the keyword/revision number mappings.

Create yourself a file called $HOME/.fcm on PUMA and add the following line to it:

inc ~um/fcm/etc/um_revisions.cfg 

comment:4 Changed 10 years ago by sgalde

Hello Ros. That worked a treat. I'm now the proud owner of a job that runs on monsoon.
Admittedly it fails trying to compile, but that's further than I've been before.
My next problem seems to be with fcm so feel free to tell me to go somewhere else!
(Also, I'm not sure whether you want a new ticket for this or not, so please put me right there as well)

The job on monsoon fails in the NEMO compilation.
I tried to introduce a modified version of par_oce.F90 (with IPROC, JPROC and IJPROCS) by using lines

repos::nemo::user           /home/sgalde/NEMO/SRC
src::nemo::user            OPA_SRC

in my job configuration file (panel "FCM options for NEMO").
In this directory I just have my copy of par_oce.F90.
This is the correct location, but the full code has lots of files and directories there as well.
When it gets to monsoon, fcm seems to just replace all files in the original OPA_SRC with all files in my OPA_SRC (in this case two files).
Is there anyway of getting fcm to replace single files in the code with user supplied files in this way, other than creating a new branch on the puma repository?

Steven (again)

comment:5 Changed 10 years ago by ros

Hi Steven,

Glad that's working ok.

I don't believe there is a way to get fcm to replace single files in the code using the src::nemo::user construct.

I believe that you need to have a copy of all the files under OPA_SRC in your local directory. If you don't then I think FCM therefore assumes that you have deleted them and thus only copied across par_oce.F90

Alternatively, as you said the other way is to create yourself a branch in the PUMA repository, which effectively does the same as having the full code under OPA_SRC in /home/sgalde/NEMO/SRC. Except that with the branch you get revision control.

Hope that helps.

comment:6 Changed 10 years ago by sgalde

Ros, I managed to get a job queued into the parallel queue on monsoon.
I had to extract the OPA_SRC of revision 436 (the one I use in my job configuration file) and then edit that, as you suggested.
Using the PUMA repository would be a better option for more serious work.
If it's alright for me to create my own branches, could you tell me where they should go and any naming conventions you want me to use (alternatively a user guide or web page)?
Thank you very much for all your help, and I promise not to bother you again this week!

comment:7 Changed 10 years ago by ros

Yes, please feel free to create your own branches.

Documentation is a little limited at present I'm afraid. We have some basic information on branch creation on the NEMO wiki about creating branches.

Creating NEMO/CICE branches

Looking at the UM Tutorial on creating branches linked from the above page should also help.

By default your branch will be placed under branches/dev/sgalde. This is where all of your development branches should go.

When you create your first branch you will need to add —password "" in the Other options field of the FCM GUI.

As far as branch naming conventions go fcm will prepend to your branch name either the revision keyword (say VN3.1_) or the revision number (r468_) this makes it easy to keep track of which revision number branches were created from.

There is also a generic FCM Tutorial which you may find of use too.
FCM Tutorial

Any questions let me know. It'll also be useful to have any feedback, so that I can improve the documentation for future newbies.

comment:8 Changed 10 years ago by ros

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