Support for damping and stress in the CELAS2 command.

[ThomasAbballe]

Hi all !

VEGA does not support damping or stress in the NASTRAN CELAS2 command, and I need it for an example i want to convert to Systus.

Judging by the documentation, the stress coefficient S is only used to post-treat the data, so maybe it can be safely dismissed. Do you know more on this subject ?

The damping, however, directly impact the mechanical matrices, so it's important to translate it. I think I can update our current Systus translation to fit this.
Problem is, for now, CELAS2 are treated as very small Matrix Elements, and translated to Systus as super-Elements (X9XX Type 0 element reading a table). It's waaay too complicated for such a simple element, so maybe I'll rewrite all this part altogether... If I find how.
I'm interested with any thought on the subject.

Cheers,

[ldallolio]

Hi Thomas,

I agree with ignoring the stress coefficient S, for me too it is for the post treatement.

I do not really see a problem with using a Matrix Element for this one (actually you will need two of them if I am not mistaken : one for the stiffness and another for the damping) :-)
The translation will then depend on Systus and can be as you see fit.

Cheers

[ldallolio]

Hi Thomas,

I was thinking about something : if you have doubts about the performance of MatrixElements when there are many of them we could write all of them in a compact way, something similar to what is done for fixed size cells or nodes : we can think of a table having two dofs and a value, then each MatrixElement would have to simply put its data into the table and remember rows... Then again we could put the element ids and the rows ids somewhere else (another table) and only use MatrixElement when we ask for the data in the writer (as we do for Cell objects, that are created on the fly). You can think of this as a Flyweight pattern if you want.

Cheers

[ThomasAbballe]

Hi Luca,

As usual, thanks for your answers.

• As we agree on this, S will be dismissed (in the next push I think.)
• In the Systus Writer, I won't need two X9XX Type 0 elements, as I can specify Damping, Mass and Stiffness (in three different tables) for each element. So a "all-in-one" solution is possible in the Writer. I'll try to figure an elegant solution in the Nastran Reader part too.

The problem with using MatrixElements for CELAS are not with VEGA capacities/resources management, but with the complexity of the Systus output. I, for one, am very satisfied of the current translation. Basically, it does the job, and pass our test case, so I am happy :D
But from our SYSTUS expert point-of-view it's not a correct translation. The elements X9XX Type 0 are quite complex, especially if they are numerous and need to point to extra-files. They were designed for Super-Elements, and not small matrice of 1 dof. So we translate something very simple in Nastran to something very complex in Systus, and it doesn't "feel right".
It seems they are way to improve the translation, so we are still looking to this.

[ldallolio]

Hi Thomas,

Thank you for your clarification, I understand your point of view (and your expert's, of course).
Sorry for repeating myself, but I wish to better explain my point of view (I suppose everything is clear for you but I still feel I didn't explain myself properly... :-) )
I still think that this issue should be resolved mostly in the Systus writer : other output codes will have different needs (for example, Code_Aster would have to define explicitely DISCRET matrices for stiffness, mass and damping, I think they should be the equivalent of Systus X9XX elements).
The other requirement, in my point of view, is to always allow the "identity" translation in Vega, that is "Nastran to Nastran", in a natural way (that is : "output should look similar to the input in identity transformations"). While this might sound silly at a first glance, it has some use cases:

• security reasons in the cloud : instead of accepting a user model directly in a cluster, you make it pass inside a translator to avoid code injection attacks
• testing : this allows to test both the parser and the writer to see that the translator does not "lose" anything by running a nastran calculation
• flattening : sometimes the input code contains some programming that you do not want or cannot replicate, Vega might replace it with the computed lines
• if a code develop an higher level, equivalent functionality (for example that was the case for RBE3 in both Code_Aster and Systus) if the abstract model has kept the information "as it was originally in the input" it will be possible to add it in a natural way : let's say that we add an Abaqus writer and let's say that is has CELAS elements, it would be a pity to have them translated with anything else, isn't it ? :-)

In any case, if you find out that Systus has an equivalent (or similar) solution to the CELAS element, a translation from the MatrixElement would be trivial I think, so I do not see any need to change anything neither in the Nastran parser nor in the abstract model, if I understood properly the issue... ;-)

Best,

[ThomasAbballe]

Yes, it's mostly a work on the Systus Writer, which should treat differently MatrixElements wether they have only "2 nodes on one dof" (CELAS) or are much bigger (Super-Elements).

But there is also the matter with the Nastran CELAS2 parser. For now, it creates a StiffnessMatrix. I could create also a Damping Matrix, but that would duplicate the element, with all the problems that follow (numbering, duplication of information, maybe fusion after). I think I'll need an other ElementSet...

[ldallolio]

Now I see your point better :-) No, i wasn't thinking of creating two separate elements either, but having a SpringElement with inside two or three MatrixElements as attributes... ;-)

…

