On Nov 18, 2011, at 07:49 , Ralph Castain wrote: > That's a condition which should never be reached, but just to be safe, I have > added a "bozo check" that will cause the routine to error out with a message > if that situation occurs. I have tried everything - hostfile, dash-host, > bizarre combinations of hosts, etc. - and been unable to replicate your > described problem.
What I see is that the impossible happened. Every run, consistently and only after the commit r25476. Anyway, this is now fixed by commit r25492. Feel free to remove the bozo check, it sounds very weird to expose that to our users. >> Moreover, reading the comments in this file, FREAK me out, as apparently >> each mapper is allowed to have a different behavior… > > Not sure why that would "freak" you out as this has always been the case. > Since the project started, we have allowed the user to separately specify > mapping, ranking, and binding algorithms so they can reach a wide range of > placement patterns. We have also allowed individual mappers to either use the > base functions, or to completely ignore them - e.g., the rank-file mapper > always ignored the base and just did things its own way. You're twisting what I said. The comment implies that the mappers don't have a consistent behavior, some being allowed to update some lists while others are not. This is what freak me out, not that they map the processes differently. > None of that is new or changed. The only thing that changed is that we > extended the range of resource types over which the user can exercise > control. Instead of just slots and nodes, it now includes cores, hwthreads, > and other strange beasts. So the number of possible combinations is much, > much greater than before. Sure, I read that in the RFC! > Don't blame me for the added complexity. I argued against some of this as I'm > convinced it will rarely, if ever, be used - but I'm told this is what the > user community wants, and so that is what I created. Again, this was clearly specified in the RFC, and thoroughly discussed in the community. The entire discussion can be found, as usual, in the thread started by the RFC. Absolutely, no issues here. george. > What I did, as I stated, was to ensure that the previous minimal option > behavior remains the same - i.e., default behavior and simple options like > -bynode result in the same patterns as before. So only gluttons for > punishment get exposed to the added complexity. george.
