• Format Question regarding a NASTRAN Input File

    From Eberhard Franz@21:1/5 to All on Thu Oct 13 08:44:29 2022
    Dear colleagues,

    I am currently analyzing the structure of NX NASTRAN input files ("bulk.dat"). I came across a table with two pairs of values.

    If you use 0.0 as both the abscissa and ordinate as the first pair of values and choose 2E6 and 7E12 for the second pair of values, NX writes the following output line to the file:
    bb0.0000bb0.00002.0000+67.000+12
    If you choose 1.0 and 22300 for the second pair of values, NX writes to the file:
    bb0.0000bb0.00001.00000022300.00
    For the second pair of values 1.0 and 700, NX writes: bb0.0000bb0.00001.000000700.0000
    "b" stands for a space.

    Does anyone have an idea with which Fortran format the output described above can be generated?

    I am very grateful for every hint, many thanks in advance

    muppets

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to muppe...@googlemail.com on Thu Oct 13 11:13:44 2022
    On Thursday, October 13, 2022 at 8:44:31 AM UTC-7, muppe...@googlemail.com wrote:

    (snip)

    Does anyone have an idea with which Fortran format the output described above can be generated?

    Trying with gfortran and output in 1PE8.3, I get ******** for all values.

    I don't right now have any running Fortran 66 compiler to test it on.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to muppe...@googlemail.com on Thu Oct 13 11:07:37 2022
    On Thursday, October 13, 2022 at 8:44:31 AM UTC-7, muppe...@googlemail.com wrote:
    Dear colleagues,

    I am currently analyzing the structure of NX NASTRAN input files ("bulk.dat"). I came across a table with two pairs of values.

    If you use 0.0 as both the abscissa and ordinate as the first pair of values and choose 2E6 and 7E12 for the second pair of values, NX writes the following output line to the file:
    bb0.0000bb0.00002.0000+67.000+12

    These look like formats that were not rare in the punched card days for input. I am not so sure now about output formats.

    Looking at 7.000+12, this would be 1PE8.3.

    There is, however, the G format which allows the selection
    between F and E, depending on the value.

    So, my next thought is 1PG8.3

    You need the 1P, otherwise there is a leading 0 before the decimal point.

    The output is allowed to omit the E, and just put the signed exponent,
    if there is not enough space. It seems it is also allowed to omit the
    leading sign, and column to print it in.

    Reading the Fortran 66 explanation, I believe that works.
    I am not so sure that the newer explanation is as easy to read.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to muppe...@googlemail.com on Thu Oct 13 16:31:01 2022
    On Thursday, October 13, 2022 at 8:44:31 AM UTC-7, muppe...@googlemail.com wrote:
    Dear colleagues,

    I am currently analyzing the structure of NX NASTRAN input files ("bulk.dat"). I came across a table with two pairs of values.

    As far as I know, those are legal for an input format such as F8.0.

    But I believe that NASTRAN does its own I/O conversion much of the time.

    Since the input format allows mixing of alphanumeric fields and
    numeric fields, it isn't so easy.

    And Fortran 66 doesn't have internal I/O, to make it easy to do such conversions after they are read in as characters.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Fri Oct 14 00:21:19 2022
    With other variants of NASTRAN, such as NASTRAN 93 an MYSTRAN the code is available, and I did not look at NX NASTRAN but I would guess the format of the file is in their documenation or available on request? That might be easier than guessing how the
    file was written, which could be a compound format or conditionally selected, etc.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Fri Oct 14 00:15:27 2022
    On Thursday, October 13, 2022 at 7:31:03 PM UTC-4, gah4 wrote:
    On Thursday, October 13, 2022 at 8:44:31 AM UTC-7, muppe...@googlemail.com wrote:
    Dear colleagues,

    I am currently analyzing the structure of NX NASTRAN input files ("bulk.dat"). I came across a table with two pairs of values.
    As far as I know, those are legal for an input format such as F8.0.

    But I believe that NASTRAN does its own I/O conversion much of the time.

    Since the input format allows mixing of alphanumeric fields and
    numeric fields, it isn't so easy.

    And Fortran 66 doesn't have internal I/O, to make it easy to do such conversions after they are read in as characters.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arjen Markus@21:1/5 to John on Fri Oct 14 00:45:26 2022
    On Friday, October 14, 2022 at 9:21:21 AM UTC+2, John wrote:
    With other variants of NASTRAN, such as NASTRAN 93 an MYSTRAN the code is available, and I did not look at NX NASTRAN but I would guess the format of the file is in their documenation or available on request? That might be easier than guessing how the
    file was written, which could be a compound format or conditionally selected, etc.

    The Fortran Discourse forum currently has a thread on MYSTRAN - https://fortran-lang.discourse.group/t/fortran-project-finite-element-solver/4529/3.
    Their site mentions a forum, perhaps they can offer specific help?

    Regards,

    Arjen

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to John on Fri Oct 14 00:53:08 2022
    On Friday, October 14, 2022 at 12:21:21 AM UTC-7, John wrote:
    With other variants of NASTRAN, such as NASTRAN 93 an MYSTRAN
    the code is available, and I did not look at NX NASTRAN but I would
    guess the format of the file is in their documenation or available on request?
    That might be easier than guessing how the file was written, which
    could be a compound format or conditionally selected, etc.

    I have what, as far as I know, is the NASA version.
    There is a big file explaining the file format.

    The question seems not to be what is the file format, but why.
    Or another way to look at it, how to write that from Fortran.

    It might be that Fortran would write that at the time, but I think it
    doesn't anymore. The conversion routines are, I believe written
    in Fortran.

    The format gets ten 8 character fields on a (80 column) card.
    There is an alternate form that gets 16 character fields, except for the first and last,
    on two cards. And also a free-form way for Unix and VAX with longer lines.

    And then programs to convert between them.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to muppe...@googlemail.com on Fri Oct 14 01:33:09 2022
    On Thursday, October 13, 2022 at 8:44:31 AM UTC-7, muppe...@googlemail.com wrote:
    Dear colleagues,

    I am currently analyzing the structure of NX NASTRAN input files ("bulk.dat"). I came across a table with two pairs of values.

    A big part of bulk card I/O is ffread.f
    There are many smaller routines that help do conversion, such as rcard.f, rcard2.f,
    and similar names.

    Even though it is supposed to be form the 1960s, there are a lot of
    CHARACTER variables, and also internal I/O. So, much of it has been
    rewritten over the years.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eberhard Franz@21:1/5 to All on Fri Oct 14 05:45:22 2022
    gah4 schrieb am Freitag, 14. Oktober 2022 um 09:53:10 UTC+2:
    ....

    The question seems not to be what is the file format, but why.
    Or another way to look at it, how to write that from Fortran.

    First of all: thank you very much for your answers.
    I would like to explain briefly why I am asking this question. I'm currently investigating the behavior of finitely long, thin-walled and non-round cylinders under external pressure. A total of about 1000 geometrically non-linear FE analyzes result from
    this.
    Doing this via the GUI would take a very long time. With the evaluation, an FE analysis takes about 20 minutes. So I would like to create the bulk files with one or more Fortran programs automatically and start NASTRAN via the command line in a batch
    file in a second step.

    The specific example from my first post is about writing a TABLED1 record. The reason for my question was indeed how to write this in Fortran as simply as possible.
    I keep searching. If I find a solution, I'll write about it.

    muppets

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to muppe...@googlemail.com on Fri Oct 14 14:09:44 2022
    On Friday, October 14, 2022 at 5:45:24 AM UTC-7, muppe...@googlemail.com wrote:
    gah4 schrieb am Freitag, 14. Oktober 2022 um 09:53:10 UTC+2:
    ....
    The question seems not to be what is the file format, but why.
    Or another way to look at it, how to write that from Fortran.

    (snip)

    . So I would like to create the bulk files with one or more Fortran programs
    automatically and start NASTRAN via the command line in a batch file in a second step.

    (snip)
    The reason for my question was indeed how to write this in Fortran as simply as possible.
    I keep searching. If I find a solution, I'll write about it.

    As well as I know it, there is the 8 column form and 16 column form, and a program
    to convert the latter to the former.

    It seems to me that the easiest way is to write the latter and use that program.

    Current Fortran input routines will accept values without the E,
    but not always write them. I am not sure that Fortran 66 programs would
    write them, but the standard sounds like they might.
    (I believe some will write them with three digit exponents, though.)

    If the number is positive, you don't need to leave a column for sign.
    If the exponent is only one digit, you don't need a leading zero.
    And you don't need the E if you have the sign.

    But I don't think they will write them that way now.

    There is also a free-form input routine, and I believe again a program to convert
    to the 8 column form.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Fri Oct 14 15:02:35 2022
    On Friday, October 14, 2022 at 5:09:46 PM UTC-4, gah4 wrote:
    On Friday, October 14, 2022 at 5:45:24 AM UTC-7, muppe...@googlemail.com wrote:
    gah4 schrieb am Freitag, 14. Oktober 2022 um 09:53:10 UTC+2:
    ....
    The question seems not to be what is the file format, but why.
    Or another way to look at it, how to write that from Fortran.
    (snip)
    . So I would like to create the bulk files with one or more Fortran programs
    automatically and start NASTRAN via the command line in a batch file in a second step.
    (snip)
    The reason for my question was indeed how to write this in Fortran as simply as possible.
    I keep searching. If I find a solution, I'll write about it.
    As well as I know it, there is the 8 column form and 16 column form, and a program
    to convert the latter to the former.

    It seems to me that the easiest way is to write the latter and use that program.

    Current Fortran input routines will accept values without the E,
    but not always write them. I am not sure that Fortran 66 programs would write them, but the standard sounds like they might.
    (I believe some will write them with three digit exponents, though.)

    If the number is positive, you don't need to leave a column for sign.
    If the exponent is only one digit, you don't need a leading zero.
    And you don't need the E if you have the sign.

    But I don't think they will write them that way now.

    There is also a free-form input routine, and I believe again a program to convert
    to the 8 column form.
    That is what I remember. The 16-character field seems like a good idea; but if I remember correctly there were ten 8-characters fields you could write into with basically any format, but if you have e+-NN and a period and a possible leading sign you are
    down to two significant digits without using a compressed format, so just writing everything with an E/ES/EN format is no good with a field that short. So as suggested, write into 16 and let the program compress the numbers down. Years ago we used to
    modify the vendor compilers to write in that format, which I think the CDC machines may have originated. There were several reasons people used to say that format was useful,
    having to do with tab stops every eight characters, using the minimal number of cards for input, etc. but not sure if any of them are true;
    but really surprised that appears to still be the format for a bulk file.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to John on Fri Oct 14 18:22:50 2022
    On Friday, October 14, 2022 at 3:02:37 PM UTC-7, John wrote:

    (snip)

    That is what I remember. The 16-character field seems like a good idea;
    but if I remember correctly there were ten 8-characters fields you could write into with basically any format, but if you have e+-NN and a period
    and a possible leading sign you are down to two significant digits
    without using a compressed format,

    I just remembered that you could use E8.3E1
    which gives only one digit for the exponent.
    That works, until the values get too big or too small.

    C test fortran i/o
    READ(*,*) X
    PRINT 1,X
    1 FORMAT(E8.3E1)
    END

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eberhard Franz@21:1/5 to All on Sat Oct 15 02:46:32 2022
    The NX Nastran User's Guide states that both 0.7E1 and 70.-1 are allowed.
    So the problem was easily solved by an 4G8.4E1 format. It is therefore not necessary to generate the output without the "E".

    Again thank you very much!

    muppets

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to muppe...@googlemail.com on Sat Oct 15 10:37:35 2022
    On Saturday, October 15, 2022 at 2:46:34 AM UTC-7, muppe...@googlemail.com wrote:
    The NX Nastran User's Guide states that both 0.7E1 and 70.-1 are allowed.
    So the problem was easily solved by an 4G8.4E1 format. It is therefore not necessary to generate the output without the "E".

    I forgot in the last one, the 1P.

    You want 1P to get one digit before the decimal point.

    Yes it is not necessary to generate without the E, but you get one more digit if you do.

    Well, it seems that Fortran likes to generate both E and sign.

    With 1PG8.4E1 you can get 7.000E+1

    But also, standard Fortran accepts 70.-1 as input, I believe since
    Fortran I.

    That is, Fortran as of October 15th, 1956

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)