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
Received on Thu Apr 29 2010 - 13:00:06 PDT
