Recap - Dumux Course 2023
Minutes of the post-course discussion:
How to improve slides
- Tone down property system and multidomain slides -> include more images and refer to advanced documentation.
- Putting in images in the beginning of a presentation brings people up to speed, invigorate interest.
- Maybe too many code snippets on the slides, also difficult to read from the back (code snippets) and understand what they do. If code is longer than 3 lines, basically useless.
- Not necessary to put whole interface of function on slides. Full signature is seen in exercise.
- Initial settings of our slides (we used to have) might be preferable, because it forces you to keep the code snippet short and clear. Never have pseudo code in README, but might be useful for slides. However, with pseudo code people might not be able to transfer.
How to handle prerequisites for the course
- Maybe have additional pre dumux-course day: how to use shell, git, WSL - maybe expect people to come with that knowledge.
- Probably cannot start at the level of explaining shell etc. - we are here to present Dumux, not the basic stuff -> maybe make slides much easier. Exercises seem to work pretty well, as they are very easy. However, people might be underwhelmed if made too easy.
- We usually overestimate audience, though level of knowledge is very diverse.
- At least a short cheat sheet for shell could be helpful, ask HLRS for material: how to use linux - might require more days than 3 days in the end.
- Prepare participants for C++/templates, tell them what knowledge we expect them to bring. Ned has some good exercises for c++, maybe do: if they can solve these exercises, then they are good to go.
- Big thing: do we want to provide basic instructions on shell, ...
How to improve exercises
- Present the solution after an exercise - that would help people follow our procedure and thoughts. Maybe cut after 1 hour of doing an exercise and tell those how are already done can do other stuff, but for those who want to see the solution, this might be helpful.
- Maybe introduce used model (equations, mathematical problem...) in the beginning of the README of an exercise and do not only show domain. However, do not force people to read these equations, make it optional, link to module, make it dropdown etc.
- Incentivise people to do the next task - make clear what you actually in a task, what do you get out of it?
- Make commands in exercise more clear, "in which folder do I have to be to execute this command?". For example, show in the first exercise, so everyone knows, how to navigate folders within the terminal, how to configure with cmake etc.
Evaluation
- It was suggested to have a continuous form of evaluation, not only on the first day - in the end it is difficult to remember what went well and what went bad on the first days.
What else to cover in the course
- Tips on how to read and deal with an error: start at top, search for red stuff. Maybe show most frequent errors and how to solve them (how to choose which ones would be the most frequent ones)? -> could be included in the part when we present the solution by ourselves. Put in errors on purpose and show how to handle them.
- Present the documentation, what we have, handbook, doxygen...
General thought and tasks
- Pure online format might be possible? But not hybrid. Online, you cannot help them that well and it is difficult to interact. People also get easily distracted.
- Introduce online forum for the course (on our website?)?
- Big task for next release: make doxygen better.