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 <[EMAIL PROTECTED]> 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 >> <[EMAIL PROTECTED]> 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 >> >> > > _______________________________________________ relax (http://nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
