> I like the "don't support MPICH-1.2.1p1" option myself as a first
> guess. I
This would be a great option is this wasn't the 'latest and greatest MPICH2
release' .AND. this same issue is likely to occur with ALL future releases
of MPICH2.
> have not looked at the code to see whether there is potential trouble
> there,
> but there are a lot of performance implications in parts of the mpi
> code...
Of course... Although I am not sure it is huge. From what I can see this
all_gatherv is only called (in pmemd at least) at the end of a GB run. E.g.
the test cases crash at step 10 of 10. That said we should probably address
it in a nice way.
> I will try to find some time to look at this further...
> (the principle I am applying here is you don't dink up your own code to
> support stuff that is broken, unless you absolutely have to...)
I agree except:
1) Convincing the MPICH2 people that they are wrong will likely be hard.
2) Having to keep telling the same thing to users again and again will be
tiring.
3) These days I just want a peaceful life so I can actually do some
research.
All the best
Ross
/\
\/
|\oss Walker
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org/ |
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Apr 13 2010 - 17:30:03 PDT
