Hello Jason,
Thanks a lot for your suggestions. Certainly, adding an extra non-bonded
proved to be complex and intrusive. I followed your suggestion of
"tagging" particular pairs. Although, it wasn't absolutely trivial, it did
not affect calculations on MPI or single CPU for pmemd 12. Changes were
made in subroutines get_nb_list in pme_direct.F90 and pairs_calc_novec.i.
Thanks,
Jose
> On Fri, Sep 20, 2013 at 2:40 PM, <jfloresc.andrew.cmu.edu> wrote:
>
>> Hello All,
>>
>> I am implementing an extra non-bonded list of only solute-solute atom
>> interactions. My purpose is to scale down solute-solute direct
>> electrostatic interactions in PMEMD MPI (Amber 12). My first attempt has
>> been to add a new non-bonded list called gbl_ipairs_solute in the module
>> nb_pairlist. Then I modified the subroutine get_nb_list in the same
>> module
>> by adding if-else sentences when the indexes of a pair of atoms are
>> below
>> or equal to the number of solute atoms.
>>
>> However, I have some problems with illegal access to memory. Below is a
>> small part of the code (extra variables are initialized:
>> ee_solute_eval_cnt = 0, full_solute_eval_cnt = 0. nsolute is the number
>> of
>> solute atoms).
>
>
> I think better information would be a diff (so we can see the changes you
> made) and the error message you got (even better if you could isolate
> where the problem was using valgrind or gdb).
>
> I hope you could provide me some tips of how to correct
>> this or a better implementation.
>>
>
> I personally think trying to create a new pairlist is an undesirable
> approach for several reasons.
>
> 1) It is complex to code (as you are discovering here), and will require a
> very large amount of debugging to make sure that it is implemented
> correctly in serial and parallel.
>
> 2) It adds considerably to the memory requirements of the program.
>
> 3) It requires the most intrusive changes (this goes along with 1)
>
> 4) I expect it will harm performance (perhaps significantly, unless done
> 'correctly' I suppose).
>
> So you should really try and decide if doing this is necessary before
> taking this route. I may misunderstand what you're trying to do, but I
> think you can use the existing pairlist with only minor changes to
> accomplish what you want. You can always pretty-it up later if you want to
> release it, but that should come after testing and validation to determine
> if it's worth spending your time.
>
> What I would suggest is try to find a way of "tagging" particular pairs
> that you want to scale. [1] Perhaps the easiest way is to tag
> solute-solute pairs with negative indexes. The abs() function allows you
> to easily recover the original value wherever you need to, and you have a
> very simple (and computationally efficient) test to evaluate whether or
> not
> the interaction should be scaled [ if (pair_index < 0) ]. (The compiler
> should be able to figure out that it just needs to look at the sign bit to
> determine truthyness...)
>
> I'm not sure if there are many people that can give you detailed help when
> coding this without spending significant (and probably unavailable)
> amounts
> of time to familiarize themselves with the code--it was written,
> optimized,
> and validated fairly long ago (it has not been changed significantly since
> 2008).
>
> I suspect that valgrind and gdb (or idb) will be a great help if you
> familiarize yourself with how to use it (particularly if you encounter
> segfaults or other fatal memory violations). Valgrind is particularly
> nice
> in terms of dealing with MPI programs and independently tracking threads.
> Of course if you have access to TotalView, just use that.
>
> Hope this helps,
> Jason
>
> [1] Don't forget that direct-space electrostatic interactions are already
> scaled by erfc in Ewald sums. The use of Fourier transforms in
> Ewald-based
> methods limits the physical relevance of pairwise electrostatic
> interactions. May be something worth considering in your method.
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
> _______________________________________________
> 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 Wed Sep 25 2013 - 18:30:03 PDT
