cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can subscribe to a forum, label or individual post and receive email notifications when someone posts a new topic or reply. Learn more! X

Non-symmetric results for symmetric model and load?

ehaenen
4-Participant

Non-symmetric results for symmetric model and load?

Why is it that displacement for a cone is not rotational symmetric for an internal pressure?

A sample model is attached (Creo 3.0) I've brought it back to the bare minimum. 1/4 cone, symmetry, default mesh etc.

It doesn't help if you refine to enormous amounts of elements, Large deformationm analysis makes it slightly better, but it is never right?

 

Why is that? it should not happen.

How do we solve this?

 

Extra: I've added a full 360 degree version in Creo2.0 format

resudisp.PNG

 

 

creo2version.PNGsimplecone.PNG

65 REPLIES 65
ehaenen
4-Participant
(To:auijttewaal)

Agnes: The problem is not in cylinders, but in cones.

my mistake indeed,

Well, the SPR is still open and with no news on datecodes for a fix. 'Creo 2  fix planned in mxxx' and 'Creo 3 -' (unknown)

jguelcher
4-Participant
(To:auijttewaal)

I just downloaded and installed Creo3.0 M080 and the problem still exists.

ehaenen
4-Participant
(To:jguelcher)

John:

Is it possible that you post a picture of your problem. Is it something conical as well?

I am very interested to get a clearer view of where this limitation is. Maybe that can teach us when to be extra suspicious of possible errors.

I've got the feeling that PTC recognize that there's something wrong but are seriously struggling to solve it.

Thanks beforehand

Erik

It is a conical shape with an internal uniform pressure load.  Fixed at the flange end.

creo.jpg

Here is the exact same model with the exact same loads run in SolidWorks Simulation.

SolidWorks.JPG

Forgot to add that default meshing was used in both simulations.

ehaenen
4-Participant
(To:jguelcher-2)

Thanks John!

It's conical again, thank you for a very clear example with a clearly visible  error, hope Mark is watching.

Erik

I genuinely wonder if the R&D team has a QA process in place, because this is something that a suite of benchmark problems should have caught. Honestly, this is unacceptable for a solver; this is basic linear-elastic mechanics here.

Making a mistake is not so bad, we are all human and we all make mistakes.

How I always judge people and companies is how they deal with the mistakes they make.

In the case of PTC, they are not doing very well so far. It's been almost a year and still no news on a fix... that is very bad for a serious issue such as this.

Hi,

geometry transfer from parametric to simulate is inaccurate:

kegel.jpg

30°, 60°, 90°, 120° etc.error expand

As assembly 180x2°:

Paulkegel_korrekt.jpg

ehaenen
4-Participant
(To:ehaenen)

Most impressive about this is that PTC has not yet been able to offer a solution to what must be classified as a serious bug.

It's been 476 days since the SPR has been submitted by Agnes Uijttewaal.

I've been infortmed by a colleague out there that the bug is still present in the 4.0 sneak preview.

Bravo PTC, well done!

Trying not to sound disappointed after using the Simulate software and paying maintenance through various employers  for 24 years.

I don't consider it worth my time to help others solve problems through this forum if PTC does not show an effort to help (whilst being paid for it)

Thanks for people who helped me so far,

Regards

Erik

Hi all,

Let me provide an update to the issue.

In Creo Simulate, based on the component (solid or surface geometry) AutoGEM tries to create tetrahedral elements where applicable.  This is the default behavior.  Here is an image of the default mesh created in Simulate for the cone model provided.  There are 234 tetra elements created.

7-15-2016 3-36-33 PM.jpg

Now running the analysis, you will find the results do not match the expected max displacement of 2.367 mm as in the thread above (Abacus results).  Obviously, there is a discrepancy in the analysis.

An area we have been investigating was the defined size of the elements shown in the image above for this model.  Now Simulate does process the size of the elements based on a number of factors during AutoGEM - model size, size of thin walls, etc. The element size optimization helps provide accuracy in the results versus compute time needed to run the analysis.  In most cases, the element size optimization output is appropriate and helps provide accurate results.  However, in this example, due to the thin wall, we feel the size of the elements might need to be reduced beyond the optimized size produced from AutoGEM.  Development is investigating the algorithm and seeing if it can be tweaked to see how this will improve the results.....at the same time, not causing ill effects elsewhere.  By ill effects, I mean lengthening the process time for all analyses as a result of increased number of elements created by AutoGEM.  Note: this tweak would be a global setting, so we need to be cautious not to negatively impact Simulate. We will have more news on this upon completing our investigation.

Now for this model, we can show that reducing the element size can provide results closer to the expected max displacement.  To try this, you can add a Mesh Control Option - Max Element Size.  In my image below, I changed the max to 12 mm.  This will obviously increase the number of elements created.

  7-15-2016 4-02-40 PM.jpg

Running the analysis, the results are very closer to the expected max displacement.....off by ~1%.  This assumes the results shown above from Abacus were correct.

Another approach would be to add other mesh control options, such as Thin Solids.  This will create both brick and wedge elements.

7-15-2016 4-13-38 PM.jpg

Again the results are very close within 1% of the Abacus results.

In both these cases, the user would need to add the control options - thin solid or max element size.  To help influence the analysis without the need to add the options is the reason why we are investigating a tweak to the optimization algorithm for element size.

