Jeff Hammond <[email protected]> writes:
1. System headers and libraries are still often on a remote filesystem. The workflow is a lot more complicated if you mirror that locally.
The workflow does not change at all. E.g. "#include <stdio.h>" works irrespective of where you build.
Yes, slowly because it's coming from the global file system.
2. /tmp isn't shared between login nodes, let alone compute nodes, so you have to copy back to global storage. With multiple login nodes, when you background/nohup a compilation task and log out or are disconnected, you have to remember the login node number to get back to the result. The cognitive load of doing all compilation on /tmp, especially with multiple packages, is not trivial.
This is not complicated. You just ssh back to the login node you were building on before or you rsync between them. People that don't know how to use ssh and rsync shouldn't be building MPICH from source.
1. You have to remember an extra number (the login node number). 2. Normal users don't build MPICH from source on expensive machines, but they do build PETSc and downstream packages. Since there is no standard system for caching the results of configure tests, each test will be run at each relevant node within the dependency graph, which is a lot for applications with a deep stack consisting of well-factored libraries.
3. Try teaching this to a novice. The fact is that if HPC is going to grow its user base, it has to be easier to use. If you want to take the elitist stance that expensive machines should only be used by experts, stop giving INCITE awards to people that don't know how to use compilers, debuggers, or the shell. Until then, hiccups along the way land in our lap, and a complicated workflow only serves to intimidate and to create more opportunity for human error, which again comes back in the form of support mail.
Novices don't build MPICH from source.
The whole question is about configure tests for packages depending on MPI, not for building the MPI implementation.
I like fish, but I refuse to swallow all the red herrings you keep feeding me.
Does this mean you are volunteering to take over the support email for incompetent INCITE awardees and that you are happy to alienate the scientists with modest technical skills that are not yet able to win an INCITE? Or we can agree that although requiring every package to test a zillion things in their configure sucks for workflow, usability, and speed, there is no viable technical solution available, so we have few options short of the life-consuming task of attempting to build and distribute a real solution.