Hi Fiona,
Thank you very much for the detailed feedback, that is really helpful for us.
Weâve noted all of your comments, but just wanted to follow up on a few points to understand your thoughts further, & also elaborate on some question you raised.
- ⌠it will be really useful to be able to see dormant suites, and ones in the register
Yes, sorry if it wasnât fully clear, but we do plan to show these: if you look to the mock-up image from my initial post here, on the âgscanâ-like side bar at the left there are some greyed-out suites listed at the bottom, with âstopâ symbols to the left, to indicate dormant suites. Otherwise, âplayâ & âpauseâ symbols for non-greyed-out suites listed convey running or held suites.
Saying that, others have suggested they wouldnât want to see those because they have so many suites that are stopped, or registered but never run, that it would be undesired âclutterâ to see them, so we will support a means to hide or filter out these, too.
- Can we have a âheritageâ colour scheme for those of us who like green=run?
I am not sure if we will have a built-in colour theme with green for the running state, but we will still support customisation for colour themes so that you could easily customise the colours as you wish.
However, whether âgreenâ should indicate ârunningâ or âsucceededâ has emerged as a point of contention over the past years! I guess generally green indicates some sort of âhappyâ state, hence either task state makes sense as green. If enough people indicate they prefer green for ârunningâ, we could change the âNormalâ default colour theme as such.
- ⌠Maybe there should be a survey of users to see what things people do or donât find useful?
Results from something like this would certainly be helpful for us to know, but sadly we doubt we could get enough people to respond to such a survey to get any meaningful results. However, we will note preferences if expressed, such as your own, & may try out a survey at some point.
What we have already done, on a similar vein, is extracted the settings set by users across the Met Office in their gcylc.rc GUI configuration files, to gauge what they find useful enough to set as their default. That was low-hanging fruit, since we auto-generated that information via a script. The results are reported here, if you are interested to see.
- I would be interested to know how the GUI will respond to a ârose suite-run --reloadâ âŚ
Firstly, the rose suite-run command itself will be migrated to Cylc, so that all suites (i.e. those managed using Rose, not just with Cylc standlone) will start up (or reload, or restart, etc., with previous such command options) with Cylc commands only.
With the above unification, & the new data provision and network layer as part of the architectural changes we are making to enable a UI in the browser, there should be no need to manually reload the suite definition. Any UI tabs open should automatically pick up on the reload.
- The one thing that I have always wanted is the ability to ârerun all failed tasks in a familyâ - this would be particularly useful for rose stem
I assume you mean to do so directly in the UI? On the command line (I have not been on the Cylc team for that long, so you probably know better than myself, but) I thought you could already do this) via the cylc trigger command (cylc trigger '*/MYFAMILY:failed')?
Relating this back to the UI, we plan to unify the UI & the command-line, so that they are more in sync, so if there is a command to interact with the suite in some way, we aim to make it so that there is a way the same can be directly from the UI (if it is in interactive mode, & not a âread-onlyâ mode we also plan to support).
- It would be nice to see some âreviewâ output - I personally dislike rose bush for various reasons, so would be interested to see what the replacement will look like
Unfortunately, our thoughts for absorbing Cylc Review into the UI are very early stage. We havenât decided how it will fit in yet, even on a higher level. We will be providing updates on our plans, so look out for these as eventually they will include a proposal for including Cylc Review. Given progress at the moment, it is possible that for the initial releases of Cylc 8, Cylc Review will remain a separate utiility.
We would like to follow up on your comment about Rose Bush (which is essentially Cylc Review under an old name, at the moment, as little has changed other than it being part of the Cylc codebase now). Do you mind elaborating on the reasons you dislike it (please donât hold back, we are aiming to get honest feedback to help us improve in future)!
- At first glance everything looks very busy on the mock-ups (and more particular the pdf is too compactly full of stuff for me to really take it in), and I think it would be much more instructive to see examples with a full NWP suite rather than an extremely simple FOOBAR suite! E.g. the bit in the graph where the task squares go in across in a line - thatâs all very well with two tasks in the family, but what will it look like with 20 tasks?
Thatâs a very good point (& sorry if the PDF is rather overwhelming, we wanted to get design concepts on a single document for ease of sharing & getting a feel for how it might fit together, but I appreciate it might not be the best format to digest).
It is difficult to balance a mock-up so that it shows essential features whilst displaying a vaguely realistic output, & we wanted to focus on the design elements, which we are hoping for feedback on, rather than attempting to display a more realistic-size suite, as it is a given that real-life suites (especially some of the mammoth ones we see here at the Met Office) will not display as nicely as a simplistic example. Also, there is only so much detail we want to, or could, manually draw out in Inkscape!
Really, to get a feel for what a realistic suite would display as, we would need to have an early-stage prototype & test it on some, ideally the most complex worst-case scenario suites we can get our hands on. That is the plan at the moment. We are currently approaching that development stage now, so it hopefully will not be long before we can do this, & we can share the results. If suites with the standard amount of tasks for a NWP suite are not viewable in the prototype in a clean, uncluttered & readable way, & canât be interacted with in a simple, intuitive way, it will be a priority to improve the prototype to make them so.
Rest assured, âtamingâ the complexity of real-life suites in the UI has been one of our main concerns from the start. We also have further ideas to try to address this to be developed later along the line (not in initial Cylc 8 versions), such as a Matrix View (as detailed here, if you are interested).
- I love the multiple suites in one window idea. At the Met Office I used the little applet on my desktop when I was running multiple suites. This layout is a great replacement for that.
Weâre glad to hear that youâd find that feature useful. We were aware that there was a desire in the community to be able to monitor & interact with multiple suites simultaneously, so tried to address that. We want to minimise the number of tabs (equivalent to separate GUI instances, as now) that people feel the need to open.
to what youâve got so far. I am impressed with your vision!
Maybe you can delete this post. Sorry for the confusion!
. Sounds all good to me.
. But yes, from the UI was what I meant.
for Rose Bush (/Cylc Review)! It may not be perfect, but some of 
, but since you are, I believe, a âpowerâ user & very kindly provided a lot of feedback I wanted to fill you on background in case you were interested.
SQLite incurs an I/O penalty when youâre querying 25+ suites on say GPFS, or at least our variant of GPFS. LustreFS wasnât much better⌠Storing the cylc-run dir on a local disk was helpful but we donât like the risk of that box dying and taking our entire run state with it.