Access Hive update: discuss flowchart of workflow for community

[chrisb13]

Meeting with @paigem and @chrisb13 notes.

Following from last chat with @aidanheerdegen, @dougiesquire, @atteggiani, @paigem and @chrisb13 (did I miss anyone?)

Chris' thoughts on workflows that are important but not currently covered on the access hive docs:

• Hosting experiment repo on Github. Workflow for users for publications. (i.e. on their own fork likely)
  Hosting experiment repo on Github. Workflow for users for publications. #934
• Hosting experiment repo on Github to share with other users (community repo).
  • make distinction between sharing a configuration (no run log) and experiment (run log)
• How to contribute a new configuration.

Suggestion:

• for @paigem to attempt the above 3 processes and see where the pain/friction points are (having started with a git clone).
• decide if above instructions should be taken from the point of view of a user that started off with a git clone from the how to run docs, or should we advise to fork first?

Scribbles:

Re: knowing where and what re-starts to use. We've started a table here for experiments (will ultimately have control experiments) -- see rendered version

Experiment info:

• https://forum.access-hive.org.au/t/access-om2-control-experiments/258
• https://forum.access-hive.org.au/t/esm1-6-spin-up-experiments/4219
• https://github.com/ACCESS-Community-Hub/access-esm1.6-dev-experiments (example community repo where development community can contribute -- see README for workflow)

For another day...

• Contributing to CM3, OM3, ESM3 .. development
  • bug (example)
  • creating a new configuration (example)
  • join technical discussions / suggest a feature (example)
  • analysis / evaluation (example 1 and 2)
• Modifying the docs (example)
  • which ones

--

Related:

• General how to use Payu Docs #978
• Hosting experiment repo on Github. Workflow for users for publications. #934
• Possibly confusing "restart" behaviour with flag in config.yaml #955
• https://forum.access-hive.org.au/t/payu-a-workflow-manager-for-some-access-models/1098/5

[atteggiani]

Thank you for this issue @chrisb13.

I think your points are important, and I have suggestions for some of those:

#934 (comment) (i.e. on their own fork likely)
#934

As I suggest in the related issue, I think this workflow would be suitable for a tutorial to be added in the Tutorials page (which we might want to rework and improve).
Note: to me the second point is very similar to this one, and would be covered by the same tutorial.

Contributing to CM3, OM3, ESM3 .. development

This might be a bit more difficult for the Hive Docs, as depending on the model, their policies / suggested development workflows / related information might be very different. I think all the things you mentioned are important and they would be best placed within the respective config docs.

Modifying the docs

I agree this is very important information that needs to be improved. We are working on an improved version of "How to contribute", and I think this could be very similar for all docs (Hive docs, config docs, tool docs, etc.) and be placed in all docs websites.
The Hive Docs team is more than happy if anyone wants to help writing contribution instructions that could be placed in the "How to contribute" section of the websites. I think it would be good to have a common vision and structure for the page, so it's important to understand the needs and preferences for contributions of multiple teams (hive docs, config docs, tools)

[chrisb13]

Thanks @atteggiani, just to quickly mention, I was still editing the post/minutes when you replied. There's a few more points in the post now. :)

[atteggiani]

@chrisb13 Do we have an update on this? Anyone wants to be assigned to it?

[chrisb13]

Thanks @atteggiani. Yeah, I wrote an email to you @paigem @heidinett etc about it last Friday but haven't heard back?

As I mentioned (tweaks for typos)

I'd be happy to provide the general concepts/overall steps and then I think it would actually be good if someone less familiar with the finer details wrote it up as they're better placed to write instructions intended for someone starting out. Once we have rough drafts available we'll be able to see how they relate to someone that's started their journey with a "how to run a model" doc and where there's friction/pain points.

@helenmacdonald has highlighted that some of these instructions already exist so it's a matter of it being consolidated and having a home somewhere on the hive docs. I gather sharing/publishing configurations would be useful for regional users @helenmacdonald?

[helenmacdonald]

@helenmacdonald has highlighted that some of these instructions already exist so it's a matter of it being consolidated and having a home somewhere on the hive docs. I gather sharing/publishing configurations would be useful for regional users @helenmacdonald?

Yep - they are currently using the instructions from the hive forum, although some are following a different method for uploading their configs. It makes it easier for us to help with debugging if there is a simple way to encourage someone to upload their configuration. The instructions are here (with the prerequisite setup here) - I have tested them on regional mom6 configs only

[chrisb13]

Thanks @helenmacdonald. Related but not the same, if one wants to share an experiment on the ACCESS-Community-Hub then there are README instructions here:
https://github.com/ACCESS-Community-Hub/access-esm1.6-dev-experiments

So it's just a matter of consolidating these instructions together and carefully covering the specific use cases.

(This is related to sharing a configuration versus an experiment make distinction between sharing a configuration (no run log) and experiment (run log) mentioned earlier and hosting something for publication.)