Hello Everyone,
For those that are interested, here are the details of what caused the problem.
What INITPARM does:
-------------------
INITPARM tells NXTSEC if it needs to read the header for the prmtop file or not. I.e., is this the first time that the file has been read. If you are reading multiple parm7 format files this needs to be set to .true. for each one.
What caused the problem:
------------------------
For parm7 format files you can set INITPARM=.true. before each NXTSEC call. For the earlier file format this is not the case and setting INITPARM=.true. resets the file pointer location, causing the wrong data to be read. The very first test has an old prmtop and causes the problem. (I still don't know why this passed the first time I ran the tests.)
Since RDPARM1 is the first time the file is read from, setting INITPARM=.true. doesn't matter. It is redundant if we haven't read any other files with NXTSEC, which is the case currently. In RDPARM2, it resets the file pointer, causing problems for the old file format.
Why I added this:
-----------------
3D-RISM gets precomputed 1D-RISM solvent data from a PARM7 format file. When I originally implemented it the call sequence was RDPARM1, RDXVV1, RDPARM2, RDXVV2 so NXTSEC needed to be reset. I also had it surrounded by #IFDEFs for RISM so only sander.RISM was effected and never tested sander.RISM with old prmtop files. The call sequence has since been changed so that only RDXVV1 needs to reset NXTSEC. I got rid of the IFDEFs because I was trying to reduce the number of files that the RISM code touches. In fact, all reference to INITPARM can be safely removed.
Sorry for the all the trouble,
Tyler
On 2010-01-29, at 6:58 PM, Ross Walker wrote:
> Hi Tyler,
>
> What does this actually do? I can't work it out why it is needed.
>
> Ps. It occurs twice in rdparm.f on line 238 and 34. I assume it is just line
> 238 that is not needed yes? It is needed on line 34 otherwise it ends up
> uninitialized yes?
>
> The test cases look like they work with this removed.
>
> All the best
> Ross
>
>> -----Original Message-----
>> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
>> bounces.ambermd.org] On Behalf Of Tyler Luchko
>> Sent: Friday, January 29, 2010 2:20 PM
>> To: AMBER Developers Mailing List
>> Subject: Re: [AMBER-Developers] CVS Tree is locked
>>
>> Hi Ross,
>>
>> At least one problem is my fault. If you comment out line 238 of
>> rdparm.f to read
>>
>> ! initprmtop = .true.
>>
>> The sander test cases should function properly again.
>>
>>
>> I did run the test cases before submitting but it would seem that the
>> recompile didn't pick up the changes for some reason. I only
>> discovered
>> this problem after doing a cvs update -ACPd and
>>
>> make clean
>> make uninstall
>> make -f Makefile_at clean
>> make -f Makefile_at uninstall
>>
>> and compiling from scratch. It is time consuming so I don't do it as
>> often as I should.
>>
>> Sorry,
>>
>> Tyler
>>
>> Ross Walker wrote:
>>> Dear All,
>>>
>>> I have locked the CVS tree to ALL checkins. There are multiple things
>> broken
>>> right now and it is clear people are not checking that everything
>> compiles
>>> correctly and passes the test cases before checking things in.
>>>
>>> E.g.
>>> ifort -c -ip -O3 -axSTPW -FR -o ncsu-umbrella.o _ncsu-umbrella.f
>>> fortcom: Error: _ncsu-umbrella.f, line 123: This module file was not
>>> generated by any release of this compiler. [NETCDF]
>>> use netcdf, only : nf90_double, nf90_float
>>> ----^
>>> fortcom: Error: _ncsu-umbrella.f, line 180: This symbol must be a
>> defined
>>> parameter or an argument of an inquiry function that evaluates to a
>>> compile-time constant. [NF90_DOUBLE]
>>> integer, private, parameter :: coeffs_type = nf90_double
>>>
>>> etc...
>>>
>>> There are also numerous issues with PBSA right now and particularly
>> the test
>>> cases which were updated on Jan 28th by Mengjuei with the ambiguous
>> log
>>> message of:
>>>
>>> "Upon the report of missing files in the test cases. I found that
>> there is
>>> something wrong with my local CVS directory. Nevertheless, I am
>> fixing it
>>> by re-checking out and in."
>>>
>>> Once the tree is working again I will unlock it.
>>>
>>> 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
>>
>> _______________________________________________
>> 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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Jan 29 2010 - 20:00:02 PST
