Hi,
On Apr 10, 2007, at 9:11 PM, Justin M. Shorb wrote:
Greetings,
I have been running a modified version of gromacs 3.3 and would
like to run two kernel loops: one which is 330 and one which is
300. In the src/gmxlib/nonbonded/nb_kerneltype.h file it strictly
says to use wrapper routines that are included in the
gmx_nonbonded.h file, which I cannot find. I assume that in
switching versions the filename has changed, and perhaps was meant
to point me to nonbonded.c ? Given that nb_kerneltype.h says that
it is part of the gromacs 4.0 version, I would not be surprised if
a version misnomer occured. However, I would be more than happy if
you can point me to where this file should be located.
In a similar light, is it possible to build and call two separate
kernels within one run of gromacs, or would the tabulated files end
up on top of each other? The nb_kerneltype.h seems to say you can
use a build routine (probably setup_kernels() in nonbonded.c, but I
want to make sure I'm not missing the gmx_nonbonded.h file somewhere).
Certainly. Each neighborlist is attached to a specific loop, but you
can have as many neighborlists as you want. Your best option is
likely to create the (different) neighborlists with the nonbonded
setups they should have, and then call do_nonbonded() as declared in
gromacs-x.y.z/include/nonbonded.h (sorry, the gmx_ prefix was lost
when backported).
My plan currently is to use setup_kernels() to explicitly setup
both kernels needed in the nb_kernel_list (which I believe is the
list of kernels to be setup ranging from 1 to eNB_NBKERNEL_NR) and
then simply force the kernel 300 to be created as well as the
generic propagation kernel (typically 330). Then it should be a
matter of choosing a different nrnb_ind index to run the alternate
kernel in the do_nonbonded() routine.
As you might already have found out, setup_kernels() is a really
trivial routine that sets kernel pointers based primarily on your
architecture (SSE/SSE2/Altivec/ia64/etc.), and assigns NULL to the
solvent-optimized kernel pointers if that type of optimization isn't
present.
You can still call all kernels, although they might be generic
(though optimized) C code if no acceleration has been implemented.
Are there double counting things that should be taken into account?
And more importantly, is there an efficient subroutine written for
such a matter that is being overlooked (hidden in a *.h file
somewhere)?
There should be a routine in src/mdlib/ns.c that initalizes the
kernel index based on the interactions in a particular neighborlist.
Cheers,
Erik
_______________________________________________
gmx-users mailing list [email protected]
http://www.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at http://www.gromacs.org/search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [EMAIL PROTECTED]
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
