Messages

1

SCHNAaP/SCHNArP / Re: GLH_build() Memory Leak

« on: June 03, 2009, 09:55:46 pm »

It took me awhile to incorporate the new code into my code and to perform regression testing, but it is working perfectly.  No memory leak!  Thanks Xiang-Jun!!

2

SCHNAaP/SCHNArP / Re: GLH_build() Memory Leak

« on: May 22, 2009, 01:14:14 am »

Xiang-jun,  I just sent you an e-mail with an example.  I hope this helps.  Thanks so much.  I'm calling GLH_build an insane number of times, which is the only reason this matters.  But, I'm getting good results!  It is a great software suite.

3

SCHNAaP/SCHNArP / GLH_build() Memory Leak

« on: May 15, 2009, 09:11:20 pm »

I took out the printf()s from GLH_build() and hard coded the user-response values that I want, so that I do not have to enter them in every time I run the function.  When I call GLH_build() in a loop, my memory usage increases with each iteration.  I assume this behavior is not wanted.  There seems to be a memory leak somewhere.  I tried looking through the code to make sure the mallocs are all freed, but I have not found any red flags.  Any idea why/where this is happening?

Thanks!

4

SCHNAaP/SCHNArP / Re: SCHNArP: Global Parameters

« on: April 02, 2009, 12:56:59 pm »

I followed your instructions, and found the format of GLH_seq.dat to be something like this for a length two helix:

    2 base-pairs
       X-dsp   Y-dsp    Rise   Incl.    Tip    Twist
A-U     0.30    0.39    0.00   27.52  -24.12    0.00
G-C     0.30    0.39    4.22   27.52  -24.12   31.90

It is the same information as in the *.glh files, removing the first 6 base pair parameters Shear through Open.

I found that selecting (in schnarp) "2. Use GLOBAL helical parameters" then "1. Uniform regular helix" then "5. Other regular double helical structures" is the path that I was looking for, since it prompts for 6 parameters, and I am minimizing the RMSD from the output to my original helix.

I did need to change the Ts to Us in the function comp_base so I wouldn't get the error "Illegal base exists!" and it would find the right file in the folder BaseGeo.  I am getting correct RNA output because I select "RNA" when prompted for "Base geometry set to use (Dft NDB96)."

Everything is working great!

5

SCHNAaP/SCHNArP / Re: SCHNArP/SCHNAaP c source code

« on: March 20, 2009, 10:36:29 am »

To satisfy my curiosity, I wrote a c program that prints out variable byte sizes.  I ran it on the 32 bit machine, and the 64 bit machine.  

Results for 64 bit:
float:  4
double: 8
char:   1
int:    4
long:   8

Results for 32 bit:
float:  4
double: 8
char:   1
int:    4
long:   4

As you can see, the long data type is twice as big in the 64 as in the 32.  In the 64 bit machine, it is not the same size as an int, which is why I was getting the memory error on the 64 bit machine.

6

SCHNAaP/SCHNArP / SCHNArP: Global Parameters

« on: March 19, 2009, 10:13:43 pm »

I am trying to build an RNA using only global parameters (not CEHS parameters).

So, I run schnarp and first enter #2 for "Use GLOBAL helical parameters."  Then I enter #2 again for "Use a full set of GLOBAL parameters."  The next thing schnarp wants is a Sequence-GLH parameter file name.  The default is "GLH_seq.dat".  I've read both READMEs, looked in the Example directory, and googled, but I am not sure how a Sequence-GLH parameter should be formatted.  Of course, I can look through the function step_GLH in rebuild.c to see how it reads in the file and emulate that, but I was wondering if there was a better source of information.

Also, step_GLH calls function comp_base in cmn_fncs.c to ensure no illegal bases exist.  However, only ATCG are hard coded as valid bases.  Since I'm trying to build RNA, I have Uracils.  Is this function going to cause me problems once I do get a GLH_seq.dat file?  Or, does functionality not exist for building RNA from purely global parameters?

Thanks ahead of time!

7

SCHNAaP/SCHNArP / Re: SCHNArP/SCHNAaP c source code

« on: March 18, 2009, 09:51:10 pm »

This problem is seen only on 64 bit machines, but this fix should be applied to nrutil.c regardless of architecture:

nrutil.c:18:    v = (long *) malloc((size_t) ((nh - nl + 1 + NR_END) * sizeof(int)));
nrutil.c:80:    m = (long **) malloc((size_t) ((nrow + NR_END) * sizeof(int *)));
nrutil.c:87:    m[nrl] = (long *) malloc((size_t) ((nrow * ncol + NR_END) * sizeof(int)));

Change sizeof(int) to sizeof(long) on lines 18, 80, and 87 in nrutil.c.

Also, this line:

 #include "cmn_fncs.h"

should be added to pdb2inp.c (thanks Xiang-Jun).

8

SCHNAaP/SCHNArP / Re: SCHNArP/SCHNAaP c source code

« on: March 17, 2009, 12:25:07 pm »

I successfully compiled the code after making the additional changes, which were very easy to do from the helpful comments.  I changed the floats to doubles, and also changed free_vector to free_dvector.

However, when I run one of the examples, I get an error message:
$ schnaap ../Examples/1bna.inp
*** glibc detected *** schnaap: free(): invalid next size (normal): 0x0000000000637910 ***

I think there is a malloc/free issue somewhere in the code.  I will diligently look through the code to try to find the error, but in the meantime I was wondering if you had seen this before.

Relevant info:
Linux version 2.6.22.14-72.fc6
(gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)) #1 SMP

Thanks.

9

SCHNAaP/SCHNArP / SCHNArP/SCHNAaP c source code

« on: March 11, 2009, 07:59:11 pm »

I am working on an RMSD minimization procedure.  I create (with my own c code) an initial RNA helix from a reduced pdb file, then I use 3DNA's analyze and rebuild to make a new helix.  I find the RMSD between the original helix and the one created with rebuild.  I use Powell's minimizatoin method to find bp_step parameters that give the minimum RMSD between the original helix and the one created with 3DNA's rebuild.

My problem is that the minimization procedure calls 3DNA's rebuild many, many times and I have no way of integrating the executables into my c code.  Since I do many other calculations, I need the code to be fast and efficient.

I've read both SCHNAaP and SCHNArP papers, and both conclusions state the source code is available upon request from the authors.

May I access the c code?  I, of course, will be happy to cite the authors' work and take no credit for that particular portion of the methodology.  It would save me a lot of time if I didn't have to rewrite the code myself.