Hi Steve,
Thank you very much for the helpful answer and the detailed information
about GIST! Indeed, excluding the flag doeij helps already not to crash,
so now I can extend the volume for the grid calculations significantly.
Best wishes and have a nice week,
Sergey
On 10/07/2016 05:31 PM, Steven Ramsey wrote:
> Hi again,
>
> Sorry for the double post, I noticed that in your command you are also
> using the optional flags doorder and doeij, these calculations will likely
> use a fair amount of memory as well. If these data are not integral to your
> analysis you may want to omit them (which will both increase your runtime
> and reduce memory usage).
>
> Another comment that may be helpful is that entropies in GIST are currently
> not calculated in the outer layer, so if you run several overlapping
> regions of GIST keep in mind that your overlap should be by one voxel. The
> concatenation of GIST output should be a tractable code to write, so long
> as the GIST grids line up, which is to say the edge of one voxel overlaps
> with the edges of a voxel in your second output, if they do not overlap
> perfectly the combination becomes much more complex.
>
> Hope this helps,
>
> --Steve
>
> On Fri, Oct 7, 2016 at 10:56 AM, Steven Ramsey <vpsramsey.gmail.com> wrote:
>
>> Hi Sergey,
>>
>> That sounds like a really interesting system to analyze! You are
>> absolutely right that GIST can run into memory issues, but depending on
>> when the crash is occurring (early vs late), there may be another issue at
>> play. If the crash occurs after some time likely GIST is running out of
>> memory as you suggest and kills itself.
>>
>> One suggestion would be to try the version of GIST in the cpptraj github,
>> which has been upgraded and will run faster. If the crash you are
>> experiencing is a bug and not memory related then the github version may
>> have already addressed said bug...only one way to find out!
>>
>> Your intuitive solution of dividing and recombining GIST boxes is
>> absolutely correct and would be my suggestion on how to tackle large
>> regions of interest in the case of limited memory. Unfortunately GistPP
>> does not have a function that combines two GIST outputs in the manner that
>> would work with this fix, however it is definitely something that I'll
>> implement in the future.
>>
>> The last comment I'd make is that there is a known bug regarding
>> arbitrarily high energies when a trajectory is aligned prior to running
>> GIST, therefore if at all possible it would be better to avoid using rms on
>> a trajectory before using GIST.
>>
>> Hope this helps, best of luck,
>>
>> --Steve
>>
>> On Fri, Oct 7, 2016 at 10:22 AM, Sergey Samsonov <
>> sergeys.biotec.tu-dresden.de> wrote:
>>
>>> Dear AMBERs,
>>>
>>> I'm trying to calculate hydration properties of a relatively big
>>> interface between two macromolecules. Because the interface that
>>> interests me consists of quite an extended H-bonding network (made up of
>>> direct and water-mediated H-bonds) I'd like to apply GIST calculations
>>> in the box containing the whole interface and, then, to get hydration
>>> properties around the residues establishing this H-bonding network. To
>>> do this I can use GistPP in the way it is shown in the tutorial.
>>> However, I face a technical problem, which was previously already
>>> partially discussed in the Mailing List: when I run GIST in a big box, I
>>> get an error probably due to the memory shortage:
>>> ------------------------------------
>>> 1: [gist doorder doeij gridcntr 62 69 60 griddim 60 60 60 gridspacn
>>> 0.5 out Region3/gist.out]
>>> GIST number of voxels: 216000, voxel volume: 0.125000 A^3
>>> GIST grid origin: 47.000 54.000 45.000
>>> ./run_gist3.com: line 1: 12480 Killed cpptraj
>>> ../../top.top < gist3.ptraj
>>> ------------------------------------
>>>
>>> The same script starts to work without any problem when I decrease the
>>> box sizes to 45 45 45 and still does not work if I just take
>>> significantly less frames (I even tried with just one frame to check if
>>> this could work) from the trajectory for my analysis.
>>>
>>> I guess an intuitive way to overcome this obstacle is to split the
>>> interface into several smaller boxes that do not yield problems for GIST
>>> calculations, to cary out calculations for them and then to unite them.
>>> The technical question is if it is possible to take two overlapping
>>> boxes and unite them into one using GistPP?
>>>
>>> Maybe I'm doing something wrong with my trajectory: prior to the
>>> analysis I image the trajectory using a script containing centering and
>>> rms to the the solute, and imaging with 'image center familiar' command.
>>> Could this be a source of the error in following GIST calculations?
>>>
>>> Thank you very much in advance and cheers,
>>>
>>> Sergey
>>>
>>> --
>>> Sergey A. Samsonov
>>> Postdoctoral researcher
>>> Structural Bioinformatics
>>> Biotechnology Center
>>> Tatzberg 47-51
>>> 01307 Dresden, Germany
>>>
>>> Tel: (+49) 351 463 400 83
>>> Fax: (+49) 351 463 402 87
>>> E-mail: sergey.samsonov.biotec.tu-dresden.de
>>> Webpage: www.biotec.tu-dresden.de
>>>
>>>
>>> _______________________________________________
>>> 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
--
Sergey A. Samsonov
Postdoctoral researcher
Structural Bioinformatics
Biotechnology Center
Tatzberg 47-51
01307 Dresden, Germany
Tel: (+49) 351 463 400 83
Fax: (+49) 351 463 402 87
E-mail: sergey.samsonov.biotec.tu-dresden.de
Webpage: www.biotec.tu-dresden.de
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Oct 09 2016 - 23:00:02 PDT
