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.
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.