Thank you for your good advice and excellent practical experience. I will pay attention to and comply with the recommendations in the future.

Yours, Hongyi

I'm sorry the author of that comment has such limited experience. If they had access to your hex output they should have seen that there really weren't any such reals or double precision numbers. Many of the bytes were nulls and just a few ")", "|", and "?".

I think he commented on how to ensure the correctness of the final data in general.

But the main source of whether what is found by the Mathematica code or your grep/sed/awk commands is legit is your assessment of the output found so far. If what comes out (rows of 9 elements, two of which are character strings) matches what you think should be there, then that's all that's needed.

And, yes, going through the Fortran code would answer this decisively. However, I'm not going to take the time for that. But to repeat, that really doesn't appear necessary in this case.

I want data and metadata, which together determine the structure of the data and the corresponding meaning of its fields. For this purpose, only the accurate reading method consistent with the Fortran source code is meaningful in the subsequent data analysis. Otherwise, what I finally get is a pile of meaningless garbage.

The internet is full of ignorant responses. (Including me sometimes.)

Nobody is perfect; everyone makes mistakes. It is important to thoroughly understand what we really want, and constantly seek, explore, and finally achieve our goals.

I'm sorry the author of that comment has such limited experience. If they had access to your hex output they should have seen that there really weren't any such reals or double precision numbers. Many of the bytes were nulls and just a few ")", "|", and "?".

But the main source of whether what is found by the Mathematica code or your grep/sed/awk commands is legit is your assessment of the output found so far. If what comes out (rows of 9 elements, two of which are character strings) matches what you think should be there, then that's all that's needed.

So, yes, in general one does need to worry about reals and double precision numbers stored as binary characters. But it doesn't appear to be the case for your files.

And, yes, going through the Fortran code would answer this decisively. However, I'm not going to take the time for that. But to repeat, that really doesn't appear necessary in this case.

The internet is full of ignorant responses. (Including me sometimes.)

Updated code above.

As far as your revised version is concerned, I have the following comments:

(1) In the ultimate output, I think you should restore the changes you've done by "GM-" to "GMminus" as an expedience.

(2) I checked with kLG_ 158.data, and find the following strange output:

{FkSUFkSUFkSUFkSU}

This is obviously not reasonable data.

BTW, if you are on *nix platforms, the following method can be used to quickly check the content of these files, taking kLG_ 158.data as an example:

