Possible to prevent stress calcs in modal analysis?

For many modal analyses I don't need to know the modal (relative) stresses, only the frequencies and modeshapes. In order to reduce the run time, is there a way to prevent the stresses from being calculated, either with the internal solver or ccx?

Don C.

Comments

  • edited October 2022
    Delete them from any mode in the solution tree, including any derived stress like von Mises and any formulas that refer to any stress variables.
  • For a particular analysis, I'd like the stresses to not be calculated to begin with so that the run time would be reduced. I thought there might be a CCX card that would prevent the stress calcs.
  • edited October 2022
    it sounds like you switched from a stress analysis to a modal analysis. modal analysis doesn't include any stress calcs. those are just left in the solution branch unless you manually delete them. this is annoying and i've asked many times for something to be done about it. it's especially annoying when you have a bunch of custom formulas in the solution tree. having these there won't increase the solution time though. at least it shouldn't. only the displacement solution is needed. so i manually delete everything but that and then solve. for some recent models i was working with for a different forum post. i just left everything in the solution branch and solved. i didn't notice any issue with that. it's just messy.
  • A typical modal analysis CCX solver output (abbreviated for clarity) is below. I'd like to stop the solver after the eigenmodes have been calculated. This would prevent the stress calcs which I often don't need. (For this particular analysis there were 17 modes which resulted in 17 stress calcs.)

    ===================================================
    STEP 1

    Frequency analysis was selected

    Decascading the MPC's

    Determining the structure of the matrix:
    number of equations
    66567
    number of nonzero lower triangular matrix elements

    2473230

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the symmetric stiffness/mass contributions.

    Factoring the system of equations using the symmetric spooles solver
    Calculating the eigenvalues and the eigenmodes

    U^T*M*U=0.000000 for eigenmode 0
    U^T*M*U=0.000000 for eigenmode -20
    U^T*M*U=0.000000 for eigenmode -23
    U^T*M*U=0.000000 for eigenmode -73
    U^T*M*U=0.000000 for eigenmode 22

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.

    Using up to 1 cpu(s) for the stress calculation.


    Job finished

  • hmm, that's really weird. by definition modal analysis doesn't have anything to do with stress calcs. i'm not sure what is going on there.
  • one thought. i wonder if you have loads defined. it might me doing a prestressed modal analysis. if that's the case you can supress the loads.
  • edited October 2022
    i ran a modal analysis without loads and looked at the ccx output. mine says the same thing you showed. i'm guessing this is poorly worded output from ccx. you might have to ask this question on the ccx forum. someone there may know more.

    i solved for 10 modes and i have 10 of those stress calcs listed. i have to believe it has nothing to do with stress calcs. it may have to do with the number of modes requested though.

    https://calculix.discourse.group/

    update; i confirmed it is tied to the number of modes requested. i changed it to 3 and got 3 of those stress calcs. pretty sure it is just lousy wording. i think the author is from germany. the ccx manual is pretty awful too. the output is not nearly as good as ansys. i've always liked mecway's output, because it's simple and meaningful. something between mecway and ansys screen output would probably hit the sweet spot for most people.
  • I agree with prop_design that it's probably not actually calculating stress if you removed all the stresses from the solution tree in Mecway before solving (which tells CCX not to generate them). Those messages don't seem to consume any time so perhaps they're where the stress calculation would be if it was happening.
  • I ran the attached modal model (86k nodes) under two conditions -- 1) with usual stress calcs; 2) without stress calcs (per Victor's suggestion of deleting all stresses from the solution tree before calcs). I alternated between the two conditions, running 4 of each. Averaging these runs for each condition should account for the effect of any background apps that might have affected the runtimes. The results --




    The improved runtime isn't great but also not insignificant. I don't know how these results would translate to different model sizes.

    Mecway v. 16
    Windows 10
  • edited October 2022
    hi jmf,

    if you have stress results in the solution tree and do a modal analysis, they should just come back as red. is that what happens for you?

    one thing i noticed, not related to modal analysis, is just having stress results in the solution tree increases the solve time. victor is aware of this. i'm not sure what the exact problem is. it seems like you are witnessing the same effect. your 12% feels right to me.

    as an example, say you do a linear static analysis. if you just have displacement in the tree, it's much faster than if you also add von mises. if you add a few formulas to the tree it slows down more. i haven't timed it but it's very noticeable.

    to your specific problem. modal analysis should not be doing any stress calcs. however, having stress related items in the tree does slow mecway down. it slows down further with formulas in the tree. hopefully this can be fixed in the future.

    another thing that seems slow with v17 is deleting formulas. especially, if you haven't cleared the results first. so i try to remember to clear the results then start deleting the tree items. oddly, even if the items you want to delete are red, it's still very slow to delete them, unless you clear the results first. so basically v17 has issues with tree items and slowness.

    i just wouldn't go around saying you are computing stress with modal analysis. that will not go over well with people familiar with the topic. there is prestressed modal. however, that doesn't compute stress. it computes a different stiffness matrix, based on a stress analysis that's run before the modal analysis. there is also nonlinear prestress. but again, stress is never computed with modal. they are just referring to the stiffness matrix. it's very unfortunate what you found with the ccx output. that is something i would post to the ccx forum. it's just wrong and misleading.

    edit; i should have also said that this slowdown with stress and formulas happens with the internal solver too. so the problem is not specific to ccx or modal analysis.
  • prop_design --
    i just wouldn't go around saying you are computing stress with modal analysis. that will not go over well with people familiar with the topic.

    You are correct if you are asserting that absolute stresses can't be determined with modal analysis. This requires harmonic (frequency response) analysis with a specified force or displacement. This isn't available in Mecway although I have requested this several times. (Victor?)

    However, relative stresses can be determined with modal analysis by normalizing the stress calcs. For example, consider the longitudinal vibration of a thin rod. The attached model shows a 10mm diameter rod x 125mm long. With a modulus of 69 GPa and a density of 2759 kg/m^3, its fundamental half-wave resonance is 20 kHz.

    Stress from theory

    Stress = E * Strain

    Longitudinal displacement of a resonant half-wave rod --

    u = U*cos[pi*(x/L)] -- (the amplitude is cosinusoidally distributed along the rod)
    where U = peak amplitude at the rod end; x = distance along rod; L = rod length

    Strain = du/dx = U*(pi/L)*sin[pi*(x/L)]
    Strain_max = U*(pi/L) at x=L/2 where sin=1.0 (i.e., at a node)

    Therefore --

    Stress_max = E * U*(pi/L)
    = U * 69e9 Pa * (pi/0.125m)
    = U * 1.734e12 Pa

    Stress_max can be linearly scaled according to U but for convenience choose U = 1 m --

    Stress_max = 1.734e12 Pa at 1 m peak displacement

    Relative stress from FEA

    For the attached model's mode 2 solution at 20 kHz, the displacement Z at the end of the rod is 17.1858 m. The formula von_Mises_per_meter_peak is the von Mises stress that has been normalized to the model's maximum displacement. For this particular model the required von_Mises_per_meter_peak formula is --

    vm/17.1858

    The resulting maximum stress in the rod is 1.734e12 Pa (see the legend).




    Thus, the FEA relative stress is exactly the same as the theoretical stress. Of course both the theoretical and FEA stresses can be scaled to any desired displacement.

    I hope this clarifies my references to stress calcs in modal analyses.

    Note -- my analyses are in v.16 because of the known problem with v.17.
  • In the above example, a 1m peak displacement was chosen for convenience to show the equivalence of the FEA relative stress and the theoretical stress. Of course, such a displacement is unrealistic for an actual material. My interest is displacements in the micron range (typically up to 75 microns peak at 20 kHz but sometimes higher for specialty devices).
  • edited October 2022
    hi dculp,

    i'm not familiar with the type of analysis you are doing. i was just speaking in the general sense of what the solvers do. for your problem, i wonder if you can't use the dynamic analysis type. there is a mode superposition option that is very fast. the mecway internal solver seems to be more robust than the ccx dynamic solver. i'm not sure why that is. however, i would recommend using the internal solver for the dynamic analysis. in your case, since you know the frequency you are looking for, you can set the dynamic forcing function at the resonance frequency. then it should calculate stress. i would imagine the results should be different than what you are calculating, since the dynamic analysis includes mass and damping effects on stress. i'm not really sure that the stress you are calculating would be accurate.

    with v17, if you add stress into the tree for dynamic analysis, it does slow down. so maybe stick with v16.

    update:

    i should add, i have always used modal analysis to place strain gages for vibration testing and to make campbell diagrams. it also lets you know where to expect resonance. for me, that means rpm's to avoid or the blades will break off. in inertial sensors, we did the opposite. we operated at resonance because it provided sensor gain. so it depends on the industry you are in. however, for stress we did other analysis types. another interesting use for modal analysis is musical instruments. i use the stress stiffening option a lot. but like i said earlier, it's not to calculate stress. it's to get accurate resonance frequency calculations when the part is under stress. i have also used ccx cards to do nonlinear stress stiffening and non linear stress stiffening with coriolis effect. victor helped me with defining the cards. it turned out linear stiffening was fine. the more advanced calculations weren't needed for my parts.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!