News: HyperSizer.com has a Community Board and Customer Support System. Submit a ticket at http://hypersizer.com/ticket

Recent Posts

Pages: [1] 2 3 ... 10
1
FEM Coupling (HyperFEA) / Re: Results from Buckling Run Deck
« Last post by Stephen on October 03, 2018, 12:30:24 PM »
Hi Jan,

For buckling cases, you are correct that we use load factors and displacements / rotations to size (using HyperFEA). If you have requested element forces for a buckling solution and the corresponding HyperSizer loadcase is active, then the forces may be used to size components.

Of course this is not desirable, so it is recommended that you deactivate (uncheck) the load case on the "Load Cases" tab of the Project Setup Form to make sure these forces do not artificially drive sizing results. This will not prevent that case from being used for HyperFEA buckling sizing.

-Stephen
2
I believe what you are suggesting is the best workaround we can currently offer for this unique scenario.

Splitting the components along the frames ensures that the buckling spans are computed correctly, and then the frames can be sized independently of the stiffeners and skins. Of course in this paradigm, you do not get the benefit of the segment analysis, but iterating with FEA (especially using HyperFEA) should still result in good designs.
3
Miscellaneous Analysis & Methods / Stiffness not changed for Buckling Constraint
« Last post by JanPio on October 01, 2018, 07:51:06 AM »
Hi,
I try to implement buckling constraint of 1 into my analysis.
My settings:
  • Failure analyses: only stiffness requirements
  • ABD components: all D_ij (also tested with all A_ij and all D_ij, same problem)
  • one buckling load case from ANSYS
  • panels in the region where buckling occurs first are "one stack unstiffened" starting at 2mm thickness, Max bound is sufficiently high
  • all elements are in a common display set that is selected for the constraint
  • FEA loads extraction: peak element filtered (if this makes a difference for FEA constraints)
Working:
  • Mode shape displayed in FEM Viewer
  • correct Eigenvalue displayed in FEM Viewer
  • max translation of 1 displayed in FEM Viewer
  • iterations run without error
  • buckling contraints, lambda_actual, lambda_req and the factor are shown in the iteration report
  • the thickness is increased once from 2 to 3 mm
However, the factor does not seem to be correctly translated into required stiffnesses of the panel (see table below).
Not working:
  • the thickness is not further increased
  • all component factors for stiffness are =1 (see table below)
  • all margins of safety are (slightly) positive (probably because the required stiffness matches the actual stiffness in the table)
  • there is no Mode Detection Parameter higher than the order of E-31, which seems very low to me
      
lambda limitlambda actualFactor
10.002128684469.7737189

D11D11,req CurrentD11,req NextFactor
181121.4823181121.4823181121.48231

Do you know why the obviously high "Factor" does not lead to further panel thickening?
Thanks,
Jan
4
FEM Coupling (HyperFEA) / Results from Buckling Run Deck
« Last post by JanPio on September 25, 2018, 08:31:42 AM »
Hi,
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.
Thanks,
Jan
5
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.
6
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: http://hypersizer.com/help_7.3/#COM/Object/Application-CompactDatabase.php

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.
-James
7
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.
See: http://hypersizer.com/help_7.3/#Projects/Run%20in%20Parallel.php
8
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.
Thanks!
9
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.

Thanks,
Stephen
10
Material Database / Linking to FEM Materials - necessary?
« Last post by JanPio on August 30, 2018, 03:41:24 AM »
Hi,
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.
Thanks,
Jan
Pages: [1] 2 3 ... 10