How do I fix USER FATAL MESSAGE 740? This error is generated by Nastran when I try to run a BDF/DAT file of mine.
*** USER FATAL MESSAGE 740 (RDASGN)
UNIT NUMBER 5 HAS ALREADY BEEN ASSIGNED TO THE LOGICAL NAME INPUT
USER ACTION: CHANGE THE UNIT NUMBER ON THE ASSIGN STATEMENT AND IF THE UNIT IS USED FOR
PARAM,POST,<0 THEN SPECIFY PARAM,OUNIT2 WITH THE NEW UNIT NUMBER.
AVOID USING THE FOLLOWING UNIT NUMBERS THAT ARE ASSIGNED TO SPECIAL FILES IN MSC.NASTRAN:
1 THRU 12, 14 THRU 22, 40, 50, 51, 91, 92. SEE THE MSC.NASTRAN INSTALLATIONS/OPERATIONS
GUIDE SECTION ON MAKING FILE ASSIGNMENTS OR MSC.NASTRAN QUICK REFERENCE GUIDE ON
ASSIGN PHYSICAL FILE FOR REFERENCE.
Below is the head of my BDF file.
assign userfile='SUB1_PLATE.csv', status=UNKNOWN, form=formatted, unit=52
SOL 200
CEND
ECHO = NONE
DESOBJ(MIN) = 35
set 30=1008,1007,1015,1016
DESMOD=SUB1_PLATE
SUBCASE 1
$! Subcase name : DefaultLoadCase
$LBCSET SUBCASE1 DefaultLbcSet
ANALYSIS = STATICS
SPC = 1
LOAD = 6
DESSUB = 99
DISPLACEMENT(SORT1,PLOT,REAL)=ALL
STRESS(SORT1,PLOT,VONMISES,CORNER)=ALL
BEGIN BULK
param,xyunit,52
[...]
ENDDATA
Below is the solution
Correct
assign userfile='SUB1_PLAT.csv', status=UNKNOWN, form=formatted, unit=52
I shortened the name of CSV file to SUB1_PLAT.csv. This reduced the length of the line to 72 characters.
Incorrect
assign userfile='SUB1_PLATE.csv', status=UNKNOWN, form=formatted, unit=52
The file management section is limited to 72 characters, spaces included. The incorrect line stretches 73 characters. The nastran reader ignores the 73rd character and on. Instead of reading "unit=52" the reader reads "unit=5" which triggers the error.
|<--------------------- 72 Characters -------------------------------->||<- Characters are ignored truncated ->
assign userfile='SUB1_PLATE.csv', status=UNKNOWN, form=formatted, unit=52
References
MSC Nastran Reference Guide
The records of the first four sections are input in free-field format
and only columns 1 through 72 are used for data. Any information in
columns 73 through 80 may appear in the printed echo, but will not be
used by the program. If the last character in a record is a comma,
then the record is continued to the next record.
I am reading large files in Fortran that contain mixed string/numeric data such as:
114 MIDSIDE 0 0 O0002 436 437 584 438
115 SURFACE M00002 0 0 359 561 560 356
412236 SOLID M00002 O00001 0 86157 82419 82418 79009
Currently, each line is read as a string and then post-processed to identify the proper terms. I was wondering if there is any way to read each line as an integer followed by four strings separated by space, and then some more integers; i.e. similar to '(I10,4(A6,X),4I10)' format, but without any information on the size of each string.
Does not work (charr is empty, iarr(2:5)=0):
INTEGER IARR(5)
CHARACTER*30 CHARR(4)
C open the file with ID=1
READ(1,*)IARR(1),(CHARR(I),I=1,4),(IARR(I),I=2,5)
Works (only for the last line in the data example):
INTEGER IARR(5)
CHARACTER*30 CHARR(4)
C open the file with ID=1
READ(1,'(I10,4(A7,X),4I10)')IARR(1),(CHARR(I),I=1,4),(IARR(I),I=2,5)
The issue is I don't know a-priori what would be the size of each string.
I actually found out the f77rtl flag was used to compile the project, and when I removed the flag, the issue was resolved. So the list-directed input format works just fine.
I am trying to create lookup tables that contain 256 elements. I searched a couple of websites and the best way seemed to create a 2D array since a case structure is very long for my application (I will need 7 other tables).
module LUTE1 (clk, address, data);
input clk;
input [7:0] address;
output reg [31:0] data;
reg [31:0] LTE1 [0:255];
The above compiles fine but it gives the error when I add the below.
LTE1 = '{
32'ha5c66363, 32'h84f87c7c, 32'h99ee7777, 32'h8df67b7b, 32'h0dfff2f2, 32'hbdd66b6b, 32'hb1de6f6f, 32'h5491c5c5,
32'h50603030, 32'h03020101, 32'ha9ce6767, 32'h7d562b2b, 32'h19e7fefe, 32'h62b5d7d7, 32'he64dabab, 32'h9aec7676,
32'h458fcaca, 32'h9d1f8282, 32'h4089c9c9, 32'h87fa7d7d, 32'h15effafa, 32'hebb25959, 32'hc98e4747, 32'h0bfbf0f0,
32'hec41adad, 32'h67b3d4d4, 32'hfd5fa2a2, 32'hea45afaf, 32'hbf239c9c, 32'hf753a4a4, 32'h96e47272, 32'h5b9bc0c0,
32'hc275b7b7, 32'h1ce1fdfd, 32'hae3d9393, 32'h6a4c2626, 32'h5a6c3636, 32'h417e3f3f, 32'h02f5f7f7, 32'h4f83cccc,
32'h5c683434, 32'hf451a5a5, 32'h34d1e5e5, 32'h08f9f1f1, 32'h93e27171, 32'h73abd8d8, 32'h53623131, 32'h3f2a1515,
32'h0c080404, 32'h5295c7c7, 32'h65462323, 32'h5e9dc3c3, 32'h28301818, 32'ha1379696, 32'h0f0a0505, 32'hb52f9a9a,
32'h090e0707, 32'h36241212, 32'h9b1b8080, 32'h3ddfe2e2, 32'h26cdebeb, 32'h694e2727, 32'hcd7fb2b2, 32'h9fea7575,
32'h1b120909, 32'h9e1d8383, 32'h74582c2c, 32'h2e341a1a, 32'h2d361b1b, 32'hb2dc6e6e, 32'heeb45a5a, 32'hfb5ba0a0,
32'hf6a45252, 32'h4d763b3b, 32'h61b7d6d6, 32'hce7db3b3, 32'h7b522929, 32'h3edde3e3, 32'h715e2f2f, 32'h97138484,
32'hf5a65353, 32'h68b9d1d1, 32'h00000000, 32'h2cc1eded, 32'h60402020, 32'h1fe3fcfc, 32'hc879b1b1, 32'hedb65b5b,
32'hbed46a6a, 32'h468dcbcb, 32'hd967bebe, 32'h4b723939, 32'hde944a4a, 32'hd4984c4c, 32'he8b05858, 32'h4a85cfcf,
32'h6bbbd0d0, 32'h2ac5efef, 32'he54faaaa, 32'h16edfbfb, 32'hc5864343, 32'hd79a4d4d, 32'h55663333, 32'h94118585,
32'hcf8a4545, 32'h10e9f9f9, 32'h06040202, 32'h81fe7f7f, 32'hf0a05050, 32'h44783c3c, 32'hba259f9f, 32'he34ba8a8,
32'hf3a25151, 32'hfe5da3a3, 32'hc0804040, 32'h8a058f8f, 32'had3f9292, 32'hbc219d9d, 32'h48703838, 32'h04f1f5f5,
32'hdf63bcbc, 32'hc177b6b6, 32'h75afdada, 32'h63422121, 32'h30201010, 32'h1ae5ffff, 32'h0efdf3f3, 32'h6dbfd2d2,
32'h4c81cdcd, 32'h14180c0c, 32'h35261313, 32'h2fc3ecec, 32'he1be5f5f, 32'ha2359797, 32'hcc884444, 32'h392e1717,
32'h5793c4c4, 32'hf255a7a7, 32'h82fc7e7e, 32'h477a3d3d, 32'hacc86464, 32'he7ba5d5d, 32'h2b321919, 32'h95e67373,
32'ha0c06060, 32'h98198181, 32'hd19e4f4f, 32'h7fa3dcdc, 32'h66442222, 32'h7e542a2a, 32'hab3b9090, 32'h830b8888,
32'hca8c4646, 32'h29c7eeee, 32'hd36bb8b8, 32'h3c281414, 32'h79a7dede, 32'he2bc5e5e, 32'h1d160b0b, 32'h76addbdb,
32'h3bdbe0e0, 32'h56643232, 32'h4e743a3a, 32'h1e140a0a, 32'hdb924949, 32'h0a0c0606, 32'h6c482424, 32'he4b85c5c,
32'h5d9fc2c2, 32'h6ebdd3d3, 32'hef43acac, 32'ha6c46262, 32'ha8399191, 32'ha4319595, 32'h37d3e4e4, 32'h8bf27979,
32'h32d5e7e7, 32'h438bc8c8, 32'h596e3737, 32'hb7da6d6d, 32'h8c018d8d, 32'h64b1d5d5, 32'hd29c4e4e, 32'he049a9a9,
32'hb4d86c6c, 32'hfaac5656, 32'h07f3f4f4, 32'h25cfeaea, 32'hafca6565, 32'h8ef47a7a, 32'he947aeae, 32'h18100808,
32'hd56fbaba, 32'h88f07878, 32'h6f4a2525, 32'h725c2e2e, 32'h24381c1c, 32'hf157a6a6, 32'hc773b4b4, 32'h5197c6c6,
32'h23cbe8e8, 32'h7ca1dddd, 32'h9ce87474, 32'h213e1f1f, 32'hdd964b4b, 32'hdc61bdbd, 32'h860d8b8b, 32'h850f8a8a,
32'h90e07070, 32'h427c3e3e, 32'hc471b5b5, 32'haacc6666, 32'hd8904848, 32'h05060303, 32'h01f7f6f6, 32'h121c0e0e,
32'ha3c26161, 32'h5f6a3535, 32'hf9ae5757, 32'hd069b9b9, 32'h91178686, 32'h5899c1c1, 32'h273a1d1d, 32'hb9279e9e,
32'h38d9e1e1, 32'h13ebf8f8, 32'hb32b9898, 32'h33221111, 32'hbbd26969, 32'h70a9d9d9, 32'h89078e8e, 32'ha7339494,
32'hb62d9b9b, 32'h223c1e1e, 32'h92158787, 32'h20c9e9e9, 32'h4987cece, 32'hffaa5555, 32'h78502828, 32'h7aa5dfdf,
32'h8f038c8c, 32'hf859a1a1, 32'h80098989, 32'h171a0d0d, 32'hda65bfbf, 32'h31d7e6e6, 32'hc6844242, 32'hb8d06868,
32'hc3824141, 32'hb0299999, 32'h775a2d2d, 32'h111e0f0f, 32'hcb7bb0b0, 32'hfca85454, 32'hd66dbbbb, 32'h3a2c1616
};
endmodule
The program is giving the following errors:
** Error: (vlog-13069) C:/Modeltech_pe_edu_10.4a/examples/LUTE1.v(9): near "=": syntax error, unexpected '='.
** Error: C:/Modeltech_pe_edu_10.4a/examples/LUTE1.v(9): (vlog-13205) Syntax error found in the scope following 'LTE1'. Is there a missing '::'?
First a quick note: the '{} syntax is SystemVerilog. Verilog can assign a whole array through system task (e.g. $readmemb or PLA modeling task). It cannot assign a whole array in a single assignment.
LTE1 = '{...}; needs to be in an procedural (initial or always block) or continuous assignment (assign statement and must be a wire type, not reg). You can also assign the array in as part of the declaration: logic [31:0] LTE1 [0:255] = '{...};
There's absolutely nothing "wrong" or "inefficient" about using a large case statement to implement a lookup table. The compiler / synthesis tool would implement the same logic as if you were trying to use the huge two-dimensional array (in SystemVerilog).
This is just fine:
case (address)
8'd0: data_temp = 32'ha5c66363;
8'd1: data_temp = 32'h84f87c7c;
8'd2: data_temp = 32'h99ee7777;
...
There's a bit more text in the code for the large case statement, but efficient use of a good text editor (or even a simple script) can simplify the task of actually creating the code.