$ strings kLG_158.data | grep -v '^\?' | sed -re 's/\($//' | awk '!a[$0]++'
P3c1      
0 0 0.5 1 A1 1 12 A 0                   
0 0 0.5 1 A2 1 12 A 0                   
0 0 0.5 1 A3 2 12 A -1                  
0 0 0.5 1 -A4 1 12 A 1                  
0 0 0.5 1 -A5 1 12 A 1                  
0 0 0.5 1 -A6 2 12 A 1                  
0 0 0.427 0 DT1 1 12 DT 0               
0 0 0.427 0 DT2 1 12 DT 0               
0 0 0.427 0 DT3 2 12 DT 0               
0 0 0.427 0 -DT4 1 12 DT 0              
0 0 0.427 0 -DT5 1 12 DT 0              
0 0 0.427 0 -DT6 2 12 DT 0              
0 0 0 1 GM1 1 12 GM 1                   
0 0 0 1 GM2 1 12 GM 1                   
0 0 0 1 GM3 2 12 GM 1                   
0 0 0 1 -GM4 1 12 GM 0                  
0 0 0 1 -GM5 1 12 GM 0                  
0 0 0 1 -GM6 2 12 GM -1                 
0.333333 0.333333 0.5 1 H1 1 6 H -1     
0.333333 0.333333 0.5 1 H2 1 6 H -1     
0.333333 0.333333 0.5 1 H3 1 6 H -1     
0.333333 0.333333 0.5 1 -H4 1 6 H 1     
0.333333 0.333333 0.5 1 -H5 1 6 H 1     
0.333333 0.333333 0.5 1 -H6 1 6 H 1     
0.333333 0.333333 0 1 K1 1 6 K 1        
0.333333 0.333333 0 1 K2 1 6 K 1        
0.333333 0.333333 0 1 K3 1 6 K 1        
0.333333 0.333333 0 1 -K4 1 6 K -1      
0.333333 0.333333 0 1 -K5 1 6 K -1      
0.333333 0.333333 0 1 -K6 1 6 K -1      
0.333333 0.333333 0.427 0 P1 1 6 P 0    
0.333333 0.333333 0.427 0 P2 1 6 P 0    
0.333333 0.333333 0.427 0 P3 1 6 P 0    
0.333333 0.333333 0.427 0 -P4 1 6 P 0   
0.333333 0.333333 0.427 0 -P5 1 6 P 0   
0.333333 0.333333 0.427 0 -P6 1 6 P 0   
0.123 0 0.427 0 D1 1 4 D 0              
0.123 0 0.427 0 D2 1 4 D 0              
0.123 0 0.427 0 -D3 1 4 D 0             
0.123 0 0.427 0 -D4 1 4 D 0             
0.5 0 0.5 1 L1 1 4 L 0                  
0.5 0 0.5 1 L2 1 4 L 0                  
0.5 0 0.5 1 -L3 1 4 L 1                 
0.5 0 0.5 1 -L4 1 4 L 1                 
0.5 0 0 1 M1 1 4 M 1                    
0.5 0 0 1 M2 1 4 M 1                    
0.5 0 0 1 -M3 1 4 M 0                   
0.5 0 0 1 -M4 1 4 M 0                   
0.123 0 0.5 0 R1 1 4 R 0                
0.123 0 0.5 0 R2 1 4 R 0                
0.123 0 0.5 0 -R3 1 4 R 0               
0.123 0 0.5 0 -R4 1 4 R 0               
0.123 0 0 0 SM1 1 4 SM 0                
0.123 0 0 0 SM2 1 4 SM 0                
0.123 0 0 0 -SM3 1 4 SM 0               
0.123 0 0 0 -SM4 1 4 SM 0               
0.5 0 0.427 0 U1 1 4 U 0                
0.5 0 0.427 0 U2 1 4 U 0                
0.5 0 0.427 0 -U3 1 4 U 0               
0.5 0 0.427 0 -U4 1 4 U 0               
0.123 0.313 0 0 B1 1 2 B 0              
0.123 0.313 0 0 -B2 1 2 B 0             
0.123 0.123 0.427 0 C1 1 2 C 0          
0.123 0.123 0.427 0 -C2 1 2 C 0         
0.123 0.313 0.5 0 E1 1 2 E 0            
0.123 0.313 0.5 0 -E2 1 2 E 0           
0.123 0.313 0.427 0 GP1 1 2 GP 0        
0.123 0.313 0.427 0 -GP2 1 2 GP 0       
0.123 0.123 0 1 LD1 1 2 LD 1            
0.123 0.123 0 1 -LD2 1 2 LD -1          
0.123 0.123 0.5 1 Q1 1 2 Q -1           
0.123 0.123 0.5 1 -Q2 1 2 Q 1         

(3) The corresponding FORTRAN code snippet that reads these files appears to be located here. But I failed to figure out the logic used by it.

Regards, HZ

(1) I wanted to ignore all characters below character code 32, and remove characters with character codes 63 (?), 124 (|), and 240 (ð - hex f0).

(2) That was a mistake in the comment I wrote. Sorry about that. I meant to have used "(" rather than ")". I've now fixed that. (A new record seemed to start with "(".)

(3) Logic? I opened up the file in NotePad and saw what appeared to be lines of data surrounded by nulls and some odds and ends of other characters. The "(" character seemed to precede each line of data. Other characters also seemed to consistently precede the start of a record (such as a hex 10) and could have been chosen to do the job.

I still have some questions about your code, as described below.

(1). How did you come up with the following code?

      (*Remove some characters*)
        data = Select[data, # >= 32 && # != 124 && # != 240 && # != 63 &];

(2). You have used the following code snippet:

(*Change ")" to "},{" pair*)

data = Flatten[data /. 40 -> {125, 44, 123}];

But the ")" in the decimal ascii table is represented by 41, as shown below:

$ ascii -d | grep -Eo '(12[35]|4[014]) [^ ]+'
40 (
41 )
123 {
44 ,
125 }

(3). What is the correspondence between your data extraction logic and the structure of the file shown below? The attached file is the internal format of this FORTRAN binary shown in Emacs obtained by (M-x hexl-find-file): (4). In fact, I've so many such Fortran binary files located here, and your above code can only manipulate/handle the one discussed in this issue. I want to find a general method to deal with all these files.

Regards, HZ