turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Navigation
- Simcenter
- Forums
- Blogs
- Knowledge Bases

- Siemens PLM Community
- Simcenter
- CAE Simulation - NX Nastran Forum
- Sol200, optimization

Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

Not applicable

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-23-2011 05:20 AM

I am running an optimization solution with two design variables, but after solution completed, the solution finishes after a number of cycles of 34.

Looking at the punch file, i dont understand why the optimal solution gives a values higher than the upper limit set for each variables. Does that mean that no optimal solution was found?

and iam runing a continuous optimization solution, is it possible to swith to Discrete one by just adding teh DDVAL card?

Thanks,

Engrequest

5 REPLIES

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-24-2011 08:24 AM

I'm no expert on SOL 200, but I work with a couple. Can you send me the F06 file? I work in CAE product development and will ask for help from the NX Nastran development staff.

Regards,

Mark

Mark Lamping

CAE Technical Consultant

Siemens PLM Software

(513) 576-2073

mark.lamping@siemens.com

Not applicable

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-25-2011 05:31 AM

Thanks for your reply.

I have enclosed the .f06 for the solution, but bear in mind that the solve was done with the parameter Print set to 1, so the .f06 file is not too large, and therefore doesn't contain the details of all the cycles.

Please let me know your findings.

Regards,

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-25-2011 08:34 AM

Normally the results should not include design variable values above prescribed limits, though I have identified one loophole in the past. Does this job have DVGRID bulk data in it (i.e. shape optimatization)?

I do have to see the job to understand exactly what is going on, or at least the parts with the design variables input and output. Do you believe that would be possible?

As for the design variables, yes DDVAL would be mostly sufficient for a discretized design, though the discretization we have is not the best possible. There is also DOPTPRM bulk data parameter DISBEG, which tells the program at what cycle to start discretizing.

Regards,

Mark

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

06-01-2011 02:18 PM

Thanks for allowing us to look into the f06 file. I have looked at the file for purposes of answering the questions (1) on design variables possibly violating their bounds and (2) as to whether the resulting design is optimal. I believe the discretization question has already been answered above. Finally, I have some additional comments (3) which may be helpful.

By the way, the f06 file we received shows that the job stopped after 22 cycles, not cycle 34 as it was originally described. Therefore this may be a job different in some respects, which may go towards explaining my reply to item (1).

(1) There are four (4) design variables in this job: two "thicknesses" and two "angles" (quotes since design variables are not directly properties, but they are associated with them). All of the 86000 or so properties that are being designed are associated with these four design variables. Since we do not have the relevant DVPREL1 cards, I cannot be sure, but from the results I assume that there is a one-to-one correspondence between each property and the design variable it is associated with. The lower bounds for the two "thickness" design variables are the same, with the upper bounds being different. The "angle" design variable lower and upper bounds appear to be the same for both, though we do not have the input file and I must confess I did not check all 86000 properties. Looking at the final results, I see that the two "thickness" variables have arrived at their upper bounds at design cycle 22, and have not violated their bounds at any cycle. The "angle" variables also remain well within their bounds during and at the end of the optimization process. Therefore I do not see that any design variable has violated its bounds at any stage (this may happen within the optimizer, but is not of concern to a user), unless it was the constraints that were meant not the design variables (in which case see item (2) below). Perhaps we need the output for the job that actually ends at cycle 34.

(2) The job shows serious constraint violations starting with the initial design (the design model defined by the DVPRELi/DESVAR cards replaces the analysis model, so that is what the initial analysis is made with). The output indicates the best design cycle as cycle 17. Since the constraints have not moved into the feasible region, this decision is arrived at by finding the design which least violates the constraints. Since only the most critical normalized constraint value is shown , it is possible that the entire design process is dominated by a single constraint or more than one, or a cluster around the same area. The "best" design of cycle 17 still indicates serious constraint violation (note that these are normalized values), but an order of magnitude less than for the starting design. Again, perhaps these results were meant only for our investigation and may not represent the actual situation. However, if they do represent an actual design, it should be investigated which constraints appear to be still seriously violated and why. In any case, the "best" design represented by the results of cycle 17 is not an "optimal" design in the sense that it does not satisfactorily satisfy at least one of the prescribed constraints. It may be that it is impossible to satisfy the constraints with the given bounds on the design variables (or given a particular design layout), or it may be that the optimizer has found only a local optimum, in which case re-starting the design process at a particular cycle may help.

