Originally Posted By: lennart

label loop
traj read
coor stat sele segid prot end
define lipunder sele segi lipi .and. point ?XAVE ?YAVE ?ZAVE CUT 15 end
goto loop


Looks promising, thanks a lot!
I would have to add an offset to ZAVE or increase the CUT since the max diameter in the current selection will be somewhat over the membrane interface.


Originally Posted By: lennart
I agree, for many analyses of solvent behavior around a solute the existing tools (COOR ANALysis or SHELL) do a very good job. For the kinds of analyses indicated by the original poster a CHARMM loop is likely to be the better solution; in particular since the concept of "under" is not so clearly tied to "being close to".


This is sadly so true, since the protein has a "hole" in the middle an if I would use nearby those lipids under the center of protein would most likely be excluded. Maybe this ASCII-Art can clear things up:

Code:
       _______
      /  ___  \  Protein
     /__/   \__\
||||||||||||||||||| Membrane
|||||||||||||||||||
      |-------|
   Lipids of interest


Originally Posted By: rmv
True, but in many contexts, such as the above snippet, atom selection is not always "image aware" (shell code is), which may be an issue. Depending on the cell size, a 15 A shell based on lipid P and N atoms (assuming PC lipid) may be fairly reasonable.

For a loop over frames, the image cell boundary problem could also be handled by a coordinate translation in the xy plane followed by an image update, but that would slow things down a bit more.

I often try several different approaches in this situation (something to do with eggs and baskets smile ).


Thanks for pointing out this problem.
Could you give an code example for"coordinate translation in the xy plane". I know the purpose behind the translation and in fact I probably would have run into this pitfall, since my protein is is moving around and reaches the end of the box here and there so I guess I have to deal with the boundary conditions. crazy

How much would this slow things down? It's going to be a very long simulation (so far ~400ns but still crunching to reach some microseconds and I am dreaming of milliseconds)
The simulations are consecutive runs of 1ns slices. So for each unreduced trajectory (1ns, 500000 steps, write out freq. 500, integration time 2 femtoseconds) has the size of 1.5G.

Sadly, running multiple small simulations is not an option here cry

If the slowdown is way to big I maybe should go with a more inaccurate selection (COOR ANALysis or SHELL) in favor for a reasonable time.

I think I'll play a bit around with both options and see what happens.

Thanks a lot!
Bjoern