Hi,
The difference is not yet obvious because it still needs to be coded.
What needs to be done here is to use generate_spin_id_data_array() in
intensity_generic(), as in the generic_fns.value.read() function. We
need to supply all the 5 spin identifier bits - mol, res, and spin
names and numbers - to generate the spin_id. But here is the problem,
intensity_generic() currently doesn't have access to the mol_col_num,
etc. values! I'll let you try to solve this problem.
Cheers,
Edward
On Thu, Dec 4, 2008 at 8:54 PM, Sébastien Morin
<sebastien.morin.1@xxxxxxxxx> wrote:
Hi Ed,
Ok, the change is made (r8143).
However, it is done in the same way for the intensity_generic() function
as for other intensity_*() functions... I am not sure to understand why
you propose to do it differently in the intensity_generic() function...
As for now, it seems to work fine.
Regards,
Séb :)
Edward d'Auvergne wrote:
On Thu, Dec 4, 2008 at 6:25 PM, Sébastien Morin
<sebastien.morin.1@xxxxxxxxx> wrote:
Hi Ed,
I am not sure I understand all what you say here...
Am I right if I say that you propose to return the spin_id directly from
the intensity_*() functions ? This would simplify the code. Perfect.
That's what I meant.
What about not doing so for the intensity_generic function also ? What
difference would this make ? This is where I don't follow what you
say... That function is not already returning the spin_id, right ?
Ah, the intensity_generic() function also needs to do this! But it
should generate it differently - directly from the generic peak
intensity file. Hope that clears things up.
Regards,
Edward
Re: r8127 - /1.3/generic_fns/spectrum.py