Hi Bill, When we discussed removing static thread levels (above single), we did consider their usefulness, for research as well as production. Configure-time selection of thread levels was important when the initial thread support was being developed, to measure the impact of dynamic thread levels. However now that we see that dynamic thread levels adds negligible overhead, I don't think that we need that feature. Instead we are now focusing on fine-grained threading, so we'll add instrumentation stuff there that might eventually go away. The goal was not really to "hide" the bug by not allowing an option to be selected. Instead we figured that removing static thread levels would result in dead code which could then be removed, and that the bug was located in the dead code. Of course if it turns out that the bug was not in this dead code, then it still needs to be fixed, but that's a different issue than getting rid of static thread levels. Note that dynamic thread levels still allows us to use MPICH_THREADLEVEL_DEFAULT. -d On Sep 29, 2010, at 11:42 AM, William Gropp wrote:

There are good arguments for reducing some of the options, but this must be done recognizing that MPICH2 must first and foremost be a research vehicle for MPI implementations - that will require supporting more options than are appropriate for a product that implements MPI for some platforms. Having said that, some of the current flexibility in supporting thread levels may not be needed and can be reduced, though I don't agree with the proposed mapping (and note that runtime can't be the general default, as the default choice depends on the capabilities of the device and channel). Reducing the options should be done carefully and openly, and after a discussion of all of the issues.