Fork me on GitHub


Teaching: 0 min
Exercises: 90 min
  • Are we missing any lessons in CodeRefinery?
  • What teaching material should we develop?
  • What is our broader picture?
  • Brainstorming about new lessons

Near future of CodeRefinery

  • How to get new workshop requests?
  • How to get attendee interest?
  • How to reach research groups who don’t know about this project?
  • How to get instructor interest?
  • What’s our capacity for workshops?

Brainstorming about new lessons

  • What lessons are useful and don’t exist?
  • Which of these are in the scope of CodeRefinery?
  • What is an appropriate length and level of modularity for lessons, so that they can be most easily reused and remixed?

Nordic Research Software Engineer network

  • CodeRefinery is trying to start a network of Research Software Engineers in the Nordics.
  • Nordic RSE conference in 2020. Date and location is not yet set.

Hands-on Scientific Computing

We have plenty of lessons. So does Software Carpentry, and all the rest of the Internet. Yet this still isn’t enough.

  • There is information overload. How does one know what to study?
  • How do you know which lessons are suitable to your level?
  • How do we convey the importance (and relative competence levels) to those involved in student and researcher training.

Hands-on Scientific Computing is a course idea, started at Aalto University but essentially a join CodeRefinery project, to organize existing material into different levels of competence, so that we can convey.

Hands-on SciComp isn’t actually supposed to be a course. It’s supposed to organize existing courses into a logical program for self-study and possible academic use.

Think about mis-matched courses

When have you or others been to a course which has been mismatched to the audience or expectations?

Hand-on SciComp is organized by:

  • Levels (A to F), indicating the overall level of competence. For example, C is “Linux and shell” while D is “Clusters and HPC”.
  • Modules, a small, self-contained topic which one can get begin to understand in 10 minutes and learn the basics of in 60 minutes.
  • Different types of material for different learning styles:
    • A 10-15 minute video introduction, that explains why it’s important, shows some live examples, and give a taste of what is to come
    • Link(s) to reading material, some of which can be understood in about an hour.
    • A “site-specific” column, which allows the material to be customized for different locations.

Learner personas:

  • Our initial user interviews can be found on Github. These show a strong need of a program such as HoSC.
  • A is a researcher who has just started. They have a good academic background, but not so much experience in Linux or non-academic programming. They discuss with their supervisor, who says that they should have a good understanding of the A, B, and C levels, with some experience in D. They should study this before beginning their research work.
  • B is a new student in a data-sciencey field. They are learning lots of academic skills, but don’t have the network to learn Linux or practical programming skills (this isn’t considered an academic field in this program). Without tools such as git or shell, they can’t work quickly. HoSC serves as a parallel, practical guide to students.

Short-term plan:

  • Study the levels and modules, and determine what the good set is.
  • Understand needs of other partners: how can we cover all needs without being too specific?

Medium-term plan:

  • Ideally, we won’t be making any of our own material: we’ll just link to the existing best material which is already available.
  • We’ll have to add our own framing and connecting, to express the high-level connections of the modules and practical work.
  • Where needed, we’ll fill in our material or encourage other groups to make the material we are missing.

Long-term plan:

  • Collaborative, open-project project
  • Connection to researcher training.
  • Connection to academic degree programs.
  • Promote modularization of lessons, so that they can be more easily re-used in programs like this.

Broader scientific computing plan in Nordics

CodeRefinery is just one aspect of support. We have thought of three key aspects of scientific computing that need to connect:

  • Easier to use infrastructure (e.g. computational clusters - being developed in the new NordicHPC project)
  • Training and teaching (CodeRefinery)
  • Hands-on support (Research Software Engineer network)

All of these are under development, and are somehow related to the CodeRefinery team.

Each of these three things should coordinate with the other. One favorite example is: if something about using the HPC clusters is difficult to teach, perhaps you should just fix the infrastructure so that you don’t have to teach the quirk. Problems you see during hands-on support should be relayed back to the teaching and to the infrastructure teams.

How should these be coordinated? Our current idea is to:

  • Develop NordicHPC is an cluster collaboration, not of hardware, but of sysadmin tips and tricks with a focus on usability and standardization.
  • Make CodeRefinery self-sustaining
  • Develop a Research Software Engineer network in the Nordics, with meetings and training.

Perhaps each of these can have one big yearly meeting, with each of the other two groups having a presentations and co-located events at the other two.

CodeRefinery is funded by the Nordic e-Infrastructure Collaboration, and NordicHPC probably will be as well. Thus, NeIC is a logical coordinating and funding body.

Nordics (everything in NeIC) are logical size for collaboration: local, existing connections, but we don’t want to be exclusive.

Existing organizations

What existing organizations in your locations are working on similar problems?

Key points

  • Roadmap for new lessons