.Maximum number of characters in a .inp line

1

HI,

Ccx do not respond properly when I request a TRANSFORM CARD written like:

*TRANSFORM,NSET=NFace,TYPE=R
-9.42849795070461E-05,0.707071235581443,-0.707142318719276,-0.707071235581443,-9.42849795070461E-05,0

After many attempts it works written like this:

*TRANSFORM,NSET=NFace,TYPE=R
-9.42849795E-05,0.707071235581443,-0.707142318719276,-0.707071235581443,-9.42849795E-05,0

They are essentially the same but one has 101 maximum characters length and the second 89 (I have removed some decimals).
There is a maximum limit of 95 characters on the same line.

I haven’t found nothing said about this limitation on the ccx manual.

Regards

2

Wrong manual. You would better try Fortran manual, the version ccx is written in. Especially integers and floating point numbers. Good luck.

3

I thought Fortran was 72 COLUMNS

4

I do not know Fortran. I cannot help on that.

5

May be to round such a number. Some numbers after period are not reliable at all so drop them off.

6

this is Fortran 77 input file. It can handle input text files with different formats, I think CCX reads numbers with a maximum length of 20 chars, try fixing this (no issue about line length).

7

Exactly!!
Writing a length of 21chars doesn’t fail or warns but gives an incorrect result.
Not sure if the number is omitted or assumed to be zero.

8

CalculiX (just as ABAQUS) reads reals with the f20.0 Fortran format.

I modified the program (Finp.f) here so you can see how it reads the first number in your TRANSFORM keyword above:

        PROGRAM MAIN
        REAL*8 R,S
        CHARACTER LINE1*24 / '-9.42849795070461E-05' / 
        CHARACTER LINE2*24 / '-9.4284979507046E-05' / 
        READ( LINE1, '( F20.0 )') R
        READ( LINE2, '( F20.0 )') S  
        PRINT *, R
        PRINT *, S
        END

compile gfortran Finp.f -o Finp the result is:

  -9.4284979507046103     
  -9.4284979507045996E-005

As you see the first number reads wrong.

9

F77 does have the 72 character line limit.
F90 allows for 80 or so…
In any case, why not try to stay with lower decimal places?

10

Hi jbr,

It’s being an accident. I copy pasted the values from an Excel file and found that error. I agree with you that’s not the right way to represent a number, but it may happen if the inp is build from an external automated input. In fact, the inp we are dealing with in the “composite buckling post” has numbers larger than 20 Chars, so it is not so uncommon. I have informed just in case there could be a warning or fix in some way as the number is read wrong and may pass unnoticed. Not sure if this could also happen internally and not only at inp level.

1 Like
11

Thanks for looking at this Juan. I’m completely ignorant in anything related with programing.

12

I understand. I believe this issue of character lengths and so forth is presented in the documentation. So, I would stay away from anything that comes close to the full lenght of a given type (string, float, etc) since I don’t know how it may break things in the code.

Keep in mind that there can’t be a warning because for the interpreter (fortran input in this case), the number is as read. You should tailor your other tool to export in the “right” format. Well, at least that’s how I try to do it.
The same is true for the number of items on a given line, it should be followed strictly to avoid issues down the road.