News: has a Community Board and Customer Support System. Submit a ticket at

Recent Posts

Pages: [1] 2 3 ... 10
FEM Coupling (HyperFEA) / Results from Buckling Run Deck
« Last post by JanPio on Today at 08:31:42 AM »
I haven't found information on this in the help files: what is actually used from secondary run decks (ANSYS buckling solution) that I add for global buckling constraints? Certainly: Load Factor (for the constraint), displacements (for the mode shape), but any other loads (which I wrote to the results file)?
I assume that a run deck having ANTYPE,BUCKLE is not used to determine margins against strength failure, local buckling, cripling etc.
What would be the process (or workaround) when you have frames discretely modeled with bar elements but the stringers are to be accounted for in smeared panels (spacing to be determined)?

It seems to me that the "segments" approach is intended to be used on a model that has both the stringers and frames discretely modeled using techniques 2 or 3, and not a mixture of smeared stiffeners in one direction and discrete stiffeners in the other. So far, the best alternative I could come up with is doing a conventional smeared panel sizing for the stringers and treating the frames as independent beam assemblies.

Thanks for any idea or clarification.
Miscellaneous Software Topics / Re: Compact Database - Assembly Project Manager
« Last post by James on September 11, 2018, 03:05:42 PM »
Compacting the assembly databases after creation is a good idea. Currently, this is not being done automatically. I've noted this down as a customer request.
In the near-term, you could write a script to compact the databases in the assembly project folder. See:

Compacting a database removes all of the unused tables in the database. We recommend to compact the database if you've deleted or reimported projects. Also, if the database gets close to 2GB (Access database limit) then you should compact.

I hope this is helpful.
Scripting / Re: Parallel Computing with HyperSizer
« Last post by James on September 04, 2018, 12:55:05 PM »
This has been included as a standard feature.
Material Database / Re: Linking to FEM Materials - necessary?
« Last post by JanPio on August 31, 2018, 12:43:51 AM »
I see the advantage, just wanted to check previous sizings.
Material Database / Re: Linking to FEM Materials - necessary?
« Last post by Stephen on August 30, 2018, 07:35:04 AM »
Hi Jan,

HyperSizer will always output the material properties stored in the HyperSizer database for components that are assigned those materials. If you are analyzing / sizing a component in HyperSizer, there is no risk of the iterating FEM not getting those properties. The "old" properties will only be used on components that you did not set up in HyperSizer (we just copy them as-is to the iterating FEM).

We recommend syncing material IDs between HyperSizer and FEA primarily to simplify the import and setup process. If your material IDs match, HyperSizer can automatically assign materials and thicknesses, etc. to your components on FEM import. Additionally, keeping the IDs in sync helps ensure standardization of material properties especially when multiple engineers may be working on a project.

Material Database / Linking to FEM Materials - necessary?
« Last post by JanPio on August 30, 2018, 03:41:24 AM »
I read the manual page for linking FEA and HyperSizer (HS) material IDs and wondered if it has any other aim than enabling automatic import of the Ansys material properties?

Our IDs are not matching, e.g. 1500 in Ansys and 1501 in HS (manually edited in Excel, manually imported from Excel, manually selected for the components in the Sizing Form). As I saw in the iterated "..._i.cdb", HS exports the materials using the IDs of HS (i.e. 1501), and also assigns Mat 1501 to the elements which had 1500 in the initial Ansys run.
Are there any errors in the HyperSizer-Ansys-iterations? (Apart from the advantage that linking would be less prone to non-matching material properties in the initial ANSYS run and HyperSizer)

In particular for the smeared stiffness properties of stiffened panels, where the material properties (=matrices) also contain the updated geometry data, I want to be sure that the iterated ANSYS run uses the updated and not the old properties.
By HyperSizer convention, the x-axis runs in the "a" direction, and the y-axis runs in the "b" direction. The zero stiffeners therefore run in the "a" direction as well.

So an orthogrid pocket that has S0 = 10 inches and S90 = 2 inches is long in the y-axis (b) direction because the space between 0 stiffeners is larger than S90.

I've attached the HyperSizer image of an orthogrid panel, and I've added a quick note showing where "a" and "b" are defined. Hopefully this clears things up! I think what you described is indeed the reverse of this.
I developed a non-fea project trying to optimize an orthogrid panel design for pressure loading only. I assumed from all the images I see in hypersizer that define free body and orthogrid varibles that the "a" dimension is width of panel, the x axis left to right that I match up to the S0 deg web spacing direction, while the "b" dimension of panel is height, the y axis top to bottom that I matched to S90 deg web spacing direction. I run my load case this way and get optimized orthogrid design, that looks OK in viewer. Everything is ok at this point. Then I create an equivalent ANSYS FEA model for verification and to proceed with detailed design, and it shows large negative margins in S90 web.  I  go back to hypersizser, flip my a and b dimensions only freeze all orthogrid dimensions to the optimized solution, and then rerun hypersizer, now I get negative margins in S90 web similar to ANSYS FEM.
So my question is, did I get my a and b panel dimensions mixed up with respect to S0 and S90 web dimensions? where did I go wrong?
Pages: [1] 2 3 ... 10