Re: [AMBER] nmode analysis - different SCEE values in SANDMIN and NMODE output files ?

From: Marek Maly <marek.maly.ujep.cz>
Date: Thu, 22 Sep 2011 13:58:49 +0200

Hi Jason,


Dne Thu, 22 Sep 2011 06:58:09 +0200 Jason Swails <jason.swails.gmail.com>
napsal/-a:

> 2011/9/21 Marek Maly <marek.maly.ujep.cz>
>
>>
>> Jason thanks a lot again !
>>
>> This is really incredible service ! No way to move from Amber :))
>>
>> What is still not so clear is the easest way how to incorporate scee =
>> 1.2
>> into
>> nmode calculation.
>>
>> I succeeded with this method which doesn.t require changing C/F sources
>> /recompiling of Amber:
>>
>> I just "hacked" file
>>
>> mm_pbsa_createinput.pm
>>
>> by adding line:
>>
>> print OUT " scee= 1.2,\n";
>>
>> to relevant block:
>>
>>
>> $name = "nmode" . $suf . ".in";
>> open(OUT,">$name") || die(" $name not opened\n For details
>> see:
>> $HTMLPATH#create_nmode_nmodein_not_opened\n");
>> print OUT "File generated by mm_pbsa.pl\n";
>> print OUT " &data\n";
>> print OUT " ntx = 0,\n"; # Binary format is no longer supported
>> print OUT " ntrun = 1, nvect = $nvect,\n";
>> print OUT " drms = $nmdrms,\n";
>> print OUT " dielc = 4.0, idiel = 0,\n";
>> print OUT " idecomp= $idecomp,\n";
>> print OUT " scee= 1.2,\n";
>> print OUT " &end\n";
>> print OUT "END\n";
>> close(OUT);
>>
>
> That should work as well. I was suggesting changing the source code
> simply
> because 2.0 is no longer used anywhere that I've seen in the Amber force
> fields (I never even knew that it once was), so there's not much point in
> keeping 2.0 as a default anymore.
>
> However, nmode is deprecated and is no longer developed (maybe it'll
> just be
> removed from Amber altogether someday? I'm not sure...)

OK
>
>
>>
>> however especially for those who have not so easy possibility to change
>> Amber files (i.g. users of supercomputer centers ... ) might be useful
>> some another way with no necessity to change Amber sources.
>>
>> So is it possible:
>>
>> a)
>> to run mm_pbsa.pl using "by hand" created sandmin*.in nmode*.in files
>> instead regular mm_pbsa.in file ?
>>
>> With regular input file, the syntax to run MMPBSA calculation is:
>>
>> mm_pbsa.pl mm_pbsa.in > mm_pbsa.out
>>
>> So using sandmin*.in nmode*.in should be similar to:
>>
>> mm_pbsa.pl sandmin*.in nmode*.in > mm_pbsa.out
>>
>> but if using exactly this form it doesn.t work.
>>
>
> Yes, because mm_pbsa.pl expects an mm_pbsa.pl-specific input file. Not
> input files to use for the calculations.
>

Yes I know but there is no problem that program/script could flexibly
change it's behaviour depending
for example just on the number of provided inputs, but this is evidently
not the case here ...


>
>>
>> b)
>> Another possibility might be to start mm_pbsa by regular way but with
>> the
>> condition:
>>
>> "Please do not create sandmin*.in nmode*.in files but use that which
>> are
>> already in actual directory"
>>
>> If I am not wrong something like this is possible in mmpbsa.py just by
>> setting some parameter but
>> I am not aware of the same possibility in case of mm_pbsa.pl.
>>
>
> As far as I know that functionality exists only in MMPBSA.py. I think
> that
> mm_pbsa.pl *does* have an option to use a nab program for normal mode
> calculations

I know

  rather than using nmode itself, which may be a better
> option in
> this case. It would be detailed in the Amber 11 manual if that option is
> available. We (the people that typically respond to MM/PBSA questions on
> the list) don't really support the perl version of MM/PBSA (which was
> part
> of the motivation behind developing the python version in the first
> place).
> We answer questions when we can, but don't actually participate in its
> continued development. That's why we continue to suggest MMPBSA.py as an
> alternative and are unlikely to contribute further developments to the
> perl
> version.

OK, I am still using perl version because I started to use it for MM/PBSA
analysis some years ago
when python version did not exist. When it appeared I didn't care about it
because I was fully satisfied
with perl version which I used till that moment. About the python version
I was thinking just as about
new/alternative maybe more easy/comfortable (especially for beginners)
user interface than perl version which at the end
uses the same C/C++/Fortran PBSA/GBSA/normal mode routines. But if perl
version is from some reason really "out of fashion"
and is not going to be maintained properly in the future it is probably
the right time
to switch to it.s python successor...

Anyway thanks again for the complex explanation !

   Best wishes,

       Marek


>
> All the best,
> Jason
>


-- 
Tato zpráva byla vytvořena převratným poštovním klientem Opery:  
http://www.opera.com/mail/
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Sep 22 2011 - 05:30:02 PDT
Custom Search