[MMTK] VectorField

[Nathalie Reuter]

Hi Konrad,

thanks for your quick response.

> On Jun 16, 2005, at 16:52, Nathalie Reuter wrote:
>
>> I used to calculate vector fields (of normal modes vibrations) and it 
>> worked really fine with MMTK-2.4.1.
>> I upgraded to 2.5.7 and got the following error message:
>
>
>
> I thought I had fixed that in 2.5.7, but I will check again.
>
>> Has something been changed in the Modes object?
>
>
>
> Yes, a lot. The normal mode module has been replaced by a subpackage 
> containing separate modules for energetic, vibrational, and Brownian 
> normal modes. The error message you get is due to that restructuring, 
> as some internal attribute names have changed. When modes created with 
> older versions are loaded into 2.5, they need to be adapted, and 
> apparently that doesn't yet work as well as I thought it did.
>
> If your mode calculation is not expensive, just redo it with 2.5. 


Ok, now I did the modes calc. with 2.5 and I got a different error message:

File "vector_field.py", line 24, in ?
   field = AtomicVectorField(universe, 0.3, modes[13])
 File 
"/net/bccs/cbu/linux/PYTHON/Python-2.4.1/lib/python2.4/site-packages/MMTK/Field.py", 
line 256, in __init__
   AtomicField.__init__(self, system, grid_size, values)
 File 
"/net/bccs/cbu/linux/PYTHON/Python-2.4.1/lib/python2.4/site-packages/MMTK/Field.py", 
line 43, in __init__
   self._setField(values)
 File 
"/net/bccs/cbu/linux/PYTHON/Python-2.4.1/lib/python2.4/site-packages/MMTK/Field.py", 
line 80, in _setField
   array[indices] = v
AttributeError: Vector instance has no attribute '__float__'


> Otherwise, be patient for a while, I won't be able to look into this 
> before next week.


That is absolutely ok for me. My main objective was simply to upgrade to 
v2.5. It is just by chance that I chose a modes file calc. with v2.4 to 
test my 25. installation ;o).

> If you have an example file that you can send me, that speeds thing up.


> BTW, note that mode files generated with 2.5 cannot be read with 2.4.


Good to know.

> I may or may not fix that in the future, it certainly does not have a 
> high priority. In any case, only vibrational modes could be made 
> backwards compatible.


That is fine for me, I don't need to use files from one version to the 
other anyway.