I am running a code that uses the fitsread function to open my fits movies and analyse them. It was working perfectly fine until about a week ago, when, without me doing anything, it started giving the following error whenever I try to run it:
Error using matlab.io.fits.openFile (line 48)
Unable to open file. File might be corrupt or filename might have unsupported
characters.
Error in fitsread>read_image_hdu (line 412)
fptr = fits.openFile(info.Filename);
Error in fitsread (line 125)
data = read_image_hdu(info,1,raw,pixelRegion);
I have tried manually checking the properties of such files using the fitsinfo function and nothing was wrong with the files themselves. I have also tried to re-set the default MATLAB path, delete them from the working folder and re-download them from a central University server where they were originally stored upon acquisition on a microscope, but it didn't help either. A collaborator has tried running the same code on his machine and it works well. I get this same error on both MATLAB versions R2011b and R2015b. It originally used to work on R2011b with the same files.
Thanks in advance to whoever will be able to help!
Related
I have a stand alone script, that opens a QGIS project file in order to extract details.
I accidentally moved a file and the script broke. Below is the interesting part.
QgsApplication.setPrefixPath("/usr", True)
project = QgsProject.instance()
qgs = QgsApplication([], False)
qgs.initQgis()
project.read('/home/jdoe/textproj.qgz')
# invalid path, but does not fail or warn in any way
print(project)
# prints: <QgsProject:'/home/jdoe/textproj.qgz'(singleton instance)>
# no indication of any problems with loading file
Question 1 - Why no error?
I think everyone would expect it to fail (throwing an exception). Is there any good reason for it to behave different than failing?
Question 2 - How to properly load a project from a file?
Is there anything in my code that that is is using the library differently that intended, which may partly explain why I got no errors?
Question 3 - How do I make sure it fails?
Of course I could write my own assertion to test if the path does point to a file. But I guess there could be other ways in which reading/loading a project file could fail. So what is the proper way of catching this right away?
I have problems translating Modelica models with Dymola 2020: When I try to translate the models, the following error message appears:
"unknown internal error in Dymola".
The model was translating and simulating a couple of days ago, and the same model still runs on the computer of other colleagues. I didn't change the compiler in between nor the Dymola version. I've also restarted the computer but the problem persists.
Also, other models are still translating, so not all models are affected by this error.
Does anyone have a clue how to debug this error? Thank you very much for all hints!
The most likely explanation would be some weird setting of some flag.
You can see if you have any odd settings of normal flags by:
Dymola 2020: Edit>Options>General>Flags... Check "Non-default"
Dymola 2020x: Tools>Options>General>Flags... Check "Non-default"
(If it is a non-Boolean setting it is a bit messier.)
That is assuming it is really the same model and there is no difference in any model in the path (including working directory).
Frankly speaking, if you get "unknown internal error in Dymola" you should report it to technical support at Dassault Systèmes (through your reseller), and let them debug it.
It is not your job to debug such errors.
Have you tried to delete the content from the working directory (WD)?
Sometimes there are artifacts, which mess up the compilation of a specific model.
You can check where it is, using the
GUI, File -> Working Directory -> Copy Path and paste it in the Explorer
Command line typing cd, which returns the path to the WD
Then make sure that there are no important files in the WD (usually .mo files) and finally delete the full content of the directory.
Note: You should ensure that the WD is a local path (otherwise performance can take a serious hit). Besides that it is usually a good idea to have the WD separated form the directory where models are stored.
I was going through the example of FRDM-KL25Z library in MATLAB Simulink and having some problems when deploying it to the board.
1) Most of the H files are missing in the directory during (compiling?) and was FIXED by downloading individually from website.
2) After the H files are fixed, MATLAB prompt me another error stating FILE_DIR/TOOLCHAIN_GCC_ARM/libmbed.a' needed by ".../freedom_board_servo.elf'
I'm quite new to this field so was hoping someone can guide me through these errors as I have been stuck here doing nothing for few days fixing errors and errors.
Thanks.libmbed.a ERROR
Hi all the problem is fixed by changing the directory of the file.
During installation MATLAB have named the directory wrongly "8e73be2a2ac1" was supposed to be named to "mbed-8e73be2a2ac1".
I'm seeing some very strange behavior with FileMaker 14. I'm using LayoutObjectNames for some required functionality. On the development system it's working fine. It returns the list of named objects on the layout.
I close the file, zip it up and send it to the client, and that required functionality isn't working. He sends the file back and I open it and get a data viewer up. The function returns nothing. I go into layout mode and confirm that there are named objects on the layout.
The first time this happened and I tried recovering the file. In the recovered file it worked, so I assumed some corruption had happened on his end. I told him to trash the file I had given him and work with a new version I supplied. The problem came up again.
This morning he sent me the oldest version that the problem manifested in. I confirmed the problem, tried recovering it again, but this time it didn't fix the problem.
I'm at a loss. It works in the version I send him, doesn't on his system. We're both using FileMaker 14, although I'm using Advanced. My next step will be to work from a served file instead of a local one, but I have never seen this type of behavior in FileMaker. Has anyone seen anything similar? Any ideas on a fix? I'm almost ready to just scrap the file and build it again from scratch since we're not too far into the project.
Thanks, Chuck
There is a known issue with the Get (FileName) function when the file name contains dots (other that the one before the extension). I will amend my answer later with more details and a possible solution (I have to look it up).
Here's a quote from 2008:
This is a known issue. It affects not only the ValueListItems()
function, but any function that requires the file name. The solution
is to include the file extension explicitly in the file name. This
works even if you use Get (FileName) to return the file name
dynamically:
ValueListItems ( Get ( FileName ) & ".fp7" ; "MyValueList" )
Of course, this is not required if you take care not to use period
when naming your files.
http://fmforums.com/forums/topic/60368-fm-bug-with-valuelistitems-function/?do=findComment&comment=285448
Apparently the issue is still with us - I wonder if the solution is still the same (I cannot test this at the moment).
I have got this really strange error in matlab. When I try to run the command
save(fullfile('filepath','filename'),'var','-v7');
I get the error message,
error using save can't write file
but when I try
save(fullfile('filepath','filename'),'var','-v7.3');
everything works fine. The the variable takes some space on the workspace, 165MB, but the I would guess that the size should not be an issue here. Does anyone know why it does not work to save in v7?
For the one that want to confirm the size of the variable, I will add the whos information,
Name Size Bytes Class Attributes
myName 1x1 173081921 struct
BR/ Patrik
EDIT
The variable I try to save is a struct with plenty of fields. I have tried to save a 3 dimensional matrix of size 800 mb, which went through without problems.
This is not an exact match to your problem, but I received the same error message when trying to save to -v6 format. Matlab is supposed to issue an error when a variable type or size is not supported:
help save
...
If any data items require features that the specified version does not support, MATLAB does not save those items and issues a warning. You cannot specify a version later than your version of MATLAB software.
Matlab's error checking seems to not be perfect, because there are certain situations (dependent on Matlab version and the particular variable type) that just fail all together with this not so helpful error message:
Error using save
Can't write file filename.mat.
For example, saving a string with certain unicode characters with the '-v6' option in Matlab r2015b in Linux produces the error, but Matlab r2016a in Windows does not. This is the output from my Matlab r2015b session:
>> A=char(double(65533))
A =
?
>> save('filename.mat','-v6','A')
Error using save
Can't write file filename.mat.
Without having your specific variable to test with, but seeing that the error messages match, I suggest removing parts of your data structure until it will save in order to isolate the variable that is causing it to fail.