In Creo 4.0, we have added a new option which will help automate the process of creating Thin Solids.  This option is available under the AutoGEM Settings dialog and is called 'Create automatic thin solids'.

7-15-2016 3-21-32 PM.jpg

This can also be controlled by the config option - 'sim_auto_create_thinsolids'.  Either checking the box in settings (session only) or adding the config option (all session), during AutoGEM, where applicable, brick and wedge elements will automatically be created.  Note: this will not create a thin solid node in the model tree under AutoGEM Controls.  This can be tested in the Creo 4.0 Sneak Peek. Running the analysis with the checkbox selected will provide the following results.....which is less than 1% off the expected max displacement.

7-15-2016 3-22-21 PM.jpg

I hope this helps explain the situation and the steps you can use to obtain the desired results.  In the meantime, PTC is also looking to improve Simulate to obtain these results out of the box.

Regards,

Mark

ehaenen
4-Participant
(To:mfischer)

Dear Mark

Thank you very much for your detailed answer, but I'm afraid it is a typical case of: too little too late.

It's taken your company 17 months to provide me with the answer that I need a finer mesh. With your product placement (every good designer should be able to use this simulation tool) it is hard to convince your typical user that something easily recognizable (a round-ish thing that becomes un-round-ish with a uniform load) needs extra attention, and still trust results obtained for more realistic products like the one shown below, which is, by the way, not likely to mesh very well in thin solids.

thinsolid.jpg

  • If this is support, I consider it not present.
  • I've seen Jose Coronado's "PTC Creo Simulate Roadmap" of March 2016, containing not much more than cosmetic changes for Creo Simulate 4.0.

As far as I can tell PTC continues to be commercially interested in this product, but seems to have lost the will to back this with technical effort.

--> So why am I paying maintenance for a product that is not supported and not developed?

I regret to have to say that after being a very loyal customer for more than 20 years through various employers, I've informed my reseller two months ago that I will discontinue PTC maintenance as of September 6.

It's a shame.

Kind regards

Erik Haenen

Hi Erik,

excuse my English, the baby is not dead, stopped it aht to grow:


Creo Parametric 2.0 M080 is stopped


17 years work (very) intensive

Paul

Hi,

the cause of the problem is the wrong transfer of the geometry description to Simulate (before AutoGEM).


Paul

Can you tell us how you came to this conclusion?

Hi,

cone 49500 bricks as part: non-symmetric result

con_part.jpg

cone 100 bricks as assembly: better

con_asm.jpg

Paul

Ok, I have to admit I don't know what I'm seeing at when I look at your graphs.  If you could explain it a bit - what analysis are you running?  What is the curve arc length graph showing?

It seems you have uncovered a big clue as to why Creo Simulate gives wrong benchmark results, but I'm afraid it's not apparent from your evidence presented.

con_asm_vs_part.JPG

geometry description is wrong, not AutoGEM

It's not clear to me how this shows that the geometric definition given to Simulate is incorrect; can you flesh this out for me?

It's also very alarming that the solver shows a solution quantity such as displacement could have more error with an increase in mesh density...

Shaun, what Paul is showing is correlation between number of parts used to build the cone and number of arcs shown in the displacement graphs.

This supports what I mentioned in my post on the 4th of March.

More elaborate;

The displacement graphs show a 1 arc for half a cylinder when using 1 part and 1 for every part when using multiple parts to build up the same cone in simulate.

Less displacement where...

1. one part touches another

2. one half cone touches the other half of the cone (since creo devides cones and cylinders up into 2 surfaces there is some kind of geometry boundary there)
3. symmetry is defined..

...and more displacement in between, where there is no 'interface/constraint/geometry'.

I still don't get how you can say the root problem is that the geometry sent to Simulate (before analysis) is wrong.

But all figures shown in this discussion showcase an uneven displacement of a stressed component (after analysis).

Also, although there is something to this "feeling" about this being related to how Creo splits circles into 2 semi-circular arcs, it still doesn't explain why regular cylinders do not show the anomaly...

Anyway, what's troubling is that PTC hasn't really found what the problem is.  Makes you wonder if there is some fundamental problem with the math of the modeling engine...

Test in stand-alone Pro/MECHANICA STRUCTURE without creo parametric , revolve 1 brick:

revolve_1_brick.jpg

revolve feature in structure ist wrong

cylinder is OK:

Paultransfer_of_geometry.JPG

Hi Paul,

You are right, geometry description is wrong, not AutoGEM.

Other comparison that show the issue.

Model with mesh.

JM1.bmp

Model Version1: Feature Revolve

JM2.bmp

Model Version2: Boundary Blend with option developable (surface from boundary curve)


JM3.bmp

Regards,

Jerzy

Jerzy,

great work,

geometry description is wrong, all revolve simulate-features, torus too.

torus.jpg

Regards,

Paul

Erik,

revolve feature in STRUCTURE is inaccurate:

cylinder-torus.jpg

this "ERROR" is 30 years old.

Paul

workaround:

fake of geometry to bezier.

example attached

Regards

Paul

comparison bezier vs. revolve

(Creo Simulate 2.0 M080)

cone_spline.JPG

Prefer Swept type mesh for rotational and cylindrical objects. Formation of element and nodes plays crucial role in analysis.

"Formation of element and nodes plays crucial role in analysis"

yes, exactly

"Prefer Swept type mesh for rotational and cylindrical objects"

well, that is the problem

revolve of spline geometry only is correct: as bezier surface

Top Tags