Revision not sync'd

General
,
1

Hello,

I have made some minor revisions to a previously working suite u-ce369 which have not been picked up. I think the committed revisions are not being sync’d, as was the case in cms trac ticket #2965 (http://cms.ncas.ac.uk/ticket/2965) on Monsoon.

My error reads:
[FAIL] svn://pumatest/um.xm_svn/main/branches/dev/leightonregayre/vn11.1_MMPPE_cloud@99255: not found
[FAIL] svn: E160006: No such revision 99255

though I have only just commited that revision number:
image

Thanks,

Leighton

2

Hi Leighton,

Yes looks like some of the mirrors on pumatest have stopped sync’ing. I’ll break the locks and set them all going again. I’ll let you know when that’s completed it may take a little while depending on how much needs syncing.

Cheers,
Ros.

3

Hi Leighton,

UM mirror repository is now up-to-date. Please try again.

Cheers,
Ros.

4

Hi Ros,

Thanks for your help. The sync seems to have worked.

Cheers,

Leighton

5

Hi Ros,

I’m not sure if this is a related problem, or something new.

I have created a new branch (fcm:um.x-br/dev/leightonregayre/vn11.1_Emission_MIP) and merged with an existing branch (fcm:um.x-br/dev/luciadeaconu/vn11.1_vn11.1_ACURE_PPE_all_diagnostics@82414), without conflicts. I then made a few minor code changes and committed them.

Running my suite returns an error in the atmos_main task that I cannot see replicated in any other cms trac tickets. The job.out file for my suite u-ce369 states ‘No IO server processes assigned’ because the ‘Configuration not IOS capable’. This sounds like a submission problem which is what makes me wonder if it is related to the earlier problem in this thread.

There are some clues in the job.err log, which might relate to cms trac tickets #3393 and #1791. Namely, that there is some write statement in the code which is too long. I have used the suite I merged with many times without error and the minor code changes I included here are not long lines at all.

Thanks,

Leighton

6

Leighton

The IOserver message is just for information. The error has come about because the suite has Extra diagnostic messages switched on - it’s ironic that asking for information itself breaks the model. There does appear to be an underlying problem that has been flagged - try setting PRINT_STATUS to Operational status… that might give a clue to what’s actually happening.

Grenville

1 Like
7

Hi Grenville,

Changing the PRINT_STATUS to Operational has allowed the suite to run nd no further errors have been flagged. I’ve reviewed the logs as they’re made. There are a few minor errors associated with diagnostics mentioned in the atmos_main task which failed previously, but nothing stands out. Was there anything specific in the earlier logs that gave you cause to think there was an underlying problem, or just the flagged error?

Thanks,

Leighton

9

well that’s irritating - sent before I’d finished:

just because a message was being written, I’d assumed it’d found a problem. Nice to be wrong.

Grenville

1 Like
10

Yes, a little irritating. But, the site did show me you were still replying, so it was clear you weren’t going to leave it there.

I appreciate the caution and am glad this strange problem is now avoided.

Cheers,

Leighton

11

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.