FeResPost 4.4.4 is available

[FeResPost]

Hello everybody,

Version 4.4.4 of FeResPost is available.

Several bugs have been fixed:

• In the reading of XDB files with option DBCFACT=4,
• In the reading of inter-lmainr shear stresses from Nastran OP2 and XDB results,
• In the writing of GMSH outputs,
• In several methods of the ``Result'' class,
• ...
  

(See details in the PDF manual.)

Several methods have been added to the ``Result'' class.

Renaud.

Note: I have some problems with my computer at the moment, and some of the binaries are missing. In particular the 32 bits LINUX binaries (Python and ruby). I am working on the problems now...

[Alfred Aoude]

Hi Renaud,

I am having some issues with reading results from an xdb that contains superelements. 

I guess my first question should be if FeResPost supports superelements?

Thanks

Alfred

[Renaud Sizaire]

Hi Alfred,

I think FeResPost does not really support super-elements.

However I have used FeResPost with finite element results obtained with models containing super-elements. In the models I used, the super-elements were connected to the structure I had to size. What I mean is that I did not have to extract results on the super-elements. I imported results only on the structure modeled in details (ie no super-elements).


Mayebe, you should tell a little more about the issues you have with super-elements, and we can see whether a solution exists.

Regards,

Renaud

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

[Renaud Sizaire]

By the way, Now I think to it: when I read results from an XDB obtained from a FEM containing super-elements, the load case names (specified by Nastran SUBTITLE entry) are "decorated" by Nastran with additional stuff. The results on the detailed FEM then are associated to a load case the name of which contains "SUPERELEMENT 0". For example:
    "SINE Y"
may become
    "SINE_Y                                                                                            SUPERELEMENT 0"
Maybe this is the issue you have with super-elements?

Renaud

[Steven Doyle]

Renaud,

In my experience parsing the OP2, I use the following key to store access superelements (and the general result):

    (subcase_id, analysis_code, sort_method(), optimization_count, ogs_id, superelement_adaptivity_index, pval_step) 

 

The flags I use and why are:

 - analysis_code: a static result/preload with the same subcase id as a transient/frequency case (integer 1-10)

 - sort_method: SORT1 and SORT2 flag (this happens when you  have OUTPUT plots; integer 1/2)

 - optimization_count: a counter for SOL200 optimization that's necessary as you may be optimizing on a curve fitted model (a subset of elements) to speed up optimization.(incremented when you find R1TABRG; integer)

 - ogs_id : The OGS surface/volume flag, which is required if you have 2+ OGS results (from the OGS info table; integer)

 - superelement_adaptivity_index: the name of the superelement or mesh adaptation step (comes from the subtitle; string)

 -  pval_step  : the name of the PVAL or STEP (comes from the subtitle; string)

There is an additional reduction step to compress the following key down into the subcase id if all the other flags are the same.  It's not the ideal interface, but at least you can access it.

Do you by chance have a capabilities list for FeResPost?  I probably need to make a complete list of capability for pyNastran.  Maybe we can iterate on that so we both have one?

Steve

[Renaud Sizaire]

Hi Steven,

Thank you for the information about pyNastran and OP2 files reading. I have to confess that I never tried to read results from OP2 files involving also superelements. So I am not sure we wouldn't have the same kind of issues with OP2 files.

But the difficulty of reading WDB files wrt OP2, is that the documentation is poor. You find some information in the DB.access manual, but this manual does not explain much about the XDB file internal structure. What I mean is that the programming of XDB files reading is essentially empirical: each time a new problem occurs, I try to understand the problem when I discover it and improve step by step the programming. (By the way, yesterday, I discovered another issue for the reading of SOL106 results when the option DBCFACT=4 is used.)

So, in my opinion, the best way to fix the problem is to investigate the difficulty working on an example that reproduces the bug discovered by Alfred.

About you last question: I think indeed that I should include in the manuals a list of FeResPost's capabilities for the reading of XDB and OP2, or a list of what has been tested successfully. Actually, I am not even sure I ever trie to read OP2 files with superelements.

Regards,

Renaud

[FeResPost]

Hello Alfred,

Latest version of FeResPost has some support for the superelements. If you are still interested in that feature, you should have a look.

Regards,

Renaud