Lukasz KaczmarczykI’m stuck! How to efficiently debug computational solid mechanics models so you can enjoy the beauty of simulations.
https://doi.org/10.1016/j.euromechsol.2022.104845
https://doi.org/10.1016/j.euromechsol.2022.104845
Jed Brown@likask Fun. I think a more concrete guide is needed for specific software. I may be totally wrong, but I feel like the audience who can interpret the abstract stuff here and efficiently act on it using code/run-time diagnostics also knows most of these techniques. But it's great that papers like this are being written.
@jedbrown
Agreed. The paper is not for us, it is too late, but I will recommend it to students. Fixing the error is not usually a problem; finding where it is the most difficult.
Also, you are right that creating codes have certain ways of doing things. Codes should be designed to make funding errors easy. You should be able to dissect code and test bits independently. Productivity is as important as efficiency, if not more, especially in research codes. But you know that very well.
@likask Indeed, we aren't the audience, but my concern is that it's too abstract for most students who need to solve a specific problem. Maybe what's needed are debugging vignettes with a sequence of diagnostics/reductions and interpretation along the way to identify specific bugs. Sometimes "war stories" are more visceral and memorable than a diagram of abstract interactions.
@jedbrown That is tricky; how should we teach this? Some stuff you can learn in combat.
Teaching someone coding computational mechanics, you should start with the question, how would you test code? Not the whole thing, but parts, e.g. conformity of approximation, approximation, integration scheme, matrix sparsity, etc. That will make a fundamental imprint on the design.
Being a bit extremist, if you have to look for symptoms, that is an indication problem with the behind, i.e. design.
jeremylt@jedbrown @likask
Its my impression that plenty of students get the gist of an abstract overview pretty well, especially with a good explainer, but then the leap from the abstract to the the implementation details is a big gulf to bridge. I've found 'war stories' helpful to a degree, but I feel like nothing is as effective as going on a bunch of bug hunts yourself.
Its my impression that plenty of students get the gist of an abstract overview pretty well, especially with a good explainer, but then the leap from the abstract to the the implementation details is a big gulf to bridge. I've found 'war stories' helpful to a degree, but I feel like nothing is as effective as going on a bunch of bug hunts yourself.
Jed Brown@likask @jeremylt Part of my wants to teach by asking students to implement things within big packages, but the difficulty of that task varies so widely with preparation and it invariably touches code quirks that we're not proud of (and have no pedagogical value), so my assignments are generally narrowed down (usually to writing key bits of code within a notebook, creating figures and writing captions) so there are guardrails.
@likask @jedbrown
I've seen this discussion about the difficulty in learning to build and debug large projects in different contexts (freeCodeCamp, industry junior hires, ect). I agree that having our big packages in C/C++/Fortran makes this harder, but I assume that students find these skills hard to learn in Julia/Python/Rust based projects too. I feel like students who get to build a package are lucky - their skills scale with project size/maturity. That's hard to give every student though.
I've seen this discussion about the difficulty in learning to build and debug large projects in different contexts (freeCodeCamp, industry junior hires, ect). I agree that having our big packages in C/C++/Fortran makes this harder, but I assume that students find these skills hard to learn in Julia/Python/Rust based projects too. I feel like students who get to build a package are lucky - their skills scale with project size/maturity. That's hard to give every student though.
@jeremylt @likask It takes constant vigilance to ward off incidental complexity. Language and tooling can help to some extent, but new language + new math concepts + implementation is already a lot even if the tooling is great. But that's gotta be an explicit goal if we're building tools for learning or to be easy to contribute too. Plus equally-important social factors.
@jedbrown @jeremylt The design process of splitting complexities, abstraction levels, etc., strongly depends on who are dedicated users, who are developers, and how big the team is. In bigger teams, and communities, the fundamental is how you would manage communication pathways; you have to limit the necessity of talking everyone to everyone. That imprints on the induction process length. In the case of students, you try to shorten it, but the consequence is that code complexity scales poorly.