Community Tip - Learn all about the Community Ranking System, a fun gamification element of the PTC Community. X
I'm trying to run an optimisation study on a gear with a thin web and holes drilled through the web.
I've set up some relations to keep the web in the middle of the gear facewidth, and I've used the web thickness and the hole diameter as design variables in the study.
The .rpt file keeps giving the error:
** Warning: Changing the parameters has produced invalid
model or geometry for the following parameter
values:
Parameters:
d18 10.14 (this is the web thickness, which started at 10)
d28 20 (hole diameter, unchanged in this iteration)
Recovering from invalid parameter values by cutting
step size.
but if I go back to the model and enter the values it shows (which are only a small change from the start point) it regenerates fine.
What gives?
(Initially I used the number of holes as a variable, leaving the diameter fixed, but it recognised the unit as "mm" and then started trying to use non-integer values!)
Edit: I've tried it with both "Repeat P-Loop Convergence" and "Remesh after each shape update" selected, and now with neither selected. Same result either way.
Edit 2: It seems to be running, but for every iteration it has to go through about four 'invalid geometry' cycles, which is making it really slow...
Solved! Go to Solution.
Hi Jonathan,
This issue is fixed in the currently shipping build of Creo 2.0. I would encourage you to upgrade if you can - aside from this problem, optimization and sensitivity studies run somewhat faster than they do in WF 4.0. PTC is no longer shipping regular maintenance builds of WF 4.0.
In Creo 2.0, your study from case C11549838 converges at the following dimension values, without reaching any invalid intermediate states:
d73 | 7.99501 |
d72 | 8.18416 |
d74 | 14.1397 |
d68 | 10.908 |
Regards,
Steve.
Same problem here – more than once.
Sometime there is a true regenerating problem. For example changing the geometry makes the part to lose a reference – even for a small feature like a datum point. It can be tricky to spot it until the right combination of geometries that causes the problem is found and the problem isolated.
On the other hand there are cases where there is no explanation for such “invalid model or geometry”. A manual change does not produce any geometry or meshing problem at all.
And this can be a real problem. The optimization goes ahead but this problem slows really a lot the optimization speed. Especially if it cannot test long steps to get close to a solution. In this case to move the initial variables closer to a solution region may help a little as well as to combine it with “remesh after each update”.
Another side effect is that it forces ProMechanica to test only small changes. And if the changes results are keeping below a given optimization convergence level (ex.10%) it simple stops since “no better solution was found than the initial values”.
I tested the same model in WF4 and WF5 (Creo) and I got the same problem. What is common between my model and your description is that I also use relations, although they are very simple. “Remesh after each update” also does not work.
The optimization option in ProMechanica is far from be “clever” but yet very useful. I wish to use it more but sometimes – and especially when this “warning” message appears it is quicker to find a better solution “by hand”.
If someone can provide any other clue, welcome to share. Until now I had no feedback from PTC and by the lack of similar topics it may not be a common problem (or almost no one uses ProMechanica optimization).
Well, thanks for the solidarity at least!
To be honest, I've given up running Optimisation studies. I use Sensitivity a lot, then use those results to guide my design - they're quicker and ultimately more useful, at the moment.
It's more difficult when you have several variables that interact, though. I still wish PTC could get Optimisation to work properly - until they do, I think almost no-one will use Optimisation.
Hi Jonathan:
Would you please contact PTC technical support and file an issue so that we can take a look at this problem? It's hard to determine what the issue is until we can take a look at the model.
Thanks
Eduardo
Hi Eduardo,
It's not necessarily a particular model; it's more that every 'real' part I try to optimise seems to give problems.
I'll see if I can find the part I was working on in Feb 2011 - if it's what I think it was, it would probably be a good example.
... no, sorry, can't find it. I'll try to submit a call next time I do something similar.
Hi Eduardo
Thanks for your assistance.
If helps I can send you right away one model that has the problem. It converges to a solution but runs very slowly. But PTC should have it since I asked the CAD support to contact them and send the part for evaluation.
Jonatahn is right when he wrote about being nearly straightforward to have this problem as soon as you start to try optimization in some real designs. And indeed, with several variables became dificult to do a manual optimization. Thus would be wonderful to have "optimization" available in ProMechanica...
If I have several variables should be nice to let the optimization working a while to get a result. But this is just impossible with this error. Twenty interactions takes an eternity and at the end comes nothing useful - when does not stop earlier after "not finding best solution then the original one".
My feeling in that optimization plays a 2nd or even a 3rd role in ProMechanica. It works more like as an advertisement than a useful tool.
Optimization in Creo 5 may be a bit quicker now for not keeping calling ProE in background at each interaction (Independent Mechanica does this since ever, I heard!) but uses the same algorithms and suffer the same "invalid model" problem. So, no improvements at all.
Yes, this may explain why there are almost no posts regarding this function.
Hi Rodolfo:
It will be very helpful if you can provide me with one of your models that reproduce this problem. Can you either send me a private message or let me know the case call # or SPR # when you last contact PTC technical support? This invalid model error doesn't come up in different situations (usually complex geometries etc) and we've always tried to resolve/fix them whenever they are reported to our technical support
Thanks
Eduardo
Well, I thought it was worth marking this occasion: I've finally run a successful optimisation study!
After 7 iterations it started giving the usual "Recovering from invalid parameter values by cutting
step size" and, as usual, when I plugged the offending values into the model it regenerated with no problem; but after a few cycles of "cutting step size" it actually came to a conclusion!
Only two parameters on a relatively simple part, but hey, it's a start...
Oh, and I did have "remesh after update" selected - the difference in run time is usually trivial so I generally do.
I've got another one: over 3.5 hours to reach iteration 5, on an assembly that runs a static analysis in two minutes.
Call C11549838 opened and model uploaded.
Hi Jonathan,
This issue is fixed in the currently shipping build of Creo 2.0. I would encourage you to upgrade if you can - aside from this problem, optimization and sensitivity studies run somewhat faster than they do in WF 4.0. PTC is no longer shipping regular maintenance builds of WF 4.0.
In Creo 2.0, your study from case C11549838 converges at the following dimension values, without reaching any invalid intermediate states:
d73 | 7.99501 |
d72 | 8.18416 |
d74 | 14.1397 |
d68 | 10.908 |
Regards,
Steve.
Thanks Steve.
In fact, I did eventually make a scratch copy of the model and try it in Creo 2 (being careful not to overwrite my original!), and indeed it did converge, and rather more quickly.
It's good to see this issue being fixed at last (along with not re-loading Pro/E from disk for every shape update, which will be another significant advantage of Creo 2 when we eventually take the plunge), if a bit frustrating that the only previous response from PTC was "there is no problem - it works for us".
Hello Jonathan and Steve
For all that have or had the "Recovering from invalid parameter values by cutting step size" problem, this does not necessarily stops the optimization but makes it sooooooo slowly that is a lot quicker do to some optimization "by hand" - meaning changing the values and do a own optimization based on what was obtained after each run.
This annoying problem was never fully solved by PTC in any WF Promechanica version.
I agree with Steve that Simulate (Creo) has improved (considerably) optimization speed.
It is quicker but not yet free of the "old problems". Sometimes it stuck in some parameters values (this means that iteration after iteration there is no change) but does not stop with “best value found”. Instead out of the blue it decides to run the simulation all again using the other algorithms - that like magic converges in a lot less iterations!!!
I also saw our old friend "Recovering from invalid parameter values" but in this case it was most likely a real construction geometry problem but it did not slowed down the optimization as before. And this is good!
In general I would agree that the easier solution would be to use optimization with Creo - what may be a bit unfair for those users that have to work with a previously Mechanica version that so far do not have yet a solution for this problem.
Best regards
Rodolfo