Vectors in VEGA

[ThomasAbballe]

Hi all,

I recently added the support for the Nastran FORCE2 command. This command defines nodal force, by specifying four nodes N1, N2, N3, N4. The resulting force is parallel to the cross-product of vector(N1N2) with vector(N3N4). It was done by a ugly fix, as I copied/pasted/modified the NodalForceTwoNodes class into a NodalForceFourNodes.

Because Nastran has 3 ways (that I know of) to define a vector (explicitly, implicitly parallel to two points, and implicitly by cross-product), we have now 3 Abstract classes to modelize the same thing: a nodal force on a point. It doesn't seem right.

Maybe we should introduce a Vector object in Abstract Vega, or change the VectorialValues one, to encapsulate implicit vectors. Like many others, the Vector object would be "implicit" until the end of the reading, when he will be computed from the mesh. It would greatly simplify the NodalForce object, as we would have only one class for all. As a consequence though, this Vector object would be linked to the Model class (or at least the Mesh ones), and that could/would mess the current hierarchy. I foresee quite a lot of work to do this...

Any thoughts on the subject ?

[siavelism]

Hi Thomas, NodalForceTwoNode and NodalForceFourNode both inherit from NodalForce, then it can be considered as a uniq class : in the writer you just need to cast it as a NodalForce and call the method getForce(), then the NodalForceTwoNode.getForce() or NodalForceFourNode.getForce() are called implicitly if needed and it should work out of the box without changing anything in the writer. For me what you did is the right way to do it, you can add as many class as you need in the abstract, since these class inherit from a more general class that have a specific enum Type : NODAL_FORCE in your case Bye

[ThomasAbballe]

Hi msiavelis, and thanks for your answer.

I know that the solution I provided works. I didn't think of it then, but, as you point out, this addition is transparent from the writer point of view, so it's a good point in its favour. My concern are more philosophical than practical.

It seems to me that the Abstract classes are here to provide a generic modelization of the various parts of the model. They are the "physic" and "mathematic" objects, and should not depend of the used format (Nastran, Systus, etc) But the current solution duplicates an Abstract class, just to take into account a very NASTRAN specific command. The physic is the same: a force on a single node! If/when* we generalize this approach, I fear we risk to clutter the code with various "only used one" objects, doesn't it ?

As I seem to be the only one working on VEGA at this time, and am only interested on Nastran To Systus translation, it is kind of a moot point, i know. But, he, it's still worth noting here ;)

Cheers

[ldallolio]

Hi Thomas,

I can probably tell you some more about Vega, this could help you choose:

• Abstract subclasses are (as Max is saying) at the "service" of parsers : the idea is to keep the parser as simple as possible. So every time you find a parser keyword you should have a corresponding concrete subclass in Abstract. There is another, very important reason to do this : the nastran-to-nastran conversion, or "identity" (X-to-X) conversion. In this case, if you do not have a corresponding class, you will not be able to have a nice conversion, since you have already "lost" information.
• To avoid duplication you can also do what you suggest, that is to play with the "Value" hierarchy. VectorialValue could be the right place to do this. Otherwise you can use the NodalForce superclass to "pull up" some common code.

Very often I find out that even if the two ways of programmings can get you to the expected result, only one of them can give you the "X-to-X" conversion. So I use the "Value" hierarchy when I really have a different value in a keyword, but I use a different Abstract subclass when I have a different keyword, even if a smarter Value class could handle the case.

There are at least three good reasons to have a "X-to-X" conversion :

• a simple test that everything works as expected in Abstract, validating a parser and a writer at the same time
• you can use this to isolate a solver from user input (important in web context to avoid "code injection")
• sometimes you will find a X-to-Y conversion where you have exactly the same keyword in Y writer, it would be a pity not to use it ;-)

Based on some meetings this week, we could add other output languages next year, so I really appreciate both you work and your way of thinking! :-)

Cheers