What are the limitations of the Matlab fileread command in -nodesktop mode? - matlab

Assuming a text file with 7718 characters (e.g. the contents cut and pasted from here)
The command fileread('myfile.txt') fails when I launch matlab with matlab -nodesktop but works in desktop mode.
Does anyone have any idea why?
If the number of characters in the text file is reduced to 1981 it works in -nodesktop mode.
Note:I do not know the exact number of characters at which it stops working.
Finally, I am using Matlab 7.8.0 (R2009a) on Windows7.

I can't reproduce this odd behaviour (Matlab 2010b & 2012b, both on Linux).
You could at least try to "debug" this type of behaviour by restricting the problem. The "fileread" routine does some checks on the file name (ischar, isempty), then opens the file (fopen), reads it (fread) and closes it (fclose) - rather simple basic stuff. For reference, type "edit fileread" into the command line of the matlab desktop and try running down the routine step by step.
If "fread" causes the whole thing to crash and if you're bound to this version of Matlab, try implementing a "fix". "fread" accepts a few more parameters than what is used in "fileread" (the file ID and the precision "char" only): FREAD(FID,SIZE,PRECISION,SKIP,MACHINEFORMAT). Specifying more parameters may help (wild guess but worth a try).

Related

Running Matlab scripts as ExternalCode Component

I am trying to use some existing matlab scripts within the openmdao. The external code tutorial is straight forward to follow. However, I encounter some issues when modifying the following example for matlab applications.
original code in tutorial:
self.options['command'] = ['python', 'extcode_paraboloid.py', self.input_file, self.output_file]
modified code for matlab applications:
self.options['command'] = ['matlab', '-nodesktop -r "run Paraboloid.m"', self.input_file, self.output_file]
This line is okay to launch matlab. However, other arguments('-r "test.m "') seems have been truncated and can not be interpreted by matlab correctly. The alternative solution I have is to create another .py file for calling os command.
os.system('cmd /c "matlab -nodesktop -r "run Paraboloid.m",quit"')
Any suggestion on how to call the matlab function directly? Thanks!
Try breaking everything up wherever there is a space.
self.options['command'] = ['matlab', '-nodesktop', '-r', '"run Paraboloid.m"', self.input_file, self.output_file]

MATLAB - interaction between MATLAB 32bit and 64bit

PROBLEM
I have two tools written in MATLAB (I am not the author):
the first allows me to retrieve some data from a SQL database, but it works only on MATLAB 64bit (I have MATLAB 2016b 64bit).
the second uses the data retrieved from the first tool and, through
a DLL compiled on a 32bit system, it gets some outputs. As said,
this tool works only MATLAB 32bit (I have MATLAB 2013a 32bit).
What I would like to do is:
get the data from SQL, in MATLAB 64bit
"send them" in some way to MATLAB 32bit
run the tool on MATLAB 32bit
"return" the outputs from MATLAB 32bit to MATLAB 64bit
I know a solution may be found using IPC mechanisms, but I am not sure how to find them or how to use them in MATLAB. Does anyone ever worked with this kind of stuff?
Looking into the MATLAB documentation I saw that it is possible to create a COM object, but I am not sure how to use it to run some functions in MATLAB 32bit.
SOLUTION
As suggested by #nekomatic below, everything works for me if I run the code in the way suggested, but excluding -automatic from the system command below.
The final system command is in the form
system('"C:\path\to\R2013a\matlab.exe" -wait -r "mycommand; exit"')
mycommand is a MATLAB script which loads the input file, it does something and then it saves an output file.
If you don't need this operation to be fast, the easiest way to do it is probably:
Save the data from 64-bit MATLAB as a .mat file
Use the system command to start an instance of 32-bit MATLAB
Run a script in 32-bit MATLAB that reads the data from the file, processes it and saves it
Read the result back in to your 64-bit program.
For example the 64-bit code (excluding error handling, current folder setup, etc) might look something like this:
delete result.mat % Delete any result from the previous run
save(data.mat, '-v7.3') % usually best to specify the .mat format to use
system('"C:\path\to\R2013a\matlab.exe" -automation -wait -r "mycommand; exit"')
processedData = load('result.mat')
where mycommand is your MATLAB R2013a script that reads the data from data.mat, processes it, and saves the result in result.mat.
More data on the startup options for R2013a here (assuming Windows) and on the system command for R2016b here. You may need to be signed in with a Mathworks account to see documentation for older releases, but if that's a problem just look in the help in your respective MATLAB installations.

Running a Matlab p-file coded for Windows on a MacOS

