Problem with continuation, CBEAM, PBEAM

[dezsit28]

Dear Devlopers,

we have a problem with the bdf file, written out by pyNastran.
In this case the contionuation lines are wrong, in case of the CBEAM and PBEAM cards

The attached test.nas (in the zip) is read by the small script PyNastran.py
and imediately is written out to the file out.nas (also in the zip) and the conversion is wrong.
Actually our pre-processore can read and handle this wrong(?) output, but the solver isn't, so currently we convert the pyNastran output
by the preprocessor manually, but we need to skip this step in the future.

Is there any option to handle this problem, or is this a bug, or we do some mistake somewhere?

Thank you,
dezsit

[Steven Doyle]

What is the correct answer?

--
You received this message because you are subscribed to the Google Groups "pyNastran Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pynastran-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steven Doyle]

Also, what version are you using?

On Wed, Oct 28, 2015 at 8:35 AM, dezsit28 <dezs...@gmail.com> wrote:

--

[Fabio Cunha]

Hi,

I read in the model called "PP.nas" that the continuation marks are missing. I could be the reason why the solver can not handle it.
For instance, it is written:
CBEAM        221       1       8     492      0.      0.     -1.     GGG
                                           -37.5                   -37.5

Notice that the last field in the first line you use GGG. As far as I know, it should have a plus sign, such as  +GGG, and the first field in the second line should have the same mark +GGG. Alternatively, you can use just a plus sign "+" instead of "+GGG". I believe that if do not use any continuation mark, it should also work. However, the second line shall be immediately after the first line (the same applies when you use only plus signs.

In your PBEAM cards in the same file, you use a continuation mark in the second line, but no continuation mark in the others, so it could be also the reason.  For instance:
PBEAM          1       1  601.82 735915. 483382.        1219300.
+
            YESA      1.      0.
              1.      1.
              1.      1.

You shall be consistent when you use continuation marks. This is what I notice in these model as possible reasons for the errors.

Bw,

Fabio.

[Steven Doyle]

Fabio,

The + in the PBEAM example is there because there is a missing line that is meaningful.  There are defaults for all the fields, so it wants to be blank, but there is more data after that line, so you need something there.

Continuation flags are not supported per https://github.com/SteveDoyle2/pyNastran/issues/92, nor do I plan to add support for them.  They unnecessary unless you're doing something like:

CONM2,1,,,,,,,+NEW1

CONM2,2,,,,,,,+NEW2

CONM2,3,,,,,,,+NEW3

+NEW1,1.

+NEW2,2.

+NEW3,3.

There is no requirement to be consistent among cards in regards to formatting.  The requirements are that a card can run through Nastran and that no information is lost/mangled.

Steve

[dezsit28]

Dear Steve,Fabio,

thank you for your answers
The correct answer can be the test.nas. This is the output our base FEA model, from our preprocessor.
We want to modify this base file, as a part of a large study, by the help of pyNastran.
But the pyNastran writes out those wrong card continuation, which are in the PP.nas file.
So somehow the pyNastran is not able to handle the large, multiline cards correctly(?) (in this case the PBEAM and CBEAM cards)

As I wrote before, our preprocessor can read this wrong(?) bdf (I mean the pyNastran output PP.nas) correctly, and transform it to a correct bdf (finaly we get back the test.nas after this re-read),
but the solver itself throws errors directly on the PP.nas

As I mentioned it would be a really large study (around solver 1000 runs), so we cannot correct the bdfs by hand, or by the re-read with preprocessor,
we need a syntacticaly good output from pyNastran, what we can solve directly, without any additional manipulation.

we tested the 0.7.1 and 0.7.2 versions
maybe we will test something from the 0.6.x line, but our code base is currently on the syntax of the 0.7.x line

BR,
dezsit

[Steven Doyle]

Dezit,

If there is a bug in the PBEAM, I'll fix it, but not working in your parser doesn't mean it's a bug.

I guess I'm still confused.  What is the problem with the deck that is written out?  The continuation card isn't necessary for Nastran.  It's entirely optional.  As such, you should not depend on it.  Unless your solver is a very nonstandard version of Nastran, it should work.  If it's your own solver, it's a bug in your software.  You can also just write the card out based on card.raw_fields().

pyNastran does not maintain the card formats to some clear specification.  It's very dependent on the card and different cards follow different conventions.  They're meant to be clear and short, but those are conflicting goals.  The software will not necessarily produce the exact same BDF between say v0.7 and v0.8 and that's OK.  It you want it be in a specific format, I suggest you make a write method.

Seve

[dezsit28]

So the solver is NX Nastran, so nothing specific
 If we run the PP.nas it thhrows this errors for CBEAM:

 *** USER FATAL MESSAGE 313 (IFPDRV)
     ILLEGAL NUMBER OF WORDS ON BULK DATA ENTRY CBEAM            221      SORTED ENTRY COUNT =          2
     User information:
     See Bulk Data entry description in Section 5 of the NX NASTRAN
     Quick Reference Guide. One cause of this message is using a "D" before
     the exponent for a real number. Only "E" is allowed, unless noted
     otherwise on the Bulk Data entry description in Section 5 of the
     NX NASTRAN Quick Reference Guide. Another cause is placing a BCD
     variable in a real or integer field, such as using the letter O when
     the number 0 is intended.

and for PBEAM:

 *** USER FATAL MESSAGE 316 (IFPDRV)
     ILLEGAL DATA ON BULK DATA ENTRY PBEAM  
     User information:
     See Bulk Data entry description in Section 5 of the NX NASTRAN
     Quick Reference Guide. If you are using the large field format make
     sure the number of entries is even.
 PBEAM  *               1               1          601.82         735915. 0000N1J
 *0000N1K                                                                 0000N1L
 *0000N1L                                                                 0000N1M
 *0000N1M            YESA              1.              0.                 0000N1N
 *0000N1N                                                                 0000N1O
 *0000N1O              1.              1.

our test script is very simple, you can see it in PyNastran.py, so you can try it on
just read the correct nas (test.nas), and imediatelly write it out  to PP.nas, which will be wrong
we did not modify anything just read and write

from pyNastran.bdf.bdf import BDF
nastran_mesh = BDF(debug=True,log=None)
geom_file='test.nas'
nastran_mesh.read_bdf(geom_file)
nastran_mesh.write_bdf(out_filename='PP.nas')

we don't need any specific format, but I think the PP.nas is not a correct deck
we use the pyNastran on windows, in the Anaconda environment, can this e a problem?

thanks,
dezsit

 

[Fabio Cunha]

Dear Steve,

I am sorry for the confusion. I read the bulk data again and I think that you are correct,  there is no continuation marks/flags issue in this bulk data. It should be sth else.

Dear Dezsit,

I don't find any error in the bulk data "PP.nas" in a first glance. Moreover, I was able to import both bulk data in the FEMAP GUI without any error message. I am a MSC.Nastran user, and I am not familiar with the differences between MSC.Nastran and NX.Nastran I suggest you to verify the QRG of NX.Nastran for CBEAM and PBEAM, specially the field 9 of the first line, where there is the string "GGG". In MSC.Nastran, this string means that the offsets/orientation vector are referenced to the Global Coordinate system. Does NX.Nastran also use this string in this field?

I strongly suggest you to verify your PBEAM definition. In the second lines of your PBEAMs. you write that the stress recovery points equals 0. Is it really right? Moreover, in the third line you have the string "YESA", which means that you ask for the stress recover at the same positions of endA (which are 0.).

From the error messages given by the solver, I have no other clue.

Br,

Fábio.

[dezsit28]

Dear Fabio,

yes, as I wrote, our preprocessor can also read this file (PP.nas) and it is the FEMAP :-).
That was the wierd thing after all...
We have been read out the QRG of NX several times, but not really get the solution, so thank you your suggestion
After all, that is enough for me (more or less :) ) that the pyNastran version is correct, at least for MSC.Nastran.
So we need to find out something to solve this NX related problem.

