Re: CST branch -- April 30, 2010 - 21:22

Hi,
I tried to do the changes in the __init__ function of Mf class in the file maths_fns/mf.py.
I am not sure about the way of initialization you described in the previous mail. I understand that it is necessary to initialize the lists between the loops, but I would do it in this way:
self.data[i].interactions = zeros(self.num_interactions[i], float64)
I think I can avoid procedure inside the second loop where you suggest to a new data
container initialise and append to the list. Now I can just fill the list:
for j in xrange(self.num_interactions[i]):
    self.data[i].interactions[j]=interactions[i][j]

Am I wrong? Did I misunderstand something?

Moreover, I found that in the __init__ function is necessary  to  extend the dimension of frequencies per field strength. They will be different between (for example) CC and CH interactions. So, what do you think about this:

self.data[i].frq_list = zeros((self.num_interactions[i], num_frq[i], 5), float64)

for j in xrange(num_frq[i]):
                frqH = 2.0 * pi * frq[i][j]
                frqX = frqH / g_ratio
                for k in xrange(self.num_interactions[i]):
                    frqY = frqH * self.data[i].gratio_ext[k] / gh[i]
                    self.data[i].frq_list[k, j, 1] = frqX
                    self.data[i].frq_list[k, j, 2] = frqY - frqX

Small question at the end:
Can it be included in the same patch - both changes belongs to changes in one function or is it too large step?
Best regards,
Pavel

On 13 April 2010 20:13, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:

This is perfect!  Note that 'None' should not be a sting in the lists
but the special None object.  You will also have to append an empty
list between the two loops, and inside the second loop have a new data
container initialised and appended to the list at the current spin
position.  This should be safe to implement.

Cheers,

Edward

On 13 April 2010 19:48, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx> wrote:
> Hi,
> My idea is feeding Mf class with a list of spin-data in form of lists of
> parameters for each interaction. Considering following example of data for
> one particular spin:
>
> interactions      internuclei_distance  gratio_ext     csa      unit_vector
> 'dipole-dipole'               1.02e-10           2.67522e8   'None'
> [0.707,0.707,0.000]
> 'dipole-dipole'               1.50e-10           6.7283e7     'None'
> [0,866,0.000,0.500]
> 'csa1'                           'None'              'None'
> 120e-6    [0.000,0.000,1.000]
> 'csa2'                           'None'              'None'
> 50e-6      [1.000,0.000,0.000]
>
> each column represents a list containing internuclei_distances, gratio_exts,
> csas, unit_vectors ...
>
> So Mf class would get the lists of "interactions", "internuclei_distance",
> "gratio_ext"  ... for each spin and in the __init__() the loop will go first
> over the number of spins and then over the number of interactions i.e.:
>
> for i in xrange( self.num_spin )
>    for j in xrange( self.num_interactions[i] ):
>       self.data[i].interactions[j]=interactions[i][j]
>       self.data[i].internuclei_distance[j]=internuclei_distance[i][j]
>       self.data[i].gratio_ext[j] = gratio_ext[i][j]
>        .
>        .
>        .
>
> Best regards,
> Pavel
>
>
> On 12 April 2010 09:00, Edward d'Auvergne <edward@xxxxxxxxxxxxx> wrote:
>>
>> On 8 April 2010 17:23, Pavel Kaderavek <pavel.kaderavek@xxxxxxxxx> wrote:
>> > Hi,
>> > I would do it as you suggested by "list of list" architecture, the outer
>> > loop would correspond to the loop over spins and the inner loop over the
>> > interactions.
>> > to sum up, here are the suggested changes in the __init__() method
>> > (class
>> > Mf, file mf.py)
>> > currently it is necessary to load for all spins
>> > one unit vector for xh
>> > one bond length for xh
>> > one gyromagnetic ratio of attached nucleus (proton)
>> > one csa
>>
>> Hi,
>>
>> This is correct.
>>
>>
>> > this needs to be changed to:
>> > list of units vectors over all dipole-dipole interactions and two unit
>> > vectors for CST (this correspond to two axially symmetric chemical
>> > shielding
>> > tensors to which the asymmetric chemical shielding tensor can be
>> > decomposed)
>>
>> This is good.  What do you think of having special arguments for
>> these?  For example in the future someone may come up with a better
>> way to handle rhombic and non-collinear CSA (i.e. the spectral
>> densities are different in different directions).  So we could have a
>> system whereby the interactions are classified.  The first dimension
>> of the unit vector list of lists would be the interaction, the second
>> the spin pair, and the third are the 3D coordinates.  A second
>> argument such as 'interactions' could be added to identify each one.
>> I.e. it could be something like:
>>
>> ..., interactions=['dipole-dipole', 'dipole-dipole', 'csa_split1',
>> 'csa_split2'], ...
>>
>>
>> > list of bond lengths
>>
>> This first dimension can match the above 'interactions' arg.
>>
>>
>> > list of gyromagnetic constants of attached nuclei
>>
>> This can also match the interactions arg.  The 'gx' arg could be
>> renamed to gratio_spin and be a single value - the spin being looked
>> at doesn't change, just the interactions.  The 'gh' arg could be
>> changed to something like 'gratio_ext' and turned into a list matching
>> 'interactions'  It would then have a value if the interaction is
>> dipole-dipole, and be set to None for the CSA interactions.  We don't
>> need to specify that the interacting remote spin is covalently
>> attached though.
>>
>>
>> > two "csa" corresponding to mentioned CST tensors mentioned above
>>
>> This could also be a list corresponding to 'interactions'.  Set the
>> values when needed, otherwise use None for dipole-dipole, etc.  The
>> point of having these all lists of the same length is just so that you
>> don't have to deconvolute the incoming data to work out what belongs
>> to what.  You loop over 'interactions' in __init__() and pack the data
>> container using the appropriate data.  It will make the code much
>> cleaner.  What do you think?
>>
>> Regards,
>>
>> Edward
>
>