I have several Windows sourced p-files internally coded with the '\' file separator that I want to run on Matlab under macOS.
I get errors caused by the '\' because macOS uses '/'.
eg The pfile tries to call a file named "model\xyz' which causes a warning:
"Name is nonexistent or not a directory: model\ "
1) Is there code that I might insert somewhere to recognise the 'model\' call from the pcode file and change it to 'model/' before it is used by MATLAB addpath?
2) Is there a generic fix I could apply to the addpath code?
3) Or better still is there a way to modify the Windows p-file without access to its source code so that it will run under macOS?
There are several things you can do (none of which are particularly easy; listed here in increasing order of how nasty I think they are):
Contact the author of the code and ask them to fix it.
Install an older MATLAB version (R2007b <= ver < R2015b, I think) which allowed debugging (stepping into) p-files within MATLAB, then, assuming that there is some line in the original source code that does
filepath = ['model' '\' 'xyz.m'];
step until you see filepath appear in the workspace (having the wrong path in it), then simply edit the value to the correct path, and hope for the best.
(Essentially the same idea as before, but on newer MATLAB versions, VERY DIFFICULT to pull off) Obtain an external debugger, attach to the MATLAB process, run the p-file and scan the memory for the contents of filepath. When you discover it, change the value to the correct path and detach/disable the debugger.
If this code relies on some external (and open source) function to get (or use) the path, you can modify its behavior to output the string you want. This requires some knowledge about the source code.
Find/make a tool for decoding p-files and fix the resulting source code yourself.
For completeness I describe how my problem was solved:
As suggested by Dev-iL I was eventually able to locate the author and he modified his code. This is the best solution but it took some time and is not always possible.
Based on: https://au.mathworks.com/matlabcentral/answers/117110-dealing-with-and-windows-vs-unix-for-path-definition I located a module (I've forgotten its name) within the Matlab package which handles file calls and intercepted all incoming file path names containing the '\' Windows separator, and replaced them with the always acceptable '/'. This quick and dirty fix worked until solution 1. was obtained.
Thanks to all who responded so quickly to this question.

export image fails using cmaple.exe but OK using maple.exe

Is there a difference from running the same exact Maple commands to export a plot, when run from GUI interface, using worksheet, vs. from plain text .mpl file using command line Maple?
The following code runs OK from the GUI worksheet, but gives error
Error, invalid FONT specification when run from cmaple.exe.
This is on windows 10.
#file T1.mpl
currentdir("C:/TMP"); #or any other folder of your choice
plotsetup(default); #start from default
#the following commnad below export a plot to a file
plotsetup(ps, plotoutput="t.ps",
plotoptions=`color,noborder,portrait,height=250`);
p0:=DEtools:-DEplot( diff(y(x),x)=x, y(x), x=-2..2, y=-2..2,
'color' = "#00aaff",
'arrows'='medium',
'labels'=["",""],
'thickness'=1
):
#this will send the plot to a file.
print(plots:-display([p0],'view'=[-2..2.4,-2..2.5],
axis=[tickmarks=['color'='red']],
font=["Times",bold,8]
)
);
#ERROR SHOWS HERE
plotsetup(default); #rest back to default
The print command above, does not actually display anything, even on the GUI, since it was redirected to go to a file.
The above code works with no problem in the GUI interface, and the plots is exported OK to t.ps file.
I am trying to run the large Maple code I have from .mpl using command line Maple, hoping it will be faster than in worksheet, but the above problem is making it not possible.
First time trying cmaple.exe
Command I used is
"C:\Program Files\Maple 2018\bin.X86_64_WINDOWS\cmaple.exe" T1.mpl
May be I need an option to add to the command above?
This is using Maple 2018.1
The plot export driver in the Commandline Interface (CLI, aka TTY) does not know about the more modern calling sequences allowed for the various font related plotting options.
In modern Maple the font options can be specified using strings instead of names. That helps users avoid issues with assigning to alternative all-caps name forms, not all of which are protected names.
Unfortunately, it seems as if the CLI plot export driver does not know about the newer string forms. I will submit a bug report.
But you can still use the older, all-caps, name form.
Replace,
font=["Times",bold,8]
by,
font=[TIMES,BOLD,8]
Back when I was quite current with Maple, the answer to this question would have been: the GUI and the TTY version use different plot drivers. And the TTY plot drivers are not as well maintained as the ones for the GUI, and so more recent features do not always work for them.
I am guessing that this is still the case, and that the TTY plot driver doesn't know about fonts.

Problem referencing executable using MATLAB "dos" function

I have a fairly simple question that has me stymied. I am trying to run an executable built from a simple C program using MATLAB as a shell, i.e. using the following MATLAB code:
FileName = ['D:\Users\person\Desktop\MATLAB\GUI','\Program.exe &'];
dos(FileName);
The executable correctly begins running, but crashes giving the error:
Debug Assertion Failed!
Program: D:\Users\person\Desktop\MATLAB\GUI\Program.exe
File: f:\\dd\vctools\crt_bld\self_x86\crt\src\fscanf.c
Expression: (stream != NULL)
The programs opens a text file, reads the input, performs math functions, and writes outputs back to another text file. I assume that this error means there is a problem reading from the text file, BUT-- when I run the executable by itself (i.e. Windows Explorer doubleclick), it executes flawlessly, as I would expect.
So, it's only MATLAB pointing to the file location that is causing the crash. Any ideas? Thank you.
Sounds like relative paths are the culprit. The Matlab command is running from whatever directory you've specified within Matlab; cmd runs from root or something like that (don't know much about Dos). That's why it works when you specify absolute paths. Change your Matlab directory to DOS root, and see if it works as originally coded.
Edit: Note that it's the path to whatever file Program.exe is trying to read that's the problem, not the path to Program.exe itself.