Hi Dan,
I’ve removed the TESTRISMSANDER variable.
FWIW, the same problem exists for NAB and RISM but is tougher to check for. I’ll try and come up with a solution in the next day or so.
Tyler
> On Apr 9, 2015, at 7:04 AM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
>
> Hi Tyler,
>
> Your changes appear to work great. The tests now correctly detect if
> RISM support is enabled in sander.
>
> Do we need the TESTRISMSANDER variable in configure2/config.h anymore?
>
> -Dan
>
> On Wed, Apr 8, 2015 at 11:13 PM, T Luchko (Lists)
> <tluchko.lists.gmail.com> wrote:
>> Hi Dan,
>>
>> I followed up on your suggestion and push two patches to the master branch. Let me know if these work.
>>
>> Tyler
>>
>> On Apr 7, 2015, at 2:12 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> Recently when testing the Amber RCs I've come across this kind of
>>> error during RISM parallel tests; they all fail with:
>>>
>>> mdfil: Error unknown flag: -xvv
>>>
>>> Looking into this I found that this happens if a configure that
>>> enables RISM by default (e.g. 'configure intel') occurs after a
>>> configure that disables it by default (e.g. 'configure -mpi intel').
>>> Because these tests depend on TESTRISMSANDER being properly set in
>>> config.h, if the value in config.h doesn't match the binary, the tests
>>> can be run when they shouldn't be. Having the tests depend on
>>> variables in the config.h file seems like bad practice anyway because
>>> config.h can be so volatile. I think it would be better if the tests
>>> could somehow be modified so they detect whether RISM is available
>>> (e.g. see if the -xvv flag is supported). Something that could be
>>> sourced from test run scripts that will skip the test cleanly like:
>>>
>>> touch foo
>>> HAS_RISM=`$TESTsander -O -xvv foo 2> /dev/null | grep flag`
>>> /bin/rm foo mdout
>>> if [ -n "$HAS_RISM" ] ; then
>>> echo "$TESTsander compiled without RISM support."
>>> exit 0
>>> fi
>>>
>>> In the long run it may be worthwhile to add something like the cpptraj
>>> '--defines' flag to sander/pmemd for easier inquiry of what
>>> capabilities are supported by a given binary.
>>>
>>> Of course for this release it might just be too much work for too
>>> little gain, but maybe something to keep in mind for the future.
>>>
>>> Thoughts?
>>>
>>> -Dan
>>> --
>>> -------------------------
>>> Daniel R. Roe, PhD
>>> Department of Medicinal Chemistry
>>> University of Utah
>>> 30 South 2000 East, Room 307
>>> Salt Lake City, UT 84112-5820
>>> http://home.chpc.utah.edu/~cheatham/
>>> (801) 587-9652
>>> (801) 585-6208 (Fax)
>>>
>>> _______________________________________________
>>> 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
>
>
>
> --
> -------------------------
> Daniel R. Roe, PhD
> Department of Medicinal Chemistry
> University of Utah
> 30 South 2000 East, Room 307
> Salt Lake City, UT 84112-5820
> http://home.chpc.utah.edu/~cheatham/
> (801) 587-9652
> (801) 585-6208 (Fax)
>
> _______________________________________________
> 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 Thu Apr 09 2015 - 11:30:02 PDT
