access_MichaelNaughtonEmail14Mar2012 - ACCESS-NRI/accessdev-Trac-archive GitHub Wiki
#!html
<h1 style="text-align: center; color: blue"> ROSE: email -- comments on Met Office ROSE experiments database plans</h1>
-----Original Message----- From: Michael Naughton
Sent: Wednesday, 14 March 2012 4:26 PM
To: 'Matthews, David'
Cc: Asri Sulaiman
Subject: FW: Plans for ROSE experiments database GUI
Dave,
Thanks for sharing your plans with us.
Here are some comments Asri and I came up with this morning:
Overall the ROSE suite database design seems like a compatible step on from the way UMUI experiment database has operated in the past, which will enable fairly smooth transition for users. That seems sensible enough way to go to us.
You don't mention it, but presumably there will be a GUI interface similar to existing UMUI experiments interface with point-and-click access to suite-xxx commands.
We don't really understand why there is a second "document-oriented database" for the suite discovery/identity info planned to be kept separate from the svn suite repository itself? Doesn't this just duplicate the same metadata? Is it a speed thing, to speed up discovery/identity functions of the rose-experiments-database-gui?
Why FCM? In general, we would like our users and developers to become familiar with using SCM package such as SVN directly, since it can also be used to help with day-to-day tasks. However, it seems there is tendency at UKMO to shield user from the full intricacy of SVN and present a cut-down, more simplified, FCM interface. What purpose is there really in having intermediate FCM layer:
rose-experiments-database-gui >> suite-commands >> fcm-commands >> svn-commands >> rose-svn-experiments-repository
We still think a general GUI interface to svn is worth further investigation, i.e. like rabbit-vcs, to enable direct browsing of svn repositories; this would probably be useful for UM and other source code repositories as well as rose experiments.
BTW: We finally got PyGTK installed on our machines here, both in the Bureau (Melbourne) and at NCI (Canberra), so we're able to start up rose config editor and gcylc. This was not so straightforward (at the Bureau) because we do not have system-level access to our machines, so we had to do user-level installs of required packages.
So, to date all we've done is look-and-see functions with config-edit and cylc, haven't tried to set up and run anything yet, but hopefully will get to start trying this fairly soon.
One area I've thought to give feedback on is separation of compile & run steps and um-reconfig & um-run steps in the design of rose suites. I was going to look more closely into the mechanics before commenting, but haven't got to do so.
In our SMS suites we separate umr and um into separate nqs job steps, even though they get relate to same umui job. We think of the umr reconfig step as one of the preparatory steps like like ancil or makebc, logically separate from the um step since it relies on a separate executable. Clearly there's link between reconfig and um steps in the requirement that their settings agree, but ideally it would be good to clarify and minimise, if possible eliminate, these dependencies (e.g. makebc doesn't seem to depend on physics settings?). I would think a rose reconfig suite could point to a rose model suite to get the variables it requires to know about.
Likewise, same thinking could be applied to the compilation and running phases for all the packages: um, reconfig, ops, var, etc. It would seem to be much cleaner to keep the compile suites separate from the run suites, since they're really quite separate steps and don't really derive any benefit from being locked together. Again, to handle the physics ifdef's (until they can be fully removed), the rose um compile suite would need to point to corresponding rose um run suite to pick up the required settings, but for the rest there's probably no compile-run dependency at all.
Some also's:
We're also interested to hear how you're progressing with rose NWP suite, including when we might be able to pick up test version to play with ourselves.
We're also putting rose developments into plans we're making for our ACCESS modelling developments, including for our ACCESS coupled model, using different ocean and land surface components to HADGEM.
We kept your file just to ourselves today, since you said it's pre-release. Colleagues from our TI area will also be interested to read your document, so there'll probably be more comments when the collab-wiki version comes through. People are happy with the way you're providing information on the development as you for interested collaborators to follow along, and interact.
Cheers,
Mike and Asri
-----Original Message-----
From: Matthews, David [mailto:[email protected] <mailto:[email protected]> ]
Sent: Wednesday, 14 March 2012 02:49
To: Asri Sulaiman
Cc: Michael Naughton
Subject: RE: Plans for ROSE experiments database GUI [SEC=UNCLASSIFIED]
Asri, Mike
I've attached some notes containing our current ideas on how we will
provide a suites database. These ideas haven't been widely exposed
within the Met Office yet but I thought I'd give you an early sight
since you've clearly been giving it some thought.
You'll see that we're planning a rather different approach to what I
think you were suggesting. Hopefully the notes explain the reasons
for this.
Any immediate thoughts before we publish these notes more widely?
I'll put them on the collaboration wiki once we've had a chance to
incorporate any initial feedback.
I'd also be interested to hear if you've made any progress with cylc
and if you've had a chance to look at the Rose examples yet?
Regards,
Dave
> -----Original Message-----
> From: Asri Sulaiman [mailto:[email protected] <mailto:[email protected]> ]
> Sent: 24 February 2012 04:16
> To: Matthews, David
> Cc: Michael Naughton
> Subject: Plans for ROSE experiments database GUI [SEC=UNCLASSIFIED]
>
> Dear David,
>
> We would be interested to find out some more about what your
> thoughts/plans are for ROSE experiments database infrastructure.
>
> Quite likely your group have considered all the various options
> already, but we would like to input our recent thoughts, with
> an element of request based on our perceived needs/desires.
>
> It would be handy to use as starting point readily available
> open source SVN GUI such as rabbitvcs http://rabbitvcs.org/ <http://rabbitvcs.org/> .
> That client is written using pyGTK and will have basic source
> management functions already done.
> Of note with rabbitvcs is that it can also be used with other SCM
> packages such as Git.
>
> We think the main window is already reasonably similar to current
> UI, so users should find it easy to switch. Beyond that, it would be
> useful to be able to group experiments in different sub-directories,
> which current UI cannot do.
>
> PS: There is a handy, nearly comprehensive evaluation of all
> GUI clients here:
>
> http://en.wikipedia.org/wiki/Comparison_of_Subversion_clients <http://en.wikipedia.org/wiki/Comparison_of_Subversion_clients>
> <http://en.wikipedia.org/wiki/Comparison_of_Subversion_clients <http://en.wikipedia.org/wiki/Comparison_of_Subversion_clients> >
>
>
> Cheers.
> -Asri
>