[gmx-developers] Access to User Input Values

[Hank deHaan]

Hello

Thanks, Gerrit
your explanation has helped me alot,
I think your proposition is the best solution
and relatively clean compared to what I was contemplating :>

and although I don't need access to the user groups as of now (phew)
I appreciate your explanations
(it may come in handy in the near future)

Thanks again,
                                  Hank de Haan

> >I'm trying to modify the code slightly and am a little bit lost...
> >
> >I would like access to the user defined inputs (userreal1 etc.) within the
> >posres() function inside of bondfree.c
> >
> >I think that posres() is of type ifunc (from bondf.h), and i don't think
> >that the
> >structure t_inputrec (which contains userreal1 etc.) gets passed to
> >ifunc; but I don't want to just add it
> >and mess up all the other calls to this function type.  On the other hand,
> >I don't want to just clone the definition of ifunc for posre() because I
> >don't really know what I'm doing and would miss alot of inclusions and
> >stuff
> >
> >what is the cleanest solution for gaining access to the user inputs inside
> >the posres function?  Or are they already there and I haven't recognized
> >them?
>
> >Thanks for any help and sorry if my message isn't clear, programming isn't
> >my specialty :P
>
> I'm not completely sure wheter this is what you need, but maybey it
> is:
>
> You only want to use the userint, and userreals, right?
>
> In that case the easiest, but maybe not the cleanest, way would be to
> add userreal and userint elements to one of the structs that is passed
> on to posres, like the forcerec for instance. Then you can fill this
> userelement(s) when the forcere struct itself gets initiated and
> filled by init_forcerec (force.c) with the parameters stored in the
> inputrec. The user variables get read into the inputrec by grompp, but
> are not used furtheron in the code. The good thing is that if a user
> wants to use some extra input variables they he uses the userint/reals
> and doesn't have to modify the horrible(!!) grompp code.
>
> If you also want to get acces to usergroups, it is slightly different
> and more complicated.
>
> Acces to any group defined in your mdp file (Tempcoupl. grp,
> energygrp, accel. grp, freeze grp, user1 grp, user2 grp, com motion
> grp, XTC grp and orientation orientation grp) you get through the
> t_mdatoms struct.
>
> the mdatoms struct (include/types/mdatom.h) contains a array for each
> group (cTC[], cENER[], cACC[], cFREEZE[], cUser1[], cUsre1[], cVCM[],
> cXTC[], cORFIT[], the order here reflects the order above). These
> arrays, the size of each is equal to the total number of atoms, are
> just handles to determine to which group a certain atoms belongs. I
> will explain that with an example below.
>
> The number of different groups of each group type (Tempcoupl. grp,
> energygrp, accel. grp, freeze grp, user1 grp, user2 grp, com motion
> grp, XTC grp and orientation orientation grp) is stored the atoms
> struct
> (include/types/atoms.h) of the topology struct
> (include/types/topology.h)
>
> It is a bit difficult to explain, so I use an example:
>
> Suppose you have defined two freeze groups groups in your mdp file:
> atomsA and atomsB.
>
> Then the topology.atoms.grps[egcFREEZE] is 3. This means there are
> 3(!) freeze groups, namely, atomsA (0), atomsB (1) and the rest
> (3). This is also printed to the output by grompp by the way.
>
> The elements of the mdatoms.cFREEZE[nratoms] array in mdatoms struct
> (include/types/mdatom.h) are either zero, one or two. If an atom i has
> md.cFREEZE[i]==0, it belongs to the first freeze group, atomsA. if it
> has md.cFREEZE[i]==2, it does belong to the rest (and by definition it
> is not a freeze group, so its positions will be updated in the code).
>
> I think if you follow this, you are there.  So to get acces to atomsA,
> the first freeze group, you have to loop over all atoms and scan for
> the ones that have md.cFREEZE[i]==0 and store them in some other array
> or do whatever you want with them. To get acces to atomsB, you have to
> check for md.cFREEZE[i]==1, and the rest you get by scanning for
> md.cFREEZE[i]==2.
>
> The mdatoms struct is passed on to alomst all important functions, as
> it contains the information mdrun needs to do the dynamics. Therefore
> you can do the scan trick almost everywhere.
>
> I hope I helped you a bit in the right direction,
>
> good luck,
>
> Gerrit