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.
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
- 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.
- Our initial user
can be found on Github. These show a strong need of a program such
- 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
- 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
- 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?
- 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.
- 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
- Training and teaching (CodeRefinery)
- Hands-on support (Research Software Engineer network)
All of these are under development, and are somehow related to the
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
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
- 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.
What existing organizations in your locations are working on similar