Hi Charles, Thanks for your reply.
The legacy Xplor "TENSOr" updates the tensor every time step from a current structure and measured RDCs during calculation, and it is written in Fortran. Is that right? Is there the same function in RDCpot or others? If I want to have the steric alignment tensor from its structure at every timestep, similar as TENSOr, during simulated annealing, any suggestions? Write this function into the Fortran code or C++ code then recompile? Where I can add this function? Thanks a lot!! Best wishes, Jie-rong 2008/6/16 <Charles at schwieters.org>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hello Jie-rong-- > > > I have some questions about tensor calculation and C++/Fortran code. > > > > Is there any difference between "calcTensor" in varTensorTools.py and > > "TENSOr" (Sass, 2001) in conventional Xplor-NIH? Are they the same thing? > > > > They are not the same. > > > Does the potential energy terms in python modules e.g. NOEPot, RDCPot, > still > > call the Fortran code of old X-plor to calculate the structure and > penalty > > function? or these new potential functions are only coded in C++ (e.g. > > NOEPot.cc) and nothing to do with the original Fortran? > > > > They have nothing to do with the Fortran code. > > > If the calTensor is called at every cooling cycle to update the alignment > > tensor during simulated annealing, would it be computationally expensive? > > Since it calculates the tensor "outside" the core and put result back to > the > > core to do the structure calculation. Will it be more efficient if the > > function of calcTensor is in the source code and recompiled, or it > doesn't > > matter? > > Probably too slow, and also not necessary. It suffices to periodically > recalculate the tensor (not every timestep). > > > (I am writing a python helper, which is similar to calcTensor. Steric > > alignment tensor can be obtained by sampling the structure over an > > isotropically distributed space (The result is the same as PALES > multiplied > > by a constant). The method is computationally expensive, so I am > wondering > > if it can be improved.) > > Most likely, it can be improved. The first task is to locate > bottlenecks- you might use a Python profiler for this. Once the > bottlenecks are identified, I might be able to give further advice. > > best regards-- > Charles > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> > > iD8DBQFIVqlHPK2zrJwS/lYRArrOAJ0XTo++d7nTan3ZvYwEOiv1UzGwhACfZvO3 > HyW3w6rhma6SGAYHZ5h7Gx0= > =zO0j > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://dcb.cit.nih.gov/pipermail/xplor-nih/attachments/20080618/6f65d451/attachment.html
