I am assuming you are not dinking with the energy, etc stuff in pmemd? I
sorted the sander mess out in the pmemd code a long time ago, replacing it
with a no-doubt imperfect, but nonetheless better "state information"
abstraction, and model-specific (eg., gb, pme) records.
Regards - Bob
----- Original Message -----
From: "Mark Williamson" <mjw.sdsc.edu>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Wednesday, March 10, 2010 10:11 AM
Subject: [AMBER-Developers] Current amber CVS test fails
> Dear All,
>
> I am looking to land a major change to the internal ener and ene() arrays
> in the current amber11 code. This will essentially replace these with a
> module containing a nested derived type, called "state", for energy and
> other system properties, accounting within the code. This has taken a
> while to code since the existing ene() and ener() were quite esoteric and
> regularly abused.
>
> The testing has also taken some time and I still know of a few remaining
> issues with my changing that need addressing. I want to get this into the
> tree now and iron out the remaining issue. However the show stopper on
> this has been existing parallel test cases in the tree just being plain
> broken and new issues occurring when changing from "-np 2" to "-np 4".
> I've put the fails up at
> http://www.wmd-lab.org/mjw/for_amber_dev/090310/amber/ :
>
> Generally with "-np 2" the following are real fails:
>
> test/ti_decomp/ti_decomp_1.out.dif
> test/ti_decomp/ti_decomp_2.out.dif
> test/gb_rna
>
> and with "-np 4", the following *extra* are real fails:
>
> test/softcore/ (pretty much all the restarts)
> dynlmb
> test/ncsu/bbmde
>
> Can anyone comment?
>
> I have a good grasp of the few remaining fails that are occurring within
> my code that I have been working on locally, but I am reluctant to check
> them in with these existing fails since it may make the problem of solving
> them harder. I am under a tight deadline, and I would really appreciate
> the relevant owners fixing these, or I may just have to commit and thus
> make solving these harder.
>
> regards,
>
> Mark
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 10 2010 - 08:00:03 PST
