Thank you very much Franēois. Your answer was really useful.
"70000 MEP points correspond to the "i5" format in fortran, while
150000 correspond to "i6". I think RESP uses "i5" by default." -->
This is the answer to all my problems!
>From certain answers I'm getting, I don't think I've made myself very
clear, but if you read my initial message to this mailing list you'll
see that I posted all the info and errors (to answer Piotr questions).
I'm doing very accurate parametrizations of certain heme models I
built, so I actually need this extensive detail in the calculations.
I'll tune the program and recompile it. I'll let you know if there is
any problem.
Once again, thank you very much.
Best regards,
Joćo
On Thu, Apr 29, 2010 at 8:55 PM, FyD <fyd.q4md-forcefieldtools.org> wrote:
> Dear Joćo,
>
> Sorry, I missed your emails & read your email only because Piotr answered
> ;-) You might register in the q4md-forcefieldtools mailing list .
> http://lists.q4md-forcefieldtools.org/wws/ as well to get answers about RESP
> & the R.E.D. tools.
>
>> For some reason 150.000 points is just too much. It works fine with
>> 70.000 (discovered that today).
>
> 70000 MEP points correspond to the "i5" format in fortran, while 150000
> correspond to "i6". I think RESP uses "i5" by default.
>
>> But I really need the maximum number
>> of layers possible, so I'll have to take some measures to make Resp
>> able to handle 150.000 points. Changing those parameters and
>> recompiling is my next objective. I'll ask for some aid with this task
>> since my programming is rusty to say the least.
>
> If I well understood you need to handle a large number of MEP points in
> RESP.
>
> First, just be aware that "IOp(6/33=2) pop=mk" (in Gaussian) are the only
> keywords required to compute MEP using the Connolly surface & the default
> algorithm defined by Kollman & coworkers. See for instance basic examples .:
> http://q4md-forcefieldtools.org/REDDB/projects/W-1/ when using GAMESS-US,
> or
> http://q4md-forcefieldtools.org/REDDB/projects/W-2/ when using Gaussian.
>
> This is also clearly described in the Gaussian, GAMESS-US & now Firefly
> documentations.
>
> Using a large number of concentric Connolly surfaces (above 4) & a higher
> density of MEP points (above 0.28 points per square au) might be useful, but
> only in some specific cases.
>
> Anyway, if you do want to use a high density of MEP points, you need to
> slightly update the source code of RESP. If you decide to use the standalone
> version of the RESP program distributed from the q4md-forcefieldtools.org
> web site (quite simple/fast to compile) available .
> http://q4md-forcefieldtools.org/RED/resp/ you can find information about
> examples of RESP source code modifications .
> http://q4md-forcefieldtools.org/RED/resp/README
>
> In your case, you need to change the format of the number of atoms & MEP
> points which should be 2i5 (if I remember) into i5i6 (or i5i7).
> see http://q4md-forcefieldtools.org/RED/resp/#desc for more information
> about fortran formats.
>
> If you want to use R.E.D. with this new RESP binary version (i5i6), this is
> straightforward (we should even have a version somewhere) & I can send you
> this modified version if you need. We will release a new version of R.E.D.
> soon; However, it will not contain this approach.
>
> Using "B3LYP/Gen & LANL2TZ(f)" (i.e. ECP) is also quite simple to implement
> in R.E.D.-III.x/IV while Pop(MK,ReadRadii) is already implemented.
>
> I hope this helps.
>
> regards, Francois
>
>
>> On Thu, Apr 29, 2010 at 6:56 PM, Piotr Cieplak <cieplak.cgl.ucsf.edu>
>> wrote:
>>>
>>> I am not sure if I understand what (exactly) is the problem with RESP.
>>> This program should accept any number of esp points. It reads the esp
>>> points and immediately uses them to create appropriate matrices for
>>> charge
>>> fitting. The size of those matrices is roughly
>>> (nomolecules*natom+lagrangeconstr+1),
>>> so - any number of atoms should be handled easily even on the laptops.
>>> As I understand RESP in standard version handles 500 atoms, 100 lagrange
>>> constraints and 30 molecules. If it nos enough then change maxq, maxlgr
>>> and
>>> maxmol parameters and recompile.
>>>
>>> Piotr
>>>
>>>
>>> On Thu, 29 Apr 2010, Joćo Henriques wrote:
>>>
>>>> From: "[ISO-8859-1] Joćo Henriques" <joao.henriques.32353.gmail.com>
>>>> Sender: amber-bounces.ambermd.org
>>>> To: AMBER Mailing List <amber.ambermd.org>
>>>> Date: Thu, 29 Apr 2010 14:19:13 +0100
>>>> Subject: Re: [AMBER] Fortran runtime error: Bad value during integer
>>>> read
>>>> Reply-To: AMBER Mailing List <amber.ambermd.org>
>>>>
>>>> Ok, as I suspected Resp can't handle such huge ESP files. With 6/42=8
>>>> and MK pop the number of points reduces from over 150.000 to aprox.
>>>> 70.000 and Resp is finally able to handle them.
>>>> I'm kinda surprised no one has ever experienced similar problems. I'll
>>>> have to change the source code to make it able to handle bigger files.
>>>> If anyone has any ideas about how to change the code, please feel free
>>>> to mail me. All ideas are welcome.
>>>>
>>>> 2010/4/29 Joćo Henriques <joao.henriques.32353.gmail.com>:
>>>>>
>>>>> I'm 100% sure Resp within AmberTools can handle multi-conformational
>>>>> fits. I've done quite a few myself. But I don't know how limited it
>>>>> is. I'll run a few tests with less points per each atomic center to
>>>>> see if it is due to the cheer size and complexity of my models. I
>>>>> provide over 150.000 points for each model (they are 4). So it might
>>>>> be too much to handle.
>>>>> As a final measure I'll have a serious look at RED. In good truth I
>>>>> haven't looked at it more seriously because from what I've read it
>>>>> uses AmberTools Resp code. If I can use the code directly why use it
>>>>> through an intermediate program. (This consideration might be wrong,
>>>>> as I said I haven't done any significant research on RED).
>>>>>
>>>>> If the limitation in Amber's Resp program is proven this becomes
>>>>> serious, since it might occur to other users. Some kind of measure
>>>>> should be taken. At least inform users about this limitation.
>>>>>
>>>>> Thanks for all the feedback, I'm always looking forward to receiving
>>>>> more input from experienced users.
>>>>>
>>>>> On Thu, Apr 29, 2010 at 1:10 PM, Jason Swails <jason.swails.gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm not sure if RESP included with amber can handle
>>>>>> multi-conformational
>>>>>> resp fits. I remember reading somewhere that it doesn't, but you said
>>>>>> that
>>>>>> it did for small molecules, so I'm not quite sure.
>>>>>>
>>>>>> If you're looking to do some heavy-duty multi-conformational RESP
>>>>>> fitting, I
>>>>>> would suggest looking at R.E.D., which is linked to from
>>>>>> http://ambermd.org. There has been plenty of discussion about it on
>>>>>> the Amber list, and it
>>>>>> has more capabilities built in than the resp.f included with amber.
>>>>>>
>>>>>> Good luck!
>>>>>> Jason
>>>>>>
>>>>>> 2010/4/29 Joćo Henriques <joao.henriques.32353.gmail.com>
>>>>>>
>>>>>>> They were all GNU. GCC and GFORTRAN. A friend researcher of mine used
>>>>>>> PGI with 1.4 version of AmberTools and obtained the same error.
>>>>>>>
>>>>>>> On Thu, Apr 29, 2010 at 2:33 AM, Mengjuei Hsieh <mjhsieh.gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> 2010/4/28 Joćo Henriques <joao.henriques.32353.gmail.com>:
>>>>>>>>>
>>>>>>>>> It's really confusing. This leads me to suspect that
>>>>>>>>> the file size is prohibitive, but if that's the case why isn't
>>>>>>>>> there
>>>>>>>>> anything written about this on the manual or something. Since I
>>>>>>>>> have
>>>>>>>>> 99 atoms and I'm calculating the esp with B3LYP/Gen (6-31G(d) and
>>>>>>>>> LANL2TZ(f)) with SCF=Tight, Pop(MK,ReadRadii,Full) and
>>>>>>>>> IOp(6/33=2,6/41=10,6/42=17) I might have too much points too
>>>>>>>>> compute
>>>>>>>>> with resp... But again I'm just guessing!
>>>>>>>>
>>>>>>>> Hi, it is indeed intriguing, what compilers are you using for
>>>>>>>> AmberTools? Knowing the kind of compilers might help developers
>>>>>>>> tracking down the issues.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> --
>>>>>>>> Mengjuei
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Apr 30 2010 - 05:30:06 PDT
