I am trying to read a vector components from an external file:
imposed.dat (just one line, numbers separated by commas):
0.0585560952144390,0.121244222730239,0.148358440672875,0.169973557163769,0.188894991200908,0.6376108145572
I can't provide a MWE as the code is large, but this is a piece of it:
OPEN (91,file= 'imposed.dat',form='formatted',status='old')
read(91,*) CU1P(:)
write(*,*) 'read once imposed profile...'
DO J=2,5
write(*,*) 'printf CU1P(J) ',CU1P(J)
END DO
where CU1P is defined as
REAL*8 CU1P(0:129)
The error I get is
forrtl: severe (24): end-of-file during read, unit 91, file /data/forcing/imposed.dat
I have read files like this in the past, so I don't know what's going on, did I miss anything?
Related
I am trying to run a NEURON simulation via python. I got all the libraries in order and am able to run some simple simulations, but am experiencing some troubles with a more complicated code. If you have any idea how to help I will appreciate it very much
Problem number 1:
Neuron doesn't open part of a .hoc file even though it is compiled. I get the error:
NEURON: Can't open import3d/import3d_sec.hoc
in import3d.hoc near line 1
{xopen("import3d/import3d_sec.hoc")}
^
xopen("import3d/i...")
xopen("import3d.hoc")
execute1("{xopen("im...")
load_file("C:/Users/U...")
Problem number 2:
The simulator doesn't recognize a mechanism I am trying to use. here I am a bit lost and don't know to describe further, but this is the error message:
NEURON: Im is not a MECHANISM
in L5PCbiophys5b.hoc near line 26
insert Im
^
xopen("L5PCbiophy...")
execute1("{xopen("L5...")
load_file("C:/Users/U...")
Problem number 3:
Not recognizing as a template:
NEURON: Import3d_Neurolucida3 is not a template
in L5PCtemplate_2.hoc near line 26
nl = new Import3d_Neurolucida3()
^
xopen("L5PCtempla...")
execute1("{xopen("L5...")
load_file("C:/Users/U...")
You can try to use an absolute path
The name for insert should match with the SUFFIX statement in the file; also make sure that file was compiled in and that the dll is loaded (should be a message when you start nrniv)
Perhaps a result of the file xopen problem? If it is a template-containing file you should use load_file() instead of xopen()
In my code I am attempting to read in output files that may or may not have a formatted integer in the first line of the file. To aid backwards compatibility I am attempting to be able to read in both examples as shown below.
head -n 3 infile_new
22
8
98677.966601475651 -35846.869655806520 3523978.2959464169
or
head -n 3 infile_old
8
98677.966601475651 -35846.869655806520 3523978.2959464169
101205.49395364164 -36765.047712555031 3614241.1159234559
The format of the top line of infile_new is '(i5)' and so I can accommodate this in my code with a standard read statement of
read(iunit, '(I5)' ) n
This works fine, but if I attempt to read in infile_old using this, I as expected get an error. I have attempted to get around this by using the following
read(iunit, '(I5)' , iostat=ios, err=110) n
110 if(ios == 0) then
print*, 'error in file, setting n'
naBuffer = na
!rewind(iunit) #not sure whether to rewind or close/open to reset file position
close(iunit)
open (iunit, file=fname, status='unknown')
else
print*, "Something very wrong in particle_inout"
end if
The problem here is that when reading in either the old or new file the code ends up in the error loop. I've not been able to find much documentation on using the read statement in this way, but cannot determine what is going wrong.
My one theory was my use of ios==0 in the if statement, but figured since I shouldn't have an error when reading the new file it shouldn't matter. It would be great to know if anyone knows a way to catch such errors.
From what you've shown us, after the code executes the read statement it executes the statement labelled 110. Then, if there wasn't an error and iostat==0 the true branch of the if construct is executed.
So, if there is an error in the read the code jumps to that statement, if there isn't it walks to the same statement. The code doesn't magically know to not execute the code starting at label 110 if there isn't an error in the read statement. Personally I've never used both iostat and err in the same read statement and here I think it's tripping you up.
Try changing the read statement to
read(iunit, '(I5)' , iostat=ios) n
You'd then need to re-work your if construct a bit, since iostat==0 is not an error condition.
Incidentally, to read a line which is known to contain only one integer I wouldn't use an explicit format, I'd just use
read(iunit, * , iostat=ios) n
and let the run-time worry about how big the integer is and where to find it.
I have a perl script that traverses a set of directories and when it hits one of them it blows up with an Invalid Argument and I want to be able to programmatically skip it. I thought I could start by finding out the file type with the file command but it too blows up like this:
$ file /sys/devices/virtual/net/br-ex/speed
/sys/devices/virtual/net/br-ex/speed: ERROR: cannot read `/sys/devices/virtual/net/br-ex/speed' (Invalid argument)
If I print out the mode of the file with the perl or python stat function it tells me 33060 but I'm not sure what all the bits mean and I'm hoping a particular one would tell me not to try to look inside. Any suggestions?
To understand the stats number you got, you need to convert the number to octal (in python oct(...)).
Then you'll see that 33060 interprets to 100444. You're interested only in the last three digits (444). The first digit is file owner permissions, the second is group and the third is everyone else.
You can look at each of the numbers (in your case all are 4) as 3 binary bits in this order:
read-write-execute.
Since in your case owner, group & other has 4, it is translated (for all of them) to 100 (in binary) which means that only the read bit is on for all three - meaning that all three can only read the file.
As far as file permissions go, you should have been successful reading /sys/devices/virtual/net/br-ex/speed.
There are two reasons for the read to fail:
- Either speed is a directory, (directories require execute permissions to read inside).
- Or it's a special file - which can be tested using the -f flag in perl or bash, or using os.path.isfile(...) in python.
Anyhow, you can use the following links to filter files & directories according to their permissions in the 3 languages you mentioned:
ways to test permissions in perl.
ways to test permissions in python.
ways to test permissions in bash.
Not related to this particular case, but I hit the same error when I ran it on a malicious ELF (Linux executable) file. In that case it was because the program headers of the ELF was intentionally corrupted. Looking at the source code for file command, this is clear as it checks the ELF headers and bails out with the same error in case the headers are corrupted:
/*
* Loop through all the program headers.
*/
for ( ; num; num--) {
if (pread(fd, xph_addr, xph_sizeof, off) <
CAST(ssize_t, xph_sizeof)) {
file_badread(ms);
return -1;
}
TLDR; The file command checks not only the magic bytes, but it also performs other checks to validate a file type.
I make several calls to a function that reads data from an input file. Everything works fine in debug mode, but when I try to run the executable from release mode, the line with fopen crashes the program after a few calls. My code is:
From header file:
#define presstankdatabase "presst_database.txt"
In function:
FILE *fidread;
fidread = fopen(presstankdatabase,"r");
if (fidread==NULL) {
printf("Failed to open pressurant tank database: %s\n",presstankdatabase);
return 1;
}
In debugging, I've inserted comment lines just before and just after the line starting with fidread =, and after several calls the program crashes and I get the message "A problem caused the program to stop working correctly. Please close the program." The comment just before the fopen call is displayed, but the comment just after does not. My understanding of fopen is that is should return either a pointer or NULL, but it crashes before it even gets to the check. The only thing I can think of is that somehow I'm having memory problems, but I don't know how that would fit in with fopen crashing. Does anyone know what might be going on? Thanks!
EDIT 1: I increased the size of three variables, and the only places they're used (except in printf() calls), are as shown below.
char *constid = (char*)malloc(sizeof(char)*20);
Used like so:
strcpy(constid,"Propellant");
strcpy(constid,"Propellant tank");
strcpy(constid,"Pressurant tank");
If the variables are sized to 20, as shown above, it crashes. But if they're larger (I've tried 120 and 100), the program runs. The variables aren't used in any other places other than fprintf() or printf() calls.
presstankdatabase should be a pointer to a string containing the filename to open. If fopen() crashes then that pointer is probably invalid (or NULL). Without any more code it is not possible to debug it further. Use the VC debugger to see what's happening...
EDIT:
Another common cause of this is a filename string that suddenly stops being NULL-terminated.
You should add a printf() call to print the filename before opening. It will most probably fail to produce the expected output. If not, then you have a more interesting form of memory corruption that will take some more work to weed out.
EDIT 2:
If the printf() call shows the correct string, then you probably have memory corruption somewhere else in your code that has mangled some internal structure of the C library. A common cause is going beyond the end (or the beginning for that matter) of a static array or a region provided by malloc().
Before I begin, I must preface by stating that I am a novice when it comes to FORTRAN. I am maintaining a legacy piece of code from 1978. It's purpose is to read in some data values from a file, process the values, and then output the processed values to another text file.
Given the following FORTRAN code:
INTEGER NM,STUBS,I,J,K
PARAMETER (NM=67,STUBS=43)
INTEGER*4 MDS(STUBS,NM)
CALL OPEN$A(A$RDWR,'/home/test/data.txt', MAXPATHLEN,1)
CALL OPEN$A(A$WRIT,'out',11,2)
DO 90 I=1,2
READ(1,82) STUB
!-- data processing --!
WRITE(2,80) STUB,(MDS(I,J),J=1,24)
90 CONTINUE
80 FORMAT(/1X,A24,25I5)
82 FORMAT(1X,A24,25F5,1)
My question is in regards to the WRITE() statement.
I understand that (2,80) refers to the file output stream opened and pointing to the file 'out' and referenced by the numeral 2. I understand that 80 refers to the format statement referenced by label 80.
STUB is used to store the values read from file input 1. These values are what is processed, and saved into MDS(I,J) in the !-- data processing --! section that I have omitted.
Am I correct in assuming that (MDS(I,J),J=1,24) will write 24 integer values to the output file? In other words, looping from 1 to 24?
Yes, you are correct. The syntax (MDS(I,J), J=1,24) is an "implied DO-loop" and is commonly used in situations like this.