On Jun 5, 2017 15:24, "Abballe Thomas" ***@***.***> wrote: Yes, it's mostly a work on the Systus Writer, which should treat differently MatrixElements wether they have only "2 nodes on one dof" (CELAS) or are much bigger (Super-Elements). But there is also the matter with the Nastran CELAS2 parser. For now, it creates a StiffnessMatrix. I could create also a Damping Matrix, but that would duplicate the element, with all the problems that follow (numbering, duplication of information, maybe fusion after). I think I'll need an other ElementSet... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4KDUiodG2m0R3WTCLwVslVjfAwH65qks5sBAGBgaJpZM4Nub_f> .

[ldallolio]

Hi Thomas,

One question please : now I have access to the code, I do not exactly understand one point. I see that there are already two classes (very similar between each other, as the comment says) : DiscreteSegment and StructuralSegment that can handle the CELAS1 and CELAS2 terms. I think that they should be created when the parser sees PELAS that filled with stiffness, mass and damping data when the parser sees any CELAS1 or CELAS2 with the same PID... Is this the solution you are looking for ? This is how I handled this in the previous python parser.

Hope this helps ;-)

Best,

[ThomasAbballe]

I forgot I added the Structural Segment when I was working on the CBUSH/PBUSH keys. Keys that are not, as of today, correctly translated (my tests on these shows discrepancies on displacement between Nastran and Systus). But that's an other problem ^^

So, to summarize:

• CELAS1* : Creates a CellType::SEG2, with a property linked to the PID
• CELAS2 :
  - Without GE : StiffnessMatrix
  - With GE : SpringElement with inside two MatrixElements
• CELAS3* : Creates a CellType::SEG2, with a property linked to the PID
• CELAS4 : Creates a StiffnessMatrix
• PELAS* : Creates a StructuralSegment with all the needed information

I could treat a CELAS2 as a "CELAS1+PELAS" but it would lost the "specifity" of the CELAS2 command.

*: not currently supported. I don't plan to add it now: I don't have examples with it.

[ldallolio]

Hi Thomas,

This is almost, but not exactly, what I had in mind. Sorry to insist but I think that it could help you and the project:

• let's only talk about CELAS2 (or CELAS4) for the moment, I forgot that it is "without a reference to a property entry" so PELAS is not relevant here. I was thinking more of CELAS1 and CELAS3 in my last comment
• in your place, I would not do special cases like "with GE" or "without GE". I would always use something (like you did with StructuralSegment) in any case and both for CELAS2 and CELAS4. You can create a class containing both a StiffnessMatrix and a DampingMatrix (you could also add a MassMatrix in the future) and only use them if needed. We could call this new class for exemple "StructuralSpring" to indicate that it is an higher abstraction element with respect to StructuralSegment. (In the future you could use the same class to handle PELAS+CELAS1 and PELAS+CELAS3, like I did in the previous version of the translator)
• I believe that you would have to fill in three elements of the matrix for each CELAS2 or CELAS4 : stiffness[G1, C1, G1, C1] = K, stiffness[G2, C2, G2, C2] = K, stiffness[G1, C1, G2, C2] = -K so you could create a method "addStiffness" that takes G1,C1,G2,C2,K as parameters and does the three assigments at once. Same thing for the GE, probably
• if you need (in the writer) to understand what has been really used, you can add helper methods in the class, such as "hasDamping()" or similar.

We can also talk about this if all of this is not what you think should be done, it is indeed quite complicated.

[ThomasAbballe]

Everything is very clear. Yes, it's better to use a "Structural Spring" for all sort of CELAS elements. I'll look into it.

But it seems I made a very embarrassing mistake. In my example the damping coefficient is equal to 0 !!! It's not the default value written in the reference manual (there is none), so VEGA raises a warning.
But, as I skim pages and pages of documentation, it seems to me that GE=0 means 'no damping', just as if 'GE' were not provided. Am i right ? I know some Nastran keys work differently whether the field is equal to "0" or "not provided"

Can you confirm that ? If it's true, all this talk, for interesting that it is, will be moot. I can't spend time coding "not explicitly needed" features :/

[ldallolio]

Yes, I agree with your interpretation : GE=0 is like GE=blank, it is frequent with Nastran when the code is written by some graphical interface.

[ThomasAbballe]

I was almost afraid you'd say that. Basically I filled dev tickets a few months ago, one by problem/warning/error on the translation of our industrial test case. Then I started coding each devs, testing on elementary examples... But I never got back to the industrial example before yesterday.
Bad programmer -_-". Okay. I'm finished venting on the stupidity of my mistake (for now :p)

Well, I suppose there is a good side to it. When we will need a damping CELAS, this thread will still be there!
Thanks for all your answers.

[ldallolio]

If this may help, I did the same thing when I was young... ;-) ;-) I can tell you that it will happen again sometimes, dont't sweat too much about it ;-)
I agree : this discussion is a good thing in any case.