(3) Comments:

(a) The f06 file is huge, and can be made smaller by not printing out data from the approximate optimization phase. Normally the DOT optimizer generated data has little, if any, value for a user. Therefore I would suggest keeping IPRINT in the DOPTPRM bulk data at its default value of 0. Instead, the parameter NASPRT can be used to print analysis results (responses) at various cycles, and/or the P1, P2 options on the DOPTPRM bulk data can be used to print out design results (design variable values, designed responses, constraint values) at various cycles. This will still make the f06 file large, but at least these can be regulated to give useful output, if need be.

(b) I have noticed that there is some warning output to the effect that "The gap between glue faces of some elements in gap pair 2 between

regions 1 and 2 seems overly large." These should probably be looked into, unless intentional.

(c) I have also noticed warnings that there are more active constraints than the optimizer can handle at various stages. Therefore, in such cases the optimizer has had to work with a reduced set, which may or may not affect the quality of the final results. We do not have the input data, therefore I do not know the nature of the constraints, however, can guess from the analysis type and from the output requests echoed into the f06 file. There are two possible ways the user can reduce the number of active constraints:

- if possible, by reducing the total number of constraints by way of constraining representative, but not all, items in given regions, though this may be difficult to accomplish with a large model.

- by setting a tighter screening parameter (see DSCREEN bulk data). If most of the constraints are violated, this may not be very helpful. In that case, it may help to relax the bounds somewhat initially and to arrive at an improved design, with which DSCREEN may be more helpful for a re-design with the more realistic constraints. Alternatively, the best design obtained already may be further tested in this manner.

I hope the above is helpful. Please feel free to write me directly if I can be of further help.

Regards,

Erdal Atrek, Ph.D.

Senior Development Engineer

Siemens PLM Software Inc.

Digital Simulation Solutions

NX Nastran

10824 Hope Street

Cypress, California 90630, USA

Tel. : 1 (714) 952-5326

Fax : 1 (714) 952-5755

erdal.atrek@siemens.com

http://www.plm.automation.siemens.com

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

05-31-2012 07:01 PM

I finally found time to look into the PR6560028 I had filed for the issue you had reported on 5/23/2011 to the GTAC Forum, where a design property tied to a design variable violated its upper bound. Your relation was of the form:

P = 1.0 X + 0.01

where P is the property, and X is the design variable. The upper bound for both P and X were the same, at 0.22.

In your job, the design variable hit its upper bound of 0.22, thereby pushing P to 0.23, thus having it violate its upper bound.

I was able to find a simpler problem and create a similar behavior by tweaking around the various data. What I found was that this can only happen when the best design found is already infeasible, such that the most violated constraint is more violated than a property which may be violated. To verify this, I went back to your f06 file, which luckily was still where I had put it. Indeed, here is the line for the best design:

17 6.110103E+03 6.110103E+03 0.000000E+00 6.504346E-01 <<== BEST DESIGN

You will note that the constraint violation is huge, especially compared to the upper bound violation by the property in question.

One may argue that it is desirable that the property bounds are not violated even though the response bounds are, but unfortunately this did not go into the design of the code. This is done for the design variables, but not for the properties. I hope the workaround I had given at that time worked fine for you.

Please also note that property bounds will never be violated when the design is feasible.

Therefore, at this point I will resolve the PR as “not a bug”, but will put in a related comment into the Quick Reference Guide. Perhaps in the future we may have an opportunity to write the necessary (and rather complicated code) to include properties as non-violate even when responses are violated more.

Thanks again for your communicating this concern to us.

Regards,

Erdal Atrek, Ph.D.

Senior Development Engineer

Siemens PLM Software Inc.

Digital Simulation Solutions

NX Nastran

10824 Hope Street

Cypress, California 90630, USA

Tel. : 1 (714) 952-5326

Fax : 1 (714) 952-5755

erdal.atrek@siemens.com

http://www.plm.automation.siemens.com

Follow Siemens PLM Software

© 2018 Siemens Product Lifecycle Management Software Inc