2009/11/27 Michael Bieri <michael.bieri@xxxxxx>:
Hi Edward Thank you very much for the branch. I made some modifications and included your and Sébastien's comments. Unfortunately, I have a problem launching the relax functions. For example by starting the noe calculation, an error appears: Traceback (most recent call last): File "/home/michael/Programme/relax_bieri_gui/gui_bieri/relax_gui.py", line 2645, in exec_noe1 make_noe(self.res_noe1.GetValue(), self.noe_ref_1.GetValue(), self.noe_sat_1.GetValue(), self.noe_ref_err_1.GetValue(), self.noe_sat_err_1.GetValue(), self.nmrfreq_value_noe1.GetValue(),self.structure_noe1.GetValue(), self.unres_noe1.GetValue(), start_relax, self, 1, global_setting, file_setting, sequencefile) File "/home/michael/Programme/relax_bieri_gui/gui_bieri/res/calc_noe.py", line 66, in make_noe pipe.create(pipename, 'noe') NameError: global name 'pipe' is not defined relaxGUI is not able to feed the commands into relax. Do I have to import other modules? Imported relax modules: from float import floatAsByteArray from generic_fns.mol_res_spin import generate_spin_id, spin_index_loop, spin_loop from generic_fns import pipes, spectrum from relax_errors import RelaxError Do you have an idea how to solve this problem?
Hi, This is an easy one. You can solve this by copying how the prompt/script interface does this - and this is how you should replace all calls to user functions. Your GUI replaces the user functions and should go directly to the core relax API. So in this case, have a look at the prompt.pipe module and look at the create() method on line 92 (1.3 line, r9986). You'll see that all this method does is check that what the user input is reasonable - i.e. both the name and method must be strings. Then at the end it passes everything to the generic_fns.pipes.create() function: # Execute the functional code. pipes.create(pipe_name=pipe_name, pipe_type=pipe_type) So all you need in your code, in this case, is to replace 'pipe' with 'pipes'. For every single user function call you can do the same thing - look at what is happening in the 'prompt' package and implement the same thing in the 'bieri_gui' package.
I have another problem relating the OMP data. relaxGUI calculated local_tm model, but it is not able to calculate the others (also the scripts can't calculate). There seems to be a problem with the pdb file, I just don't see at the moment: Internal relax PDB parser. Opening the file '/home/mbieri/LinuxBox/OMP/1F35_mono.pdb' for reading. RelaxWarning: The atom number 80 from the CONECT record cannot be found within the ATOM and HETATM records. RelaxWarning: The atom number 88 from the CONECT record cannot be found within the ATOM and HETATM records. Traceback (most recent call last): File "relaxGUI.py", line 4126, in exec_model_free start_model_free(self, which_model) File "relaxGUI.py", line 1533, in start_model_free Model() File "relaxGUI.py", line 1125, in __init__ structure.read_pdb(PDB_FILE) File "/usr/local/relax-1.3.4/prompt/structure.py", line 464, in read_pdb generic_fns.structure.main.read_pdb(file=file, dir=dir, read_mol=read_mol, set_mol_name=set_mol_name, read_model=read_model, set_model_num=set_model_num, parser=parser) File "/usr/local/relax-1.3.4/generic_fns/structure/main.py", line 247, in read_pdb cdp.structure.load_pdb(file_path, read_mol=read_mol, set_mol_name=set_mol_name, read_model=read_model, set_model_num=set_model_num, verbosity=verbosity) File "/usr/local/relax-1.3.4/generic_fns/structure/internal.py", line 628, in load_pdb mol.fill_object_from_pdb(mol_records) File "/usr/local/relax-1.3.4/generic_fns/structure/internal.py", line 1373, in fill_object_from_pdb self.atom_connect(index1=self.__atom_index(record[1]), index2=self.__atom_index(record[i+2])) File "/usr/local/relax-1.3.4/generic_fns/structure/internal.py", line 1332, in atom_connect if index2 not in self.bonded[index1]: TypeError: list indices must be integers I tried both, the monomer (extracted in pymol) and the dimer.
This one here looks like an old bug I fixed a while ago. Does the same problem occur when using the 1.3 repository line rather than the 1.3.4 release? As for changes to the code, these should be committed in small packets. For repository usage, a commit should only have one function - and if not it should be split up. The reason is because then it allows for commits to be reverted, ported to other branches, etc. and allows the code to be more easily reviewed. When you have something, just type: $ svn diff > patch in the base directory and attach the file to the task (https://gna.org/task/?6847). I can then check the code and commit it. Don't forget to write a commit message describing what the new code does. All of this is explained in greater depth in the manual. Cheers, Edward