I would like to run a program called QuantiSNP that used Matlab in its code. I am not familiar with Matlab at all. I got the below error message and no output. Any idea how to fix it? FYI, I don't have access to source code of the program....
??? Error using ==> chol Matrix must be positive definite.
MATLAB:posdef
Highly appreciate your help
Jean
It's very hard trying to answer your question without seeing any code but here is some general info about the problem you are facing:
What you see is a Matlab error message. I assume QuantiSNP is a compiled Matlab program so you probably can't debug it. In short it says that at some point the program is trying to calculate the Cholesky factorization using chol() function, but the matrix inside is not positive definite. Most of the time the problem happens because the matrix is actually zero, which in turn is [potentially] caused by an invalid input parameter
Check to see if the parameters you are using (1) are valid and (2) match your environment. If there is an input CSV or TXT file, make sure the path is correct. Make sure numbers make sense. Are there any zeros or extra lines somewhere that should not be there?
Depending on which version of QuantiSNP you have, you may have access to the --verbose switch. Add --verbose to the end of your command (for example quantisnp2.exe firstparam secondparam --verbose) to see some messages on the screen as the program runs through the data. See if you can figure out where it's failing and if it's related to your input parameters.
Take a look the QuantiSNP how-to page to make sure you understand the required parameters and the formatting of the input file.
Related
I am using matlab to automatically parameter and launch a finite element method code. I write a parameter text file that the FEM code will read, and then call for the FEM code with :
[status,cmdout]=system(['FEMApp ' current_folder '\MyFile']);
Sometimes, the FEM App will be unable to complete its task, and send an error message in the command window. Until now, I was able to detect the error message in cmdout, and proceed to the next paramter set.
For an unknown reason, the system command started to behave differently : it gets stuck for seemingly forever (Matlab is always in "busy" mode). Did I change anything without realizing it ?
For now, I am using the following solution :
[status,cmdout]=system(['FEMApp ' current_folder '\MyFile &']);
pause(45)
system(['taskkill' 'FEMProcessus')
It works correctly, but it slows my computation a lot (~ x5), because Matlab will always wait 45 secondes even when the task is completed in much less time.
Can anyone explain the change in behaviour of Matlab ?
Does anyone has a cleverer work around than mine ?
It should be noted that Matlab is an interpreter rather than a compiler. That means it performs a lot of internal operations, hidden from the developer, some of which may require a lot of CPU resources. Finite Element applications are very numerically intense in terms of using CPU and RAM resources. It might not be a good idea to use Matlab for FEM programming. Try to use some numerically-oriented language, like C or Fortran, where you will have full control over memory allocation and arithmetic operations.
I am doing parameter estimation in matlab using lsqnonlin function.
In my work, I need to plot a graph to show the error in terms of lsqnonlin iteration. So, I need to know which iteration is running at each point of time in lsqnonlin. Could anybody help me how I can extract the iteration number while lsqnonlin is running?
Thanks,
You want to pass it an options parameter setting 'display' to either 'iter' or 'iter-detailed'
http://www.mathworks.com/help/optim/ug/lsqnonlin.html#f265106
Never used it myself, but looking at the help of lsqnonlin, it seems that there is an option to set a custom output function, which gets called during every iteration of the solver. Looking at the specification, it seems that the values optimValues.iteration and optimValues.fval get passed into the function, which is probably the things you are interested in.
You should thus define your own function with the right signature, and depending on your wishes, this function prints it on the command line, makes a plot, saves the intermediate results in a vector, etc. Finally, you need to pass this function as a function handle to the solver: lsqnonlin(..., 'OutputFcn', #your_outputfun).
The simple way to do this would be:
Start with a low number of (maximum) iterations
Get the result
Increase the number of iterations
Get the result
If the maximum iterations is used Go to step 3
This is what I would recommend in most cases when performance is not a big issue.
However, if you cannot afford to do it like this, try edit lsqnonlin and go digging untill you find the point where the number of iterations is found. Then change the function to make sure you store the results you need at that point. (don't forget to change it back afterwards).
The good news is that all relevant files seem to be editable, the bad news is that it is not so clear where you can find the current number of iterations. A quick search led me to fminbnd, but I did not manage to confirm that this is actually used by lsqnonlin.
BUG: I used cell-arrays in the underlying functions, bad!
I cannot understand why restarting Matlab result sometimes into more verbose error messages that help me to actually solve problems. Now I am trying to find a command that makes Matlab showing as much information as possible. For example the below index-exceed-dimension error is totally useless with my recursive algorithm -- this is the specific algorithm where Matlab have once revealed the specific line but now for some reason only telling the vacuously the name of the algorithm
Index exceeds matrix dimensions.
Error in Dij (line 65)
Dij_=Dij(ii,jj,[II,k],[r,q_(k)]);
where you can see that I am running the algorithm Dij failing on the line running the algorithm Dij again.
How can I get more information about the error? Or how can I get inside any point in the recursive algorithm? -Linebreak and trying to get inside that point just fires the error.
Add a try catch block on your recursive algorithm, print the information you think it would be valid and then rethrow an error that will terminate your other callbacks silently.
You may use the keyboard matlab function to check the matlab workspace as the recursive function goes on. You can choose to add it just before your error message, so it will be called every time it goes deeper in the recursive level, so that you can check what is going on, or you can add it when the error occurs (on the catch).
This is just a draft, it may contain errors, adapt it into your needs:
try
% recursive routine
catch ext
if strcmp(ext.identifier,'MyPackage:MyRecursiveRoutine:TerminateSilently'))
% Do nothing
else
% Display useful information, you edit it to add information you think would be valid, i.e.:
disp(ext.getReport)
disp(yourVariable)
% get dbstack size, to see how many recursive functions, i.e:
theStack = dbstack;
recursiveCalls=sum(strcmp({theStack.name},'MyRecursiveFcnName'))
% You may even add the keyboard function here, so that you can inspect your workspace:
keyboard
throw(MExcept('MyPackage:MyRecursiveRoutine:TerminateSilently',''));
end
end
Run dbstop if error before running your code to drop to the debugger exactly at the point of error. From there you can inspect the variables, including whatever variable you've carried along to ID the level. You can also run dbstack to see the full call stack.
It is not evident in the description where the bug is because it does not show with which tools I programmed the underlying functions: I used cellarrays and for some reason Matlab returns far worse error messages with cellarrays than with Matrices so:
my genuine recommendation is avoid cellarrays and use matrices -- and if you need to play with a lot of zero cases, use the ready sparse functionalities because they have far better debugging verbosity!
Instead of wasting too much time to debugging, choose the right tools and Matlab is excellent with Matrices and you can see it in the quality of error messages.
I have a problem with ode45. I've defined a function and trying to solve it by ode, but when i run it, it takes so long. I tried to display the "t" input in my function and it showed time step was 10^-8 ! [I do not get any error from ode45]
So i put a breakpoint at the end of my function, and after I Step once, it goes to sym.m file and calls Function delet(h)
function dxr=Dynfun(t,x)
...
dxr=[A;B]
after Step it goes to
function delete(h)
if builtin('numel',h)==1 && inmem('-isloaded','mupadmex') && builtin('numel',h.s)==1 && ~isa(h.s,'maplesym')
mupadmex(h.s,1);
end
end
and that's what makes it too long, because it goes in a loop in there.
what's the problem?! Thanks
Sounds like it's a "stiff" problem to me. I would recommend using a solver that is designed for stiff problems. I would also recommend trying a fixed step solver at a small step size ~ 0.001 and see what the output looks like. If you are breaking in sym.m, sounds like you've some some symbolic logic going on in there. Is there a way you could take your symbolic expression and convert it to a matlab script?
As indicated by macduff, your problem could be stiff. Try ode15s (which is designed for stiff problems) and see if the stepsize still decreases to unacceptably low values.
If that is indeed the case, then your problem might contain a singularity for the initial values you give it. If your problem has dimensions lower than 3, you can define a small event function to get insight into the values at each step, and plot them to see if there is indeed something problematic going on.
Then -- do you really need symbolic math? The philosophy behind that is that it's easier to read for humans, which makes it terrible to deal with for computers :) If you can transform it into something non-symbolic, please do -- this will noticeably increase performance.
Also, more a word of advice, delete is also Matlab builtin function. It is generally a bad idea to name your functions after Matlab buitins -- it's confusing, and can cause a lot of overhead while Matlab is deciding which one to use.
Matlab hangs when I am trying to generate a mex-file. When I run the program like normal everything works and when I try to generate a mex-file matlab gets to the end of the code but nothing happens after that. I have understood that it might have something to do with the figures. I read somewhere that it calls mclWaitForFiguresToDie but I have not understood how to fix it.
One figure should be displayed but it is not displayed while generating the mex-code.