Steve: thank you for the pyNastran, we love it, and use in our analysis workflow.

So thank you again for your answers, if you have any further comment on this topic, please share with me, becasue we need a quick solution on this issue.

BR.
dezsit

[Steven Doyle]

Dezsit & Fabio,

I'm sorry.  I didn't realize it was actually crashing in NX.  I thought it was just a problem with your code that was parsing it.  Can you make a complete NX deck as an example as opposed to just a PBEAM?

Steve

[dezsit28]

Dear Steve,

the complate NX deck, which is working properly is the test.nas in the attachemnt of the first post.
Yestarday we did some trial and error test, in find out that the only problem with the PBEAM card is the zero in the 4th field (marked with red)

if we blank this, the deck is able to run on nx, the empty line does not matter. On the next picture youe can see the PBEAM card written out
by Femap from our base FEA model, and this entry is blank, so the pyNastran insert this zero...

Regarding the CBEAM card, the GGG (field OFFT) is not known by NX Nastran. We found in the MSC.Nastran qrg, that the default value of this field is GGG

or blank(!) which is good for NX Nastran, because this field is always blank in it, so it can be the default behaviour of the pyNastran as well.

Actually we wrote a small script which eliminates this wrong entries after the pyNastran and before the solver running, so currently we have a workaround,

but it would be nice if it works without additional modificaton, only with the usage of pyNastran.

BR.

dezsit

[Steven Doyle]

That helps a lot.  The bug is actually fixed in v0.8-dev.  The PBEAM is one of the weirder cards in Nastran.  Nastran often reads it incorrectly leading to very subtle bugs (e.g. YESA is handled incorrectly).  A lot of work has been done for v0.8 to redo the PBEAM and follow the QRG properly.  If you 're worried about dev versions, v0.8 is generally very stable, so I wouldn't be worried about using it, but you can wait a month or two if that's better for you.

Steve

New

    PBEAM          1       1  601.82 735915. 483382.        1219300.

    +

                YESA      1.  601.82 735915. 483382.        1219300.

                  1.      1.

    PBEAM          2       1   292.5  65615.  69960.         135576.

    +

                YESA      1.   292.5  65615.  69960.         135576.

                  1.      1.

    PBEAM          3       1   273.7  83836.  28093.         111929.

    +

                YESA      1.   273.7  83836.  28093.         111929.

                  1.      1.

Old

    PBEAM          1       1  601.82 735915. 483382.      0.1219300.      0.+       

    +             0.      0.      0.      0.      0.      0.      0.      0.+       

    +           YESA      1.                                                +       

    +             1.      1.                                                        

    PBEAM          2       1   292.5  65615.  69960.      0. 135576.      0.+       

    +             0.      0.      0.      0.      0.      0.      0.      0.+       

    +           YESA      1.                                                +       

    +             1.      1.                                                        

    PBEAM          3       1   273.7  83836.  28093.      0. 111929.      0.+       

    +             0.      0.      0.      0.      0.      0.      0.      0.+       

    +           YESA      1.                                                +       

    +             1.      1.                                                        

[dezsit28]

Thanks a lot!
We will test the new version soon.
There was one more occurence of this type of error, with the YES keyword (instead of YESA), see below.
But maybe this is related to the same problem, and it will be solved in the new version as well.

BR.
dezsit