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

